Hey Pete - Thanks for the clarification - that's what I thought based on prior discussions I've had with Alex. Yes, ICEFaces had done some preliminary work with JSF 2.0: http://www.java.net/blog/2009/05/25/icefaces-20-and-jsf-20-together And I'm sure ADF Faces will follow suite (if they haven't started already). -roger Pete Muir wrote:

Our team just caught the problem with Mojarra implementation. Although interaction with client-side code is encapsulated into AjaxBehavior renderer, jsf.js library contains code that used by the some other renderers from Jsf-impl. Therefore, it is not possible to easy replace client side library for AJAX functionality only, and we have not enough extension points in the standard API to provide additional functionality. I think it breaks flexibility provided by pluggable JSF model. On 09/14/2009 05:17 PM, Alaxander Smirnov wrote:

Hey Alexander: On 9/25/09 12:26 PM, Alexander Smirnov wrote: I'm not sure what you're referring to here: Do you mean the mojarra namespaced functions? Those should be completely separate - that's why they're in a different namespace. Putting them into a separate file has performance implications. And if you think Mojarra's jsf.js file has other functions, check out MyFaces - they're much more agressive in breaking out functionality - an architecture that Mojarra will probably follow in the next rev as well. That was never the intention of either the spec or the implementation, AFAIK. The reason why is easy enough - if every framework wants to do that, then only one framework can - and that would be very bad, since you could never then mix those frameworks in a page. What extension points are you looking for? Please be specific, since this will be what we discuss in the next rev of the spec. One thing I've been contemplating (primarily to accomadate RichFaces functionality) was to change the event system from a monitor function to an intercept function - allowing the cancelation or delay of queued request from the begin event, for instance (for queues and aggregation) or allowing modification of the submitted render and execute fields (for things like autoupdate). If you're interested, we could work together on a POC for this functionality that met the current spec. We could add that into the next rev of the impl - that could fix it for you well before the next spec rev. We could coordinate that effort on the ajax sub-list. At a minimum, Werner, Ted and Andy should also be watching what direction we head in, so we don't waste too much time going down a road that they disapprove of. Please note that at least one person on this list (Ken) has already expressed discomfort at making these changes, since the bugs they could introduce would be difficult to track. It's not clear that the functionality that you're looking for will meet the approval of the EG. But the sooner we start, the sooner we can start to sort through that. Well, as I said, if you modify the jsf.js file, and someone else does as well - how will those two interact? They won't. Which is why it's a bad idea. I'd argue that we should expect that frameworks will *not* supply their own jsf.js - only implementations, of which there are two. Jim

On Sun, Sep 27, 2009 at 9:09 PM, Jim Driscoll <Jim.Driscoll(a)sun.com&gt; wrote: Actually yes we are very modular, the reasons were threefold: - First we wanted to keep the path to future extensions on the transport part as open as possible - Secondly, having done a load of work with dojo I simply prefer to have javascript modular one way or the other (dojo does it in a more aggressive manner than we do, because they also load the stuff dynamically, optionally, while we bind our modules simply in the build process) - Third, when we started this we had some corporate users who wanted to have Dojo as transport mechanism, although I like Dojo I preferred not to introduce a dependency for a core library, but I wanted to keep the path open for those users to replace the I/O transport layer, So far the aggressive modularization worked out pretty well for us. But given the state of the API as an external user I only would use the module part if I knew that I would not switch at least the scripts! You nail yourself down to one implementation. My personal guess is that the core API although it is very small (Thank god I prefer minimalistic approaches over API clutter) it leaves enough flexibility so that you can add your own extensions from the outside. But as Jim Driscoll has stated if you provide such a thing as official extension points in a dynamic language, it is hard to ensure that two libraries do not add extensions which are incompatible to each other. (Which is a non issue for now for us since the modular parts are in impl only and not part of the spec or api) The only way I can see it is to either just add additional listeners or to clearly specify the impl submodules and their interfaces and make them delegatable just like jsf does, or add some kind of chain patters which allow to plug users their own implementations on top of the chain. However we still cannot prevent that anyone does something nasty with the runtime, this is javascript after all, but so no library can. So there is a way to introduce more extension points, but we have to be careful where and how. I´m in if you guys want me as a watcher, I also would recommend Ganesh Jung or Alexander Bell for the job, we basically worked on equal parts on the myfaces scripts.

I probably rushed to send initial message based on our team concerns only, without deep investigation of the implementation details. I spent this Monday to put all things together into order. On 09/27/2009 12:09 PM, Jim Driscoll wrote: I guess what it was unclean in my point. For me, ClientBehavior would encapsulate all JavaScript rendering/decoding functionality, so it doesn't matter which JavaScript code was really generated. Custom renderer would provide its own library for particular client type ( for example, with iPhone or mobile render kit. It is also actual for portal environment where all JavaScript function names should be namespaced to prevent inter-portlet conflicts. ), or introduce its own extensions. Any component library would believe on Java ClientBehavior/AjaxBehavior API only, so it does not matter which implementation is really used by application. Of course, particular AJAX library should provide client-side API functions for application developers who needs to write its own client-side code. Really, jsf.js library is used by some other renderers ( in the Mojarra, it is commandButton / commandLink renderers ) and can't be changed with particular RenderKit or AjaxBehavior renderer. Of course, any extension can load standard jsf.js library and wrap or redefine particular API calls, but what about cases where that library should be replaced ? I understand effort to put all JavaScript code into one library, that reduces number of requests, but, from the other hand, any JSF application has to load whole library even though it not use AJAX functionality at all. Even single commandLink component will include about 100kb of javascript ... AFAIK, JSF spec has well-defined API but should not enforce particular implementation. We can replace at most any object by custom implementation that follows requirements, why client-side library should be exception ? There are options that we would like to have : 1) extended Queue. We have a smart enough implementation and wish to keep that in future releases. It was also designed to work together with Jboss Seam framework. 2) Dynamically append scripts and styles for components that were included into view during AJAX request, so their resources were not rendered with initial request. 3) Connect 'status' component to library so in can display request status for all or only selected components. 4) Log AJAX execution. At the development stage, application developer can use special 'debug' component to analyse requests and updates. 5) Remove event listeners from DOM elements that was replaced during AJAX requests. JavaScript does not have methods to get listeners attached to particular DOM element, but they can prevent DOM objects from destroying by JavaScript engine and cause memory leaks. There is no common way to cleanup removed content, but we can do that for at least our components and most popular libraries. Of course, we can load standard jsf.js library and wrap/replace its methods or register special listeners to provide necessary functionality, but it does not solve special cases ( mobile or portal applications ). N.B. about Mojarra implementation. It replaces the name of "jsf.js" library in the UIViewRoot#ComponentResources collection by "jsf-compressed.js" or "jsf-uncompressed.js" that depends of the project stage, but never specification nor API docs have any mention about that, so component developer can miss already loaded library. I wish to proper divide responsibility between EG and implementations or custom components developers. Specification should provide well-defined API but does not enforce to use particular implementation.

Do not afraid about my questions as a rising problems for JSF 2.0. Of course, all component developers would solve their problems ( and we will do ), but I wish to bring up my concerns, so some of them would be resolved in JSF 2.1 or late... On 09/29/2009 11:28 AM, Jim Driscoll wrote: For my opinion, it would be better to let application developer/deployer to decide, which solution is better for particular case. In the RichFaces, we have up to four possible options for resources. The first one is fine-grained per component script and styles, that is useful for development stage or pages with a few components only. The second option is the single solid library that contains everything from whole component library. This library is big enough ( up to 200k of compressed code ), so we have a tool that builds custom application-wide libraries with only necessary code, and compress them by Yahoo compressor. That option is useful for heavy loaded production sites. Because such sites often use separate servers for static resources, the last option disables resource loading at all, so developer can put them to external server. According to the forum and Red Hat service requests, all these options are used in real applications. Yes, this is true for a small library. Unfortunately, any code have habit to grow, and size of client-side code becomes a problem after a while :-( JSF architecture defines the API for all its components, but let component library or application developer to extend or redefine at most everything. This approach gives us nice flexibility, but including implementation of the JavaScript library into API part breaks it for client-side. JavaScript uses late coupling to resolve names, so it is not important which library is loaded if it contains necessary functions and variables. Some of the previous messages has pointed to client who wants to replace AJAX transport, but I worried pretty much about portlets, that require all JavaScript and style class names to be namespaced, to avoid conflicts between different portlet instances. That could be done easily with EL-expressions parsing in the resources, like: (function(jsf){ ............. jsf.request = function request(source, event, options) { ............. }(window.#{fn:encodeNamespace('jsf')} = {})); And use EL-function to construct JavaScript name on page: #{fn:encodeNamespace('jsf')}(...); to properly encode JavaScript function names. Once again, hardcoded jsf.js library does not allow such processing in the portlet environment. I think these points should be carefully discussed for JSF 2.1. I do not talk about two or more libraries on the same page, but only about a same flexibility for its instance as for JSF factories, handlers, and everything else.

On 09/29/2009 04:00 PM, Jim Driscoll wrote: Yes, that is exactly way that our developers go. Oops, I missed that feature, even thought I try to pay close attention to Mojarra code. Can you tell me function name / line number where it is implemented ? Stylesheets have a same importance for many components, so both of them should be processed in a same way. I do not think what that is possible to do in common way, because it requires to provide patched versions of libraries that know how to register listener to let library to remove it from deleted elements... I do not see a big difference between these sides. Both JavaScript and Java have a similar flexibility, although JavaScript has no way to be type safe. That is why I prefer to define Java API only, similar to behaviors, that encapsulates functionality for both sides, and let its implementation to generate particular client-side code. Yes, of course I agree with that.

On 09/29/2009 04:16 PM, Jim Driscoll wrote: It would be better to delegate choose of particular file, compressed or uncompressed, to ResourceHandler/Resource, and let developers ability to provide compressed version of JavaScript/Stylesheet for production stage. For example, in the production stage, look first for resource with additional ".compressed" or ".production" suffix and, if such resource exists, send its contents instead of the original file.