Version 6
Created by jbalunas on Aug 26, 2010 8:45 AM. Last modified by lfryc on Dec 9, 2010 5:06 PM.

    The RichFaces team, along side the Seam team, are working together to get some important updates into the next version of the JSF specification.

     

    This page will outline the current proposals, and issues, with links to spec issue tracker.  The Seam team maintains their own list here: http://seamframework.org/Documentation/JSF21

     

    Document TODOs:
    • Flush out priorities
    • Find, or create spec issues, and link to from proposal here
    • Remove out of date items

    PartialViewContext Interoperability (P0)

     

    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 need to 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.

     

    Ajax Request Events

    New Event Between Complete and Success (P0)

     

    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 careful logging and debug will be available
    Granular Update Operations

    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. absence 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 functionality 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.
    Hardcoded JavaScript Event Name

    Currently all the event names in js are hardcoded, but we suggest to change this to using constants in order to make wrappers more easily maintainable.

    Event Context Additions

    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.response

     

    • Response 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 response processing. E.g. new request already fired.

    Queue Extension Issues

     

    • Parallel requests not possible at all. Only one queue is available.
      • Resolved as "won't fix" serial queue required to maintain state
    • 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 useful.
      • "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

     

    Plugable JavaScript Client Library

     

    Does it make sense to make JavaScript client library plugable ? 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 plugable modules.
    • Portlets and similar environments. Portlet JSR recommends 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.

    Miscilanious Implementaiton issues

     

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

       

      Clarification of execute=@all

       

       

      Support for generic types in Composite Component's attributes

      http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-916

       

       

      Note: This document very closely related to : JSF Ajax points for discussion with EG

      7389 Views Categories: New Features and Requirements, Release Planning Tags: