On 12/17/09 9:57 AM, Dan Allen wrote: I saw that comment as well. But I'm not sure it's really that big a deal... Let's break down what the problem is here, since I really see multiple problems: 1) You download the file more than once. This happens once. After that, it's cached on the user's browser. That means that you have a performance hit on the first hit on the page. After that, there's only a negligible performance impact. The recommended way to really get around this is to aggregate all of the files on the page, full stop - I'd assert that a component library should offer documentation on doing so. That's not really possible programmatically - the combinatorial effects are too unpredictable. 2) You load the file more than once, and the library is the same version. For badly written libraries, this may cause errors. In which case, I'd advise you that if the library has that bug, it probably has others. Note that this problem also exists for certain valid usecases with JSF Ajax, so you're already in trouble - for instance, Ajaxifying a commandButton with an action attribute. 3) You load the library more than once, and it's of different versions. Again, you're quite probably hosed, unless the library is written to handle that case (jsf.js is). I'm not sure there's much we can do about that, regardless of what we do. All three scenarios are very similar to problems that the portal guys already face, and which we've committed to looking at for 2.1 - so I hope that Alexander chimes in here. We could provide a registration mechanism, but then we'd have to run a registry. Please see the OpenAjax registry for an example of how hard that is to do in practice. Or, we could offer a limited registry, matching just the big frameworks - such as the ones offered by Google for download. Or we could just recommend that component libraries at least offer the capability of using the Google library API: http://code.google.com/apis/ajaxlibs/ (Which reminds me, we need to have markup for external resources. We don't, currently, which is a shame, and limits the ability of libraries to offer this as an option - filed as spec bug 706). Of course, none of that solves anything for the stuff that uses the dojo or YUI dynamic loading stuff. Jim

On 12/17/09 12:05 PM, David Geary wrote: Exadel started gwt4jsf some time ago, but I think it died on the vine. Might be a good project for $SOMEONE to pick back up: http://www.theserverside.com/tt/articles/article.tss?l=GWTandJSF -- Jason Lee, SCJP President, Oklahoma City Java Users Group Senior Java Developer, Sun Microsystems http://blogs.steeplesoft.com

a) The import part, the import only once facility would be nice, but does it really matter in as jim pointed out, first there is the browser cache, secondly almost all libs have a double import blocker in its code which check for already existing data structures under their namespaces. b) Double import of different versions, same problem scenario, which in my opinion has to be handled on the library side not on the JSF side. The library has to ensure that a double import of different versions cannot happen, and to my knowledge the big libs do. Is it really our problem? This introduces overhead and in the end we can only cover some libraries (probably the most popular ones) b) as for general framework interoperability, and which kid is the most popular on the block Actually I would not want to go into the jQuery/Dojo whatever wars at all, JSF2 did the necessary steps to isolate itself from other libraries to a huge degree, but it is outside of the scope of jsf to avoid for instance namespace conflicts inflicted by third party libraries. Lets give the an example here the famous $ operator overloading some libraries which I do not want to mention here do, they intra collide with each other they basically are bad neighbors in a well behaved neighborhood by turning on the Ghetto blaster full force to get their own sound for their own 4 walls. But does that anything have to do with the JSF2 implementation, Id say no, if you move into such a neighborhood, then you are on your own regarding those things. I do not even think there is a single thing we can do on our side to ensure the well behavior of the javascript libraries used on the javascript side, all we can do is to behave well in our domain so that others wont get interference from us, which already has happened with the OpenAjax namespaces. I am not even eager to start a discussion here, which library is better or which one is going to win and we have to watch more thoroughly! To come to a conclusion, I personally see bigger things which have to be resolved for the ajax part of JSF2.1 than trying to solve problems which are not really our construction site. Ie. finally introducing different transport layers so that we can handle file uploads, combined with that maybe comet support, better handling of the ResponseWriter on the server side in an ajax case.

On 12/21/09 3:52 AM, Ganesh wrote: Actually, for the most part, they do agree. jQuery is more popular, and the comments either explicitly or implicitly acknowledge that... I didn't say anything about better, nor did I say that popularity should be the basis for choosing a framework, though bluntly, it should be a part of that decision, along with other fitness to task criteria. From the standpoint of looking at the various frameworks out there, the popular ones are what I'm proposing we study. What makes for a popular framework? Because sometimes it's just "first mover advantage", but it's rarely only that. Jim