Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 75 Next »

[00:12:19 EST(-0500)] * Tuomaz (n=fredrik@kaffe.umdc.umu.se) has joined ##uportal
[00:12:31 EST(-0500)] * apetro (n=apetro@68.3.207.51) has joined ##uportal
[00:26:20 EST(-0500)] * JASIGLogBot (n=PircBot@jasigch.Princeton.EDU) has joined ##uportal
[00:31:26 EST(-0500)] * ChanServ (ChanServ@services.) has joined ##uportal
[00:31:26 EST(-0500)] * jlee|afk (n=jlee_lap@adsl-074-184-125-241.sip.asm.bellsouth.net) has joined ##uportal
[00:32:37 EST(-0500)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined ##uportal
[00:32:54 EST(-0500)] * dstn (n=dstn@schultz.its.yale.edu) has joined ##uportal
[00:42:19 EST(-0500)] * Tuomaz (n=fredrik@kaffe.umdc.umu.se) has joined ##uportal
[05:08:33 EST(-0500)] * JASIGLogBot (n=PircBot@jasigch.Princeton.EDU) has joined ##uportal
[05:08:33 EST(-0500)] * Topic is 'http://uportal.pastebin.com/ - http://www.ja-sig.org/wiki/display/UPC/uportal+IRC+Logs' set by EricDalquist on 2008-02-27 12:32:13 EST(-0500)
[05:18:39 EST(-0500)] * JASIGLogBot (n=PircBot@jasigch.Princeton.EDU) has joined ##uportal
[05:18:39 EST(-0500)] * Topic is 'http://uportal.pastebin.com/ - http://www.ja-sig.org/wiki/display/UPC/uportal+IRC+Logs' set by EricDalquist on 2008-02-27 12:32:13 EST(-0500)
[06:27:06 EST(-0500)] * higmad (n=chatzill@pcit-8752.HIG.SE) has joined ##uportal
[08:18:41 EST(-0500)] * higmad (n=chatzill@pcit-8752.HIG.SE) has joined ##uportal
[08:23:23 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[09:00:40 EST(-0500)] * athena7 (n=athena7@adsl-99-136-251-32.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[09:32:13 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:33:02 EST(-0500)] <athena7> hey eric, you didn't ever have a chance to check up on UP-2220 did you?
[09:33:16 EST(-0500)] <EricDalquist> No I didn't
[09:34:15 EST(-0500)] <EricDalquist> do you happen to have a 2.6 layout file handy?
[09:34:17 EST(-0500)] <athena7> ok (smile)
[09:34:27 EST(-0500)] <athena7> no, it's not a big deal
[09:34:31 EST(-0500)] <athena7> i can test it myself later
[09:34:48 EST(-0500)] <athena7> i just wanted to ask because i know some of the tickets aren't necessarily updated
[09:35:06 EST(-0500)] <athena7> by the way, jlee got us started with a patch for the datepicker that i think will actually work
[09:35:30 EST(-0500)] <athena7> i still need to review a couple pieces of it, but i did a cursory check and it looks like it was the only broken component
[09:35:47 EST(-0500)] <EricDalquist> nice
[09:36:10 EST(-0500)] <athena7> yeah
[09:36:26 EST(-0500)] <athena7> so just waiting on some discussion from fluid
[09:36:32 EST(-0500)] <athena7> but hopefully we can really get this all working
[09:36:36 EST(-0500)] <EricDalquist> I'd need a 2.6 layout file to confirm but I would guess that just calling the import-layout_v3.0.crn script on it would work
[09:37:07 EST(-0500)] <athena7> i'll try and find a time this morning to test it and let you know
[09:37:19 EST(-0500)] <athena7> i'm sure i must have a checkout of 2.6 somewhere on this machine
[09:37:43 EST(-0500)] <EricDalquist> you can look at the import-channel scripts in trunk for an example of delegating up
[09:39:02 EST(-0500)] <EricDalquist> have you posted anything about the datepicker issues to its developers?
[09:58:29 EST(-0500)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:09:47 EST(-0500)] <athena7> no, not yet
[10:10:09 EST(-0500)] <athena7> i tried to search their bug tracker yesterday to see if it was documented, and their tracker was down
[10:41:45 EST(-0500)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:53:22 EST(-0500)] * apetro (n=apetro@12.164.139.7) has joined ##uportal
[11:16:42 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[11:54:46 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[12:09:58 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has joined ##uportal
[12:10:00 EST(-0500)] <colinclark> athena7: I hear you've been encountering some issues with jQuery's extreme noConflicts mode.
[12:10:25 EST(-0500)] <athena7> indeed!
[12:10:33 EST(-0500)] <athena7> i get errors about jQuery not being found
[12:10:51 EST(-0500)] <athena7> looks like there are a number of references to "jQuery" in the fluid code and/or dependencies
[12:10:59 EST(-0500)] <colinclark> athena7: Yep, that's right.
[12:11:17 EST(-0500)] <colinclark> I took a look at the jQuery source code, and they're not kidding when they say it's extreme. (wink)
[12:11:45 EST(-0500)] <athena7> is there any way to get fluid to work with their extreme noconflicts mode?
[12:11:50 EST(-0500)] <colinclark> There's a note in the documentation that says most plugins will break when it is turned on. Interestingly, it looks like jQuery UI is also susceptible to this problem.
[12:12:03 EST(-0500)] <colinclark> athena7: I think we can, but there are some interesting issues to work out.
[12:12:11 EST(-0500)] <athena7> everything w/ jquery ui works except the datepicker, which jlee patched for us
[12:12:16 EST(-0500)] <colinclark> Interesting.
[12:12:41 EST(-0500)] <colinclark> I wonder how they do this, since they follow the standard plugin technique of binding $ to jQuery in a closure...
[12:12:49 EST(-0500)] <athena7> basically we're trying to set things up so that portlets can potentially use a different version of jquery and jquery ui than the portal
[12:13:03 EST(-0500)] <colinclark> (function($) {
[12:13:03 EST(-0500)] <colinclark> })(jQuery);
[12:13:22 EST(-0500)] <athena7> that all works fine as long as the code in the middle references $ instead of jQuery
[12:13:35 EST(-0500)] <colinclark> athena7: So what name are you assigning the various versions of jQuery to?
[12:13:59 EST(-0500)] <athena7> jlee suggested something like the following: http://www.ja-sig.org/wiki/display/PLT/JavaScript+Best+Practices
[12:14:47 EST(-0500)] <athena7> and then of course our plugins are just separate files with "(function($){ })(jQuery);"
[12:15:22 EST(-0500)] <colinclark> athena7: I'm slightly confused, since this is exactly what we're doing in Fluid.
[12:15:36 EST(-0500)] <athena7> the difference is how jQuery is called within that closure
[12:15:50 EST(-0500)] <athena7> so with most of jquery ui, they use the $, rather than using "jQuery"
[12:16:33 EST(-0500)] <athena7> here's the code for the tabs plugin: http://jquery-ui.googlecode.com/svn/tags/1.6rc4/ui/ui.tabs.js
[12:16:46 EST(-0500)] <colinclark> athena7: Right. Any reference to jQuery within the closure should be via $.
[12:17:04 EST(-0500)] <colinclark> athena7: I wonder if you've just stumbled across a few lingering places where we refer to jQuery inside the closure?
[12:17:10 EST(-0500)] <colinclark> What errors have you seen?
[12:17:10 EST(-0500)] <athena7> yep
[12:17:26 EST(-0500)] <athena7> it looks like some of the aria stuff in particular maybe?
[12:17:33 EST(-0500)] <colinclark> Interesting. Ok.
[12:17:44 EST(-0500)] <colinclark> Cool, we can fix that asap. Dorky bug on our part.
[12:17:46 EST(-0500)] <colinclark> (tongue)
[12:19:04 EST(-0500)] <athena7> (smile)
[12:19:46 EST(-0500)] <colinclark> I like jlee's suggestion in the JS Best Practices document.
[12:20:01 EST(-0500)] <colinclark> I wonder if it wouldn't be more recognizable if it used the anonymous closure technique instead, like all the plugins do.
[12:20:40 EST(-0500)] * colinclark_ (n=colin@142.150.154.154) has joined ##uportal
[12:20:57 EST(-0500)] <athena7> hang on a second, phone, sorry!
[12:21:13 EST(-0500)] <colinclark_> network dropped
[12:21:15 EST(-0500)] <colinclark_> no worries
[12:21:17 EST(-0500)] <colinclark_> (smile)
[12:27:15 EST(-0500)] <colinclark_> athena7, Justin_o: http://issues.fluidproject.org/browse/FLUID-2165
[12:27:36 EST(-0500)] <colinclark_> I haven't done any coding in about a week, so this will give me something real to do. (wink)
[12:32:48 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[12:34:14 EST(-0500)] <athena7> lol
[12:37:30 EST(-0500)] <athena7> ok, i'm back!
[12:44:47 EST(-0500)] <colinclark_> athena7: So, I'm still slightly confused about how plugins like jQuery UI aren't breaking when you're using extreme noConflicts mode.
[12:44:54 EST(-0500)] <athena7> hello again colin
[12:45:02 EST(-0500)] <athena7> thanks for creating the ticket
[12:45:06 EST(-0500)] <colinclark_> no problem
[12:45:12 EST(-0500)] <colinclark_> I'm just fixing it now.
[12:45:18 EST(-0500)] <colinclark_> I mean, the point of the extreme mode is to surrender both the $ and jQuery variables.
[12:45:28 EST(-0500)] <athena7> things from within closures seem to work fine
[12:45:33 EST(-0500)] <colinclark_> So, say when jQuery UI core loads...
[12:45:37 EST(-0500)] <EricDalquist> but only surrender them at the global scope right?
[12:45:45 EST(-0500)] <colinclark_> EricDalquist: Yep, that's right.
[12:46:02 EST(-0500)] <athena7> when we call those external files we do it from the variable we assigned when we called the jQuery.noConflict(true);
[12:46:02 EST(-0500)] <colinclark_> It binds $ to the global jQuery variable, right?
[12:46:09 EST(-0500)] <colinclark_> aha
[12:46:37 EST(-0500)] <colinclark_> athena7: So does that mean you've modified each of those third-party dependencies?
[12:46:50 EST(-0500)] <athena7> no
[12:46:57 EST(-0500)] <athena7> the dependency works ok
[12:47:10 EST(-0500)] <athena7> but when we call it we use the style that jlee described
[12:47:22 EST(-0500)] <EricDalquist> well wait ... when you load the plugin JS it references the global $
[12:47:36 EST(-0500)] <EricDalquist> then you rename/modify that reference when you do jQuery.noConflict(true);
[12:47:49 EST(-0500)] <EricDalquist> the trick is since the loaded JS file is wrapped in a closure
[12:48:07 EST(-0500)] <EricDalquist> when it gets loaded it gets function pointer to what $ was at that time ... before you called jQuery.noConflict(true);
[12:48:11 EST(-0500)] <EricDalquist> right?
[12:48:15 EST(-0500)] <athena7> yes, exactly
[12:48:19 EST(-0500)] <athena7> so we have things like this in the page: http://uportal.pastebin.com/m2f0b39c2
[12:48:22 EST(-0500)] <EricDalquist> that's the magic of all of this, that JavaScript supports function pointers
[12:48:30 EST(-0500)] <colinclark_> yes, totally
[12:48:40 EST(-0500)] <athena7> then somewhere else in the page, we can import another version of jquery and assign it to a different variable
[12:48:48 EST(-0500)] <athena7> and use that other version for some arbitrary portlet
[12:49:16 EST(-0500)] <colinclark_> But still, that doesn't account for the value of "jQuery" at plugin load time.
[12:49:20 EST(-0500)] <colinclark_> If you know what I mean.
[12:49:33 EST(-0500)] <colinclark_> You'll have to forgive me, I'm hopelessly fuzzy this morning, so I may be missing something.
[12:49:42 EST(-0500)] <athena7> i'm sort of fuzzy on javascript in general, sadly
[12:49:47 EST(-0500)] <colinclark_> ha
[12:49:50 EST(-0500)] <colinclark_> Hardly!
[12:49:55 EST(-0500)] <athena7> lol
[12:49:56 EST(-0500)] <EricDalquist> are both $ and jQuery defined by the act of loading the jQuery JS file?
[12:50:14 EST(-0500)] <colinclark_> EricDalquist: That's right.
[12:50:25 EST(-0500)] <EricDalquist> ok so my understanding ...
[12:50:36 EST(-0500)] <colinclark_> And a call to noConflicts will then surrender those variables to whatever they were defined as before.
[12:50:53 EST(-0500)] <colinclark_> So I guess it all depends on the timing of your call to noConflicts()
[12:50:54 EST(-0500)] <EricDalquist> you load jquery-1.0.js, it defines $ and jQuery in the global scope
[12:50:59 EST(-0500)] <colinclark_> EricDalquist: Exactly.
[12:51:14 EST(-0500)] <colinclark_> And then, immediately after jQuery.js is loaded, presumably we load all our other dependencies...
[12:51:15 EST(-0500)] <EricDalquist> you load randomplugin.js, which is wrapped in a closure that passes in jQuery
[12:51:19 EST(-0500)] <colinclark_> jQuery UI, Fluid, etc.
[12:51:41 EST(-0500)] <EricDalquist> when each of those is loaded that closure is executed
[12:51:43 EST(-0500)] <colinclark_> So you must be calling noConflicts() after everything has loaded.
[12:51:46 EST(-0500)] <EricDalquist> yes
[12:51:58 EST(-0500)] <EricDalquist> after loading everything you call noConflicts
[12:52:01 EST(-0500)] <colinclark_> So this isn't actually allowing for more than one version of jQuery at a time, right?
[12:52:02 EST(-0500)] <EricDalquist> which clears out the global scope
[12:52:12 EST(-0500)] <colinclark_> yep{color}
[12:52:29 EST(-0500)] <EricDalquist> all of the stuff you loaded has function pointers to the jquery-1.0 defined objects though
[12:52:37 EST(-0500)] <EricDalquist> so if I then load jquery-2.0
[12:52:47 EST(-0500)] <EricDalquist> it defines $ and jQuery again at the global scope
[12:52:51 EST(-0500)] <EricDalquist> load more stuff that depends on 2.0
[12:52:54 EST(-0500)] <EricDalquist> call noConflict
[12:53:10 EST(-0500)] <EricDalquist> now there is no $ or jQuery defined globally
[12:53:21 EST(-0500)] <EricDalquist> but since all my plugin code was loaded via these closures
[12:53:40 EST(-0500)] <EricDalquist> each closure has a reference to the version of jQuery that was active when it was loaded
[12:53:56 EST(-0500)] <EricDalquist> as long as it always accesses it via the jQuery reference passed into the closure
[12:54:05 EST(-0500)] <colinclark_> that assumes that your head looks something like this:
[12:55:09 EST(-0500)] <colinclark_> arg, i could type this out but it will be tedious. (wink)
[12:55:25 EST(-0500)] <EricDalquist> well lets work at improving: http://www.ja-sig.org/wiki/display/PLT/JavaScript+Best+Practices
[12:55:32 EST(-0500)] <colinclark_> Definitely, I will.
[12:55:33 EST(-0500)] <EricDalquist> since that is probably the biggest usecase of this
[12:55:48 EST(-0500)] <EricDalquist> I think including an example of what an included js file (wrapped in a closure) should look like
[12:56:03 EST(-0500)] <EricDalquist> we can add comments explaining how the function pointers are working
[12:56:05 EST(-0500)] <colinclark_> yep
[12:56:10 EST(-0500)] <colinclark_> I have some of this in the Fluid wiki,
[12:56:13 EST(-0500)] <colinclark_> let me dig up a link
[12:56:17 EST(-0500)] <colinclark_> and then i'll move some of it over to this page
[12:56:25 EST(-0500)] <EricDalquist> ok
[12:56:43 EST(-0500)] <colinclark_> If our goal is to support multiple versions of jQuery within the portal, I think we still have a problem.
[12:56:52 EST(-0500)] <colinclark_> We had to bend our brains to get it all to work for multiple versions of Fluid.
[12:57:09 EST(-0500)] <EricDalquist> why is that?
[12:57:21 EST(-0500)] <colinclark_> Ultimately, we had to declared a separate variable in the global namespace for each version of Fluid.
[12:57:45 EST(-0500)] <colinclark_> Here's the code:
[12:57:47 EST(-0500)] <colinclark_> var fluid_0_8 = fluid_0_8 || {};
[12:57:57 EST(-0500)] <colinclark_> And then our closures look like this:
[12:58:13 EST(-0500)]

<colinclark_> (function ($, fluid)

Unknown macro: { < code goes here > }

)(jQuery, fluid_0_8);


[12:58:27 EST(-0500)] <EricDalquist> http://www.nabble.com/JQuery-UI-and-JQuery-.1.1.3-td19593705s27240.html
[12:59:06 EST(-0500)] <colinclark_> Here's a doc that explains it:
[12:59:07 EST(-0500)] <colinclark_> A user who, say, wanted to use Fluid 0.7, would
[12:59:09 EST(-0500)] <colinclark_> oops
[12:59:13 EST(-0500)] <colinclark_> (tongue)
[12:59:14 EST(-0500)] <colinclark_> http://wiki.fluidproject.org/display/fluid/Versioning+the+Fluid+Framework
[12:59:15 EST(-0500)] <colinclark_> that's better
[12:59:32 EST(-0500)] <EricDalquist> http://uportal.pastebin.com/m7fe7bf72
[13:00:07 EST(-0500)] <EricDalquist> yeah I think this is the same idea
[13:00:11 EST(-0500)] <colinclark_> EricDalquist: Yep, that's it. Everything that depends on a certain version of jQuery needs to be loaded in a group.
[13:00:19 EST(-0500)] <EricDalquist> yes
[13:00:40 EST(-0500)] <EricDalquist> and honestly with portlets we could end up with a case where you load jQuery X twice and jQuery Y once
[13:01:01 EST(-0500)] <EricDalquist> but that should still work
[13:01:12 EST(-0500)] <colinclark_> EricDalquist: Yep
[13:05:35 EST(-0500)] <EricDalquist> I'm still impressed that anyone figured out a way to do this at all
[13:05:44 EST(-0500)] <EricDalquist> its the only thing that gives me hope for using JS in portlets
[13:05:50 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[13:05:57 EST(-0500)] <EricDalquist> my only fear now is how much time the browser is going to spend parsing .js files (smile)
[13:06:08 EST(-0500)] <EricDalquist> but there isn't much we can do about that
[13:18:01 EST(-0500)] <athena7> oh i'm sure we could do things (smile)
[13:18:04 EST(-0500)] <athena7> i just don't know that we want to
[13:21:10 EST(-0500)] <colinclark_> yeah, loading multiple versions of everything strikes me as sort of a last resort.
[13:21:24 EST(-0500)] <colinclark_> we need to support it within uportal, but it's not ideal
[13:21:32 EST(-0500)] <colinclark_> load time and memory usage are both concerns
[13:21:40 EST(-0500)] <EricDalquist> yup
[13:21:54 EST(-0500)] <EricDalquist> which is the fun that the portal infrastructure folks deploying the portlets get to deal with (sad)
[13:22:13 EST(-0500)] <athena7> i mean we could define some sort of method that would return a handle to a jquery environment based on some parameters about the desired jquery ui version or something
[13:22:21 EST(-0500)] <EricDalquist> yeah
[13:22:31 EST(-0500)] <EricDalquist> something like the google loader API
[13:22:35 EST(-0500)] <colinclark_> athena7: Yep, that would do it.
[13:22:41 EST(-0500)] <EricDalquist> integrate that into that JS provider webapp we keep talking about
[13:22:58 EST(-0500)] <athena7> i think it might be doable
[13:23:18 EST(-0500)] <athena7> that way different portlets could share the same handle to any given version set
[13:23:41 EST(-0500)] <athena7> will have to think about it
[13:23:41 EST(-0500)] <colinclark_> That does male sense. Take the approach that it's the portal's job to satisfy dependencies for whatever we determine to be "core" javascript libraries.
[13:23:53 EST(-0500)] <athena7> yeah
[13:24:03 EST(-0500)] <EricDalquist> yup
[13:24:10 EST(-0500)] <athena7> we'd have to switch to dynamically including the javascript dependencies, i guess
[13:24:13 EST(-0500)] <EricDalquist> the only problem with that is it then ties the portlets to the portal
[13:24:15 EST(-0500)] <athena7> but i don't think that should be a problem?
[13:24:20 EST(-0500)] <athena7> it does
[13:24:25 EST(-0500)] <EricDalquist> I don't think so
[13:24:40 EST(-0500)] <EricDalquist> it would be nice to make it not too difficult to use in some other portal if someone wanted to though
[13:24:41 EST(-0500)] <athena7> but we could make that a configuration parameter, and allow people to just include jquery that's bundled w/ the portlet, or something
[13:24:46 EST(-0500)] <athena7> right
[13:24:53 EST(-0500)] <EricDalquist> like have a way for the portlet to host the JS itself if it needed to
[13:24:53 EST(-0500)] <athena7> i don't think that's a big deal
[13:24:55 EST(-0500)] <athena7> right
[13:24:59 EST(-0500)] <EricDalquist> (smile)
[13:24:59 EST(-0500)] <colinclark_> That makes sense to me.
[13:25:14 EST(-0500)] <athena7> actually i think this is worth exploring
[13:25:30 EST(-0500)] <athena7> would allow us to bring in some multi-versioning without making things too insane
[13:25:32 EST(-0500)] <EricDalquist> I do too
[13:25:52 EST(-0500)] <EricDalquist> portalJs.load('scriptName', 'version');?
[13:26:19 EST(-0500)] <EricDalquist> does this pattern apply to frameworks other than jQuery & FLUID?
[13:26:32 EST(-0500)] <colinclark_> The only challenge with dynamic loading on the client side is that it makes debugging much harder.
[13:26:44 EST(-0500)] <colinclark_> Dojo's .declare() system is a mess to debug
[13:26:56 EST(-0500)] <colinclark_> because FireBug still hates code that is dynamically loaded with eval().
[13:27:02 EST(-0500)] <EricDalquist> ah
[13:27:08 EST(-0500)] <colinclark_> Head manipulation is probably more reliable.
[13:27:31 EST(-0500)] <athena7> i don't know that portalJs.load('scriptName', 'version'); would do it, because we'd need the handle back to a jquery environment that had more than just one file
[13:27:37 EST(-0500)] <athena7> some combination of jquery/jqueryui/fluid
[13:27:39 EST(-0500)] <colinclark_> Is it not possible to satisfy all the correct JS dependencies on the server, though?
[13:28:02 EST(-0500)] <athena7> the portal has no way of knowing what javascript portlets are trying to include
[13:28:10 EST(-0500)] <athena7> well, not with jsr-168, anyway
[13:28:45 EST(-0500)] <colinclark_> Right. So it would have to be something uPortal-specific, where the portal defined its required dependencies in a configuration file.
[13:28:52 EST(-0500)] <EricDalquist> JSR-286 allows for contributions to the head
[13:29:11 EST(-0500)] <EricDalquist> but uPortal doesn't support 286 yet
[13:29:29 EST(-0500)] <colinclark_> right
[13:29:32 EST(-0500)] <colinclark_> ok
[13:29:45 EST(-0500)] <athena7> so unfortunately i think we would have to do dynamic loading, which i agree sucks
[13:30:01 EST(-0500)] <EricDalquist> athena7: I was just thinking of not hiding too much stuff
[13:30:10 EST(-0500)] <EricDalquist> making it like the jQuery noconflict stuff
[13:30:21 EST(-0500)] <EricDalquist> where I do a bunch of portalJS.load calls
[13:30:29 EST(-0500)] <EricDalquist> then do a portaljs.noconflict when all done
[13:30:38 EST(-0500)] <EricDalquist> and the JS does magic to only load a particular version once
[13:30:49 EST(-0500)] <athena7> hm
[13:30:59 EST(-0500)] <athena7> i'm trying to think how we'd get a handle to the right version that way
[13:31:09 EST(-0500)] <EricDalquist> very well named global variables
[13:31:39 EST(-0500)] <EricDalquist> portalJsCache['framework','version'].ref?
[13:31:42 EST(-0500)] <athena7> because if the scripts weren't loaded because they were already present, then $var = jQuery.noConflict(true) wouldn't actually return the right thing
[13:31:56 EST(-0500)] <[jlee]> just jumping in on the tail end of the discussion here, but perhaps you can handle javascript dependencies from view layer (JSP) ?
[13:32:09 EST(-0500)] <EricDalquist> that's why we call our noconflict which is smart enough to only call it once
[13:32:15 EST(-0500)] <EricDalquist> it being the real jQuery noconflict
[13:32:19 EST(-0500)] <EricDalquist> once per load that is
[13:32:25 EST(-0500)] <EricDalquist> [jlee]: in what way?
[13:32:38 EST(-0500)] <EricDalquist> the problem we have is we have N apps on one page
[13:32:39 EST(-0500)] <[jlee]> create some sort of custom tag used to include the .js files in the portlet.. but it will check a flag to see if that .js file has already been imported?
[13:32:41 EST(-0500)] <EricDalquist> each with their own JSP
[13:32:51 EST(-0500)] <EricDalquist> and each rendering in their own classloader
[13:33:03 EST(-0500)] <EricDalquist> so each of the N JSPs can't share data between them
[13:33:13 EST(-0500)] <EricDalquist> heck in uPortal's case they render in parallel threads
[13:33:23 EST(-0500)] <[jlee]> ah.. gotcha
[13:34:01 EST(-0500)] <EricDalquist> the only other idea would be a portal level API that a portlet can call before rendering that declares all of it's JS deps and versions
[13:34:08 EST(-0500)] <EricDalquist> but that would very strongly tie the portlet to uPortal
[13:34:33 EST(-0500)] <[jlee]> yeah.. from what I understand of liferay, I think that's how they do it
[13:34:33 EST(-0500)] <athena7> i think that might be what we need to do, but if we go that route, we should make that behavior configurable
[13:34:41 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[13:34:53 EST(-0500)] <athena7> so with the flag off, it would act more traditionally and load up local javascript itself
[13:35:22 EST(-0500)] <EricDalquist> "i think that might be what we need to do" that being an extension to the portlet API?
[13:36:13 EST(-0500)] <athena7> i was thinking something like calling from the portlet: "var something = getPortalJsEnv('version-identifier');"
[13:36:41 EST(-0500)] <athena7> where getPortalJsEnv would figure out which scripts need to be imported, and import them if necessary
[13:37:04 EST(-0500)] <athena7> and return the result of jQuery.noConflict(true) for that script set, returning an already-existing variable if we've already done this
[13:37:47 EST(-0500)] <EricDalquist> ok
[13:37:59 EST(-0500)] <EricDalquist> what about custom plugins and stuff the script needs to load?
[13:38:05 EST(-0500)] <EricDalquist> s/script/portlet/
[13:38:16 EST(-0500)] <athena7> hm, good point
[13:38:36 EST(-0500)] <athena7> i don't know that loading them after getting back that variable would work
[13:38:59 EST(-0500)] <EricDalquist> that's why I was thinking of a thinner wrapper
[13:39:29 EST(-0500)] <athena7> the problem is, if the script was imported previously on the page, i'm not sure that it will work regardless of how we wrap it
[13:40:01 EST(-0500)] <EricDalquist> hrm
[13:40:08 EST(-0500)] <EricDalquist> let me try typing out an example
[13:40:21 EST(-0500)] <athena7> so say we import jquery 1.3.1 for the portal, then 1.2.6 for portlet #1
[13:40:39 EST(-0500)] <athena7> then portlet #2 needs 1.3.1 and a custom plugin
[13:41:09 EST(-0500)] <athena7> if we have something that only imports scripts once per page, we don't import 1.3.1 again because we already did it once
[13:41:16 EST(-0500)] <EricDalquist> right
[13:41:25 EST(-0500)] <EricDalquist> but couldn't we just put back the $ and jQuery global vars
[13:41:29 EST(-0500)] <EricDalquist> then load the 1.3.1 plugin
[13:41:30 EST(-0500)] <athena7> but now if we call jQuery.noConflict(true), we get something back from jQuery 1.2.6, not 1.3.1
[13:41:32 EST(-0500)] <EricDalquist> then remove them
[13:42:05 EST(-0500)] <EricDalquist> isn't all that jQuery.noConflict(true) is doing is unsetting $ and jQuery and returning a reference to what jQuery was?
[13:42:28 EST(-0500)] <athena7> i think so
[13:42:40 EST(-0500)] <athena7> but i'm not sure how to get back the reference to jQuery 1.3.1
[13:43:26 EST(-0500)] <EricDalquist> lets see...
[13:43:40 EST(-0500)] <EricDalquist> 1. load jquery 1.3.1, this sets the $ and jQuery global variables
[13:43:51 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has left ##uportal
[13:44:26 EST(-0500)] <EricDalquist> 2. call jQuery.noConflict(true), this unsets the $ and jQuery global variables and returns a reference equivalent to what the jQuery global var was
[13:45:05 EST(-0500)] <EricDalquist> 3. store that reference in a global map that we manage: portalJsLoader['jQuery-1.3.1'].jQuery
[13:45:15 EST(-0500)] <athena7> right
[13:45:22 EST(-0500)] <EricDalquist> then some portlet asks for jQuery 1.3.1 later
[13:45:27 EST(-0500)] <EricDalquist> instead of loading it
[13:45:42 EST(-0500)] <EricDalquist> when just set the global vars $ an jQuery and set them equal to portalJsLoader['jQuery-1.3.1'].jQuery
[13:46:01 EST(-0500)] <EricDalquist> when that portlet is done loading its plugins/scripts and calls portalJsLoad.noConflict()
[13:46:11 EST(-0500)] <EricDalquist> we just unset $ and jQuery and return a reference to jQuery
[13:46:18 EST(-0500)] <athena7> yes . . . i think that works
[13:46:19 EST(-0500)] <EricDalquist> so we didn't really reload jQuery 1.3.1
[13:46:23 EST(-0500)] <EricDalquist> just pretend to
[13:46:27 EST(-0500)] <athena7> depends on the portlets playing really nicely
[13:46:29 EST(-0500)] <athena7> but i think it's doable
[13:46:33 EST(-0500)] <EricDalquist> yes it does
[13:46:52 EST(-0500)] <EricDalquist> and we have to have logic to handle each JS framework
[13:46:59 EST(-0500)] <EricDalquist> but hopefully the concepts are all similar
[13:47:03 EST(-0500)] <athena7> and we need to handle them together, sort of, too
[13:47:05 EST(-0500)] <EricDalquist> with having a map to track globals
[13:47:17 EST(-0500)] <athena7> we need to know whether a particular JS framework has been loaded for a particular jQuery version
[13:47:39 EST(-0500)] <EricDalquist> well we just use the same logic agaisnt that map for everything
[13:48:36 EST(-0500)] <EricDalquist> the load logic could look like:
[13:48:37 EST(-0500)] <EricDalquist> if isset portalJsLoader['scriptname-version'] then; fake loading & set fake load flag else; load for real & set real load flag;
[13:48:44 EST(-0500)] <EricDalquist> the noConflict logic could look like:
[13:49:26 EST(-0500)] <EricDalquist> if is real load then; do real noConflict call and update global map; else do fake noConflict call, clear global vars;
[13:49:53 EST(-0500)] <EricDalquist> that global map lets us track what is loaded and potential references to it that need to be shared
[13:50:34 EST(-0500)] <EricDalquist> for each particular script/version we would need probably need a little utility stub to do the load/fakeload/noConflict/fakeNoConflict logic
[13:50:56 EST(-0500)] <EricDalquist> since that will all be specific to each framework & plugin
[13:51:13 EST(-0500)] <athena7> i'm not sure if it actually would be specific
[13:51:19 EST(-0500)] <EricDalquist> [jlee]: you have any thoughts about all of this rambling from a non JS person?
[13:53:04 EST(-0500)] <EricDalquist> well the nice thing is it would only have to handle the scripts actually supported by this webapp
[13:53:33 EST(-0500)] <EricDalquist> this could turn into like a render time maven for JS (tongue)
[13:54:07 EST(-0500)] <athena7> lol
[13:54:09 EST(-0500)] <colinclark_> Wow, good convo... just catching up.
[13:55:49 EST(-0500)] <EricDalquist> well can't you see some meta JS framework that lets you do:
[13:56:00 EST(-0500)] <EricDalquist> jsLoader.load(groupId, artifactId, version)
[13:56:11 EST(-0500)] <athena7> yes (smile)
[13:56:11 EST(-0500)] <EricDalquist> and also resolves dependencies of that script
[13:56:19 EST(-0500)] <athena7> i totally know what you mean
[13:56:28 EST(-0500)] <EricDalquist> though it could cheat server side a bit
[13:56:30 EST(-0500)] <athena7> the thought of having something that complex is just scaring me though
[13:56:30 EST(-0500)] <athena7> lol
[13:56:43 EST(-0500)] <colinclark_> I only wish jQuery would version their own global variables, making our life much easier.
[13:56:51 EST(-0500)] <athena7> yes
[13:56:53 EST(-0500)] <colinclark_> I've never really talked to Resig about it, maybe I should.
[13:57:03 EST(-0500)] <EricDalquist> and do an AJAX callback to a servlet that figures out the deps and returns a complete array of all deps to be loaded
[13:57:04 EST(-0500)] <athena7> i think all this could work though
[13:57:08 EST(-0500)] <EricDalquist> ok ... I need to stop thinking about htat
[13:57:09 EST(-0500)] <colinclark_> yep, it could
[13:58:31 EST(-0500)] <athena7> so if i can find some of that elusive thing called spare time
[13:58:40 EST(-0500)] <athena7> it seems like it'd be worth trying some of this out
[13:58:47 EST(-0500)] <EricDalquist> (smile)
[13:58:48 EST(-0500)] <athena7> as well as actually sharing our plans with the list
[13:59:16 EST(-0500)] <athena7> i'd really like to find some time to try and deal with some of those profile issues
[14:00:28 EST(-0500)] <athena7> but it'd probably be good to get some of this javascript stuff hashed out before we talk about best practices at the conference
[14:00:56 EST(-0500)] <EricDalquist> yes it would
[14:01:21 EST(-0500)] <EricDalquist> I need to read the recently finished incubation docs
[14:01:29 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[14:01:40 EST(-0500)] <EricDalquist> but perhaps we could start something in the sandbox and hack in our combined 'spare time'
[14:01:51 EST(-0500)] <athena7> yeah
[14:02:02 EST(-0500)] <athena7> i do think i'll be able to take a look at it
[14:02:30 EST(-0500)] <athena7> maybe if i could find some time to look at some of the javascript side of things, you could take a look at the gzipping and filtering aspects?
[14:02:51 EST(-0500)] <EricDalquist> yup
[14:03:03 EST(-0500)] <EricDalquist> I'm still thinking this as a little stand-alone webapp
[14:03:14 EST(-0500)] <EricDalquist> since it really isn't uPortal specific right now?
[14:04:08 EST(-0500)] <athena7> definitely
[14:07:03 EST(-0500)] <colinclark_> let me know if there's anything i can do to help. this is awesome stuff
[14:07:09 EST(-0500)] <colinclark_> and i will be there at the conference, too
[14:07:19 EST(-0500)] <colinclark_> hopefully will be staying for the dev meeting afterwards
[14:12:02 EST(-0500)] <athena7> will be nice to see you!
[14:12:14 EST(-0500)] <athena7> i'm not going to be able to stay for the dev meeting, but i'll be there until wed night
[14:12:18 EST(-0500)] <[jlee]> sorry, was afk.. mind if I chime in my $0.02?
[14:12:26 EST(-0500)] <athena7> please do!
[14:13:06 EST(-0500)] <[jlee]> well it's not just jQuery core versioning you have to worry about, but it's also plugin versioning
[14:13:31 EST(-0500)] <[jlee]> ie, one portlet could use jQ 1.3 and treeview 1.5, and another portlet would need jQ 1.3 and treeview 2.0
[14:13:34 EST(-0500)] <athena7> right
[14:13:54 EST(-0500)] <[jlee]> so if you were to use the same jQuery core instance for both portlets, you would run into conflicts
[14:13:58 EST(-0500)] <athena7> hm, yes
[14:14:02 EST(-0500)] <EricDalquist> oh fun
[14:14:14 EST(-0500)] <[jlee]> I think that it's probably best to give each portlet it's own instance of jQ
[14:14:34 EST(-0500)] <[jlee]> it's a really small footprint, and if we have it coming from the same filepath, the browser will cache it anyways
[14:15:07 EST(-0500)] <athena7> is jquery + all of jquery ui + all of fluid always going to be a small footprint though?
[14:15:18 EST(-0500)] <athena7> and what about if we're including it at least 5 times in every page?
[14:16:56 EST(-0500)] <[jlee]> hmm.. yeah, I could see how that can bloat things pretty fast
[14:17:10 EST(-0500)] <[jlee]> (not familiar with how large fluid is..)
[14:17:30 EST(-0500)] <athena7> maybe we could call the initial script import with a list of library-managed scripts, rather than importing each individually
[14:17:45 EST(-0500)] <colinclark_> [jlee]: Fluid's probably a bit bigger today than it will be by the time we hit 1.0.
[14:17:47 EST(-0500)] <[jlee]> would a portlet grouping strategy be viable?
[14:18:00 EST(-0500)] <colinclark_> But it's a good question, since one of the things we've been working on is a custom Fluid builder...
[14:18:09 EST(-0500)] <colinclark_> allowing users to select the various parts of Fluid they want to use.
[14:18:13 EST(-0500)] <athena7> and the code could check to see if the matching jQuery version has matching other libraries
[14:18:22 EST(-0500)] <colinclark_> That might depend on the specific portlet.
[14:18:27 EST(-0500)] <athena7> if so, return that handle, if not, create a new one
[14:18:55 EST(-0500)] <EricDalquist> athena7: that's a good iea
[14:18:57 EST(-0500)] <EricDalquist> idea
[14:19:14 EST(-0500)] <athena7> colinclark_: i think we'd discussed including the entirety of our library dependencies so we coudl make use of shared caches
[14:19:17 EST(-0500)] <EricDalquist> do jsLoader.load([['framework','version'],['framework','version'],['framework','version']]);
[14:19:27 EST(-0500)] <colinclark_> athena7: Yeah, that makes a lot of sense.
[14:19:39 EST(-0500)] <athena7> yeah that's exactly what i was thinking eric
[14:19:51 EST(-0500)] <athena7> and that way we still leave a way for the portlet's own internal scripts to be loaded in
[14:20:16 EST(-0500)] <EricDalquist> so the portlet would need to call: jsLoader.load([['framework','version'],['framework','version'],['framework','version']]);
[14:20:23 EST(-0500)] <EricDalquist> then jsLoader.noConflict()
[14:20:32 EST(-0500)] <athena7> yes
[14:20:36 EST(-0500)] <EricDalquist> which will work as long as of all the things they load they only need a single reference
[14:22:14 EST(-0500)] <athena7> i think that should all work, yes
[14:28:09 EST(-0500)] <[jlee]> so playing devil's advocate here... one thing that would have to be made clear to the portlet developer is that any change to the jQuery object (plugins, overriding, etc...) could possibly affect other portlets...
[14:28:33 EST(-0500)] <athena7> yeah
[14:28:42 EST(-0500)] <athena7> i think all of this relies on the portlets playing extremely nice
[14:28:50 EST(-0500)] <[jlee]> either that, or it's made clear that there should be no inline scripting of plugins within the portlet, and that every script needs to go through the portal mechanism
[14:29:12 EST(-0500)] <athena7> at the moment though, almost all the portlets that will be affected by this stuff are JASIG portlets, largely written by people in this channel
[14:29:44 EST(-0500)] <[jlee]> cool – that should help avoid headaches (smile)
[14:32:19 EST(-0500)] * tsnfoo (n=tsnfoo@wso-mbp15.test.denison.edu) has joined ##uportal
[14:32:41 EST(-0500)] <athena7> we'll see!
[15:07:07 EST(-0500)] <dstn> EricDalquist, sorry to keep buggin you on this man but can you do a new export of your guys genericxslt portlet
[15:07:40 EST(-0500)] <dstn> I found an old one here... https://mywebspace.wisc.edu/groups/portal/public/dist/xslt_portlet/
[15:57:41 EST(-0500)] * colinclark (n=colin@142.150.154.154) has joined ##uportal
[16:01:13 EST(-0500)] <EricDalquist> oh sorry dstn
[16:01:17 EST(-0500)] <EricDalquist> and you should keep buging me about it
[16:05:58 EST(-0500)] <dstn> well get on it alreadyyyyy
[16:06:04 EST(-0500)] <dstn> ;-D
[16:06:05 EST(-0500)] <dstn> j/k
[16:06:18 EST(-0500)] <EricDalquist> doing it right now actually
[16:06:34 EST(-0500)] * colinclark_ (n=colin@142.150.154.101) has joined ##uportal
[16:07:06 EST(-0500)] <EricDalquist> https://mywebspace.wisc.edu/dalquist/web/JA-SIG/UWXMLTransformPortlet-2009.01.27.zip
[16:07:11 EST(-0500)] <EricDalquist> that is an export of our latest code
[16:08:19 EST(-0500)] <dstn> thanks!
[16:08:25 EST(-0500)] <EricDalquist> yup
[16:08:29 EST(-0500)] <EricDalquist> it could still use some TLC
[16:08:41 EST(-0500)] <EricDalquist> like switching to Spring's Resource framework for XML and XSL loading
[16:08:53 EST(-0500)] <EricDalquist> but that's the story of every app
[16:09:05 EST(-0500)] <dstn> hmm, never heard of that
[16:09:10 EST(-0500)] <dstn> I'll have to look into it
[16:09:42 EST(-0500)] <EricDalquist> Spring's Resource interface and related code is handy
[16:10:00 EST(-0500)] <EricDalquist> gives a common interface for accessing file system, classpath and URL resources
[16:11:20 EST(-0500)] <EricDalquist> back in a few
[16:14:18 EST(-0500)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[18:27:26 EST(-0500)] * jayshao (n=jayshao@ool-44c4edd3.dyn.optonline.net) has joined ##uportal
[18:29:01 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[18:29:17 EST(-0500)] * apetro_ (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[18:45:08 EST(-0500)] * tsnfoo (n=tsnfoo@cpe-173-88-4-254.columbus.res.rr.com) has joined ##uportal
[18:58:43 EST(-0500)] * [jlee_] (n=jlee@adsl-074-184-125-241.sip.asm.bellsouth.net) has joined ##uportal
[19:04:00 EST(-0500)] * [jlee_] (n=jlee@adsl-074-184-125-241.sip.asm.bellsouth.net) has joined ##uportal
[19:14:21 EST(-0500)] * EricDalquist (n=EricDalq@76.210.72.253) has joined ##uportal
[19:18:52 EST(-0500)] * EricDalquist (n=EricDalq@76.210.72.253) has joined ##uportal
[19:43:01 EST(-0500)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal
[20:46:58 EST(-0500)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined ##uportal
[22:50:07 EST(-0500)] * [jlee] (n=jlee@adsl-074-184-125-241.sip.asm.bellsouth.net) has joined ##uportal
[22:54:51 EST(-0500)] * [jlee_] (n=jlee@adsl-074-184-125-241.sip.asm.bellsouth.net) has joined ##uportal

  • No labels