JSF server-side AJAX code problems/requests for features

Partial view context interoperability

Partial view context is a new entity in JSF 2.0 serving the purposes of controlling AJAX view processing/rendering. However it appears that you should provide your own implementation in order to be able to use external capabilities of PartialResponseWriter, e.g. rendering of extension elements or addition/removal of elements by AJAX. This can be breaking interoperability of component libraries. Here is an issue against JSF spec. for this: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=658.

JSF Ajax Script problems/requests for features

Ajax Request Events(extension points)

• Currently we have begin, complete, success and errors handlers. We need additional events "between" complete and success events fired for every component update operation. This will be used for
  
  • cleanup client-side objects before element removal on update. In other case we will have memory consumption problem which has no accurate workaround(http://www.jboss.org/index.html?module=bb&op=viewtopic&t=158804)
  • Some component need to perform some initialization before updating it's DOM elements.
  • more carefull logging and debug will be availalbe

• Currently update operations isn't granular at all(relates to previous point). If some error will occurs during update - nothing after this error will be updated. Problems with this:
  • any update error of some element update- causes further update fails. (e.g. absense of some element for update in DOM causes malformed XML exception)
  • If we will clean-up all the objects before DOM update - we will not be able to recover component functionlity after broken update.
  • if we will clean-up the object after DOM update - we could not determine which objects which need to be cleaned-up after success and which were failed and should not be cleaned.
• Currently all the event names in js are hardcoded, but we suggest to change this to using constants in order to make wrappers more easilly maintainable.
• Event handlers should contain request context with next info:
  • options of the request. (e.g. we should know which status component was activated by the request.)

jsf.ajax.request :

• options of jsf.ajax.request function - should contains params as "object containing parameters" according to jsf js-docs. But actually options contains named array of parameters and base parameters(execute, render, etc..)  mixed together. It's not good solution because names of some parameters could cross with base ones.
• possibility to cancel the request according to some conditions

jsf.ajax.responce :

• Responce not contains jsf version. This will probably cause problems with future versions of jsf.
• Need public api to update/remove nodes in order to be used by various third-party frameworks. This will allow to populate events for all  affected listeners.
• Possibility to skip responce processing. E.g. new request already fired.

Queue extension problems

• Parallel requests not possible at all. Only one queue is available.
• Requests could not be combined in jsf queue. (e.g. usage onkeypress as ajax request source.)
  • Also option like request delay needed in order to make "combine" feature more usefull. 
  • "similarity" flag should be added in order to mark requests which should be combined.
• Form serialization problem. jsf serializes form right after jsf.ajax.request() call. But the form could be changed after previous request completion. So we prefer to serialize form before actual request submit. We should send actual viewState to server and not one which was generated after event but before some updates.
• Timeout feature not present at all

Misc problems of current impl:

• Method to get all registered listeners not present.
• Current dynamical scripts loading implementation completelly blocks the IE browser including all opened tabs.
• Dynamical style loading not possible.
• Browser history support not possible currently. Now we're investigating the ways to add this functionality.

After all, is it makes sense to make JavaScript client library pluggable ? possible use-cases that may require custom client library:

• Allow application developer to use different transport. For example, if application used jQuery widgets, developer would use jQuery transport for JSF requests too.
• Vendor-specific extensions. Application developer should be able to decide which implementation he wants to use in the same way as other JSF pluggable modules.
• Portlets and similar environments. Portlet JSR reccommends to prepend all JavaScript functions with portlet namespace to avoid conflicts between portlet instances on the same page. Even more, some portal engines provide vendor-specific AJAX transport or require special URL for such requests.

Current RF Solutions and proposals

Ajax Request Events(extension points)

• currently we could only process clean-ups and general initializations only before/after all the updates occurs.

Queue

Design of richfaces queue: http://www.jboss.org/community/docs/DOC-12894

Jim's article and our comments: http://www.java.net/blog/driscoll/archive/2009/10/19/request-aggregation-jsf-2-ajax

Current implementation works on top of jsf queue and will provide two strategies:

• push - works fully according to "design of richfaces queue" design page and passes requests to jsf.ajax.request - one by one when ready to submit.
• pull - works also according our requirements but passes ready requests to jsf.ajax.request() without waiting when previous complete. (causes their serialization before completion of prev ones.)

Need to choose one way instead of having such options. We propose to define public JS API for queue that will allow to plug in various queuing behaviors. Then we will have no need in our wrapper queue on top of jsf one.