Version 8

    This page is a part of RichFaces 4.0 JSF 2.0 Integration

    The RichFaces 4.0 AJAX capabilites should be based on the JSF 2.0 "behavior" and AJAX features to be compatible with other libraries.

    The goals:

    1. Make RichFaces AJAX compatible with JSF 2.0 specification requirements.
    2. Make RichFaces compatible with third-party libraries.
    3. Improve performance.
    4. Make AJAX library portlet-compatible.
    5. ?????? Integrate AJAX feature with Bean Binding (JSR-295) , to make AJAX updates automatically in case of model changes ????????????

    Extended RichFaces AJAX features are:

    1. Design of RichFaces <a4j:queue/> ( TODO : Where is queue article ? - ADDED)
    2. Server based "process" and "update" sets.
    3. Smaller AJAX call JavaScript code to reduce page size.
    4. Better iteration components support ( UIData, trees and iterators ).
    5. Dynamic JavaScript and Style sheets updates ( RichFaces is able to insert new javascript library required by the updated component while default implementation is not ).
    6. Additional RichFaces features: listeners, error handlers, updatable messages etc.
    7. Browser history support
    8. Client-side events for AJAX updates (forum discussion)

    Event Driven AJAX Updates.

    The new JSF 2.0 behaviors could be interpreted as approach to the common event-driven GUI model. The Behavior instance seems as the EventListener bounded to the GUI event on both client and server sides. That hides and simplifies communication proces for application developers, but they still have to manually define parts of page that affected by model updates and should be refreshed on the client, same way as for old Ajax4jsf and RichFaces. But most of modern GUI libraries, like Java Swing or JavaFX have also backward communication channels there binded properties or models fires value change events that update user interface transparently. The idea for RichFaces 4.0 is to introduce such event model for JSF components, these events should mark parts of page 'dirty' and automatically include corresponding component into AJAX response. That can significantly simplify development of rich internet applications without performance costs.

    Framework API should define a default ValueChangeListener object that collects events from models and component handlers ( append and delete cases ) and calculates Id's for partial rendering. User beans would fire sich events from code created by the developer or by the appropriate model classes similar to Swing models, from Jboss Seam interceptors, by  bindings similar to the JavaFX or Bean Binding (JSR-295) . VDL handlers should fire similar events in the case of components tree changes ( thanks to the extensible VDL model, we can extend default functionality ).


    To achieve these goals:

    1. Rewrite a client library with OpenAjax hub support and JSF 2.0 API. This library should be loaded instead of the implementation default. The Javascript code should be based on one library, common for entire project. The jQuery project seems better solution.
      1. Ajax library implementation discussion on our forum.
    2. Create custom <h:form> replacement wich writes only one base AJAX call per form while per-component calls should contain only behavior clientId and additional parameters if any.
    3. Use JSF 2.0 traversals and PartialContext instead of the custom UIViewRoot and ViewHandler.
    4. Transform Ajax4jsf "support" component into the JSF 2.0 "ClientBehavior" implementation.
    5. Make custom AjaxBehaviorRenderer that transform JSF 2.0 calls into RichFaces ones.
    6. Remove Ajax filter from the applications. The original Ajax filter was developed to support old Mozilla brousers which have not had "InnerHTML" property support in XHTML mode at all, therefore is only DOM manipulation was only avalible. The filter transforms any HTML response to the
    7. Rewrite 'a4j:log' and 'a4j:status' components.