Version 15
Created by alexsmirnov on Nov 26, 2008 6:11 PM. Last modified by alexsmirnov on Jul 1, 2010 1:57 AM.

    JSF 2.0 – RichFaces integration plan.

    Test environment

    It is important to use test-driven development for a new features. Because current Shale-test framework does not have JSF-2.0 versions of the mock objects, and due to often JSF API changes during development phase, we need to have a powerful test environment for the framework and components. New jsf-test project works like existing Shale tests, but uses “stub” webserver and  a real JSF implementation.Tasks:

    1. Create Mock webserver with JSF support. DONE: Test Driven JSF Development

    2. Integrate test framework with HtmlUnit, jWebUnit or an other      framework for components rendering and Javascript tests. DONE

    3. Rewrite existing abstract test classes for a new framework.

    4. Setup Real World automated test project using Selenium test framework...

    CDK

    Component Development Kit is base for entire RichFaces components library, therefore rewriting  it should be first stage of migration process.

    RichFaces 4.0 Components Development Kit

    AJAX framework

    RichFaces 4.0 AJAX

    Probably, it is hardest part of the transition.

     

    Framework

    Base

    1. Properly divide api, implementation and component library. The library itself should depends from the 'api' only. Common components classes should be moved into the library.(https://jira.jboss.org/jira/browse/RF-7560)
    2. Use standard JSF 2.0 ExceptionHandler.
    3. DataModel classes - support new JSF 2.0 iterator() method.
    4. Use JSF 2.0 system events instead of custom listener/tree walkers.

    Initialization

    1. Move initialization code into JSF 2.0 system listener. Move all "lazy" loading into application startup. If necessary, use javax.nio locking instead of "syncronized" (https://jira.jboss.org/jira/browse/RFPL-12)
    2. Add support for hot redeployment, as JSF 2.0 does.
    3. Move all configuration parameter names into the ContextInitParameters utility class constants. Use that class instead of direct init parameters references. (https://jira.jboss.org/jira/browse/RFPL-13)
    4. Use Faces-config extentions instead of the init parameters for a complex cases ( two or more related parameters ). (https://jira.jboss.org/jira/browse/RFPL-14)
    5. Use single 'Configuration' class to access for all parameters by single point.(https://jira.jboss.org/jira/browse/RFPL-15)

     

    Skins

    1. Reduce the number of the style classes. Merge internal names with public ones.
    2. Make skin style class names portal-compatible by passing them with ExternalContext.encodeNamespace() method. (https://jira.jboss.org/jira/browse/RF-7573)

    Resources

    1. Transform RichFaces resources to use JSF 2.0 Resource Handling instead of Richfaces filter. The extended ResourceHandler should serve dynamic RichFaces resources and delegate other requests for default one.(https://jira.jboss.org/jira/browse/RF-7562)
    2. Transform RichFaces InternetResource interface into JSF 2.0 Resource abstract class. (https://jira.jboss.org/jira/browse/RF-7563)
    3. Move the Renderer dependend resources definitions from propietary interface to the JSF 2.0 annotations. (https://jira.jboss.org/jira/browse/RFPL-21) Implemented in JSF itself
    4. Inject resources by the JSF 2.0 UIViewRoot#addComponentResource instead of filter. It seems as JSF 2.0 bug what that API does not preserve scripts and styles order. (https://jira.jboss.org/jira/browse/RFPL-22) Implemented in JSF itself
    5. Dynamic Resources. Current JSF implementation supports a static files only. (https://jira.jboss.org/jira/browse/RF-7566)
    6. Proprietary "xcss" stylesheet-description language should be replaced by the native CSS with EL-expressions and conditional elements. Possible way - define custom PDL handler for CSS format, as it exists in the JSF 2.0 Facelets-based one for a XML. (https://jira.jboss.org/jira/browse/RF-7567)
    7. Process EL-expressions in JavaScript files. Implemented in JSF itself
    8. Replace runtime images rendering by pre-generated static images ( nice idea to use SVG and maven batic plugin to prepare them ), but only apply color transformation directly to PNG file content. For example, each skin color could be rendered into separate channel ( Red, Green or Blue, RichFaces skins do not use more than 3 colors for images ) and use channel value as intencity of actual color. That would eliminate AWT dependencies from runtime and solve compatibility problems.

     

    Client-side library

    Rewrite components JavaScript and HTML code to reduce a number of JavaScript libraries dependencies ( after a long development we have  dependencies from the Sarissa, Prototype, Scriptaculos, JQuery and a lot of duplicated functionality ):

    1. Use only one base library (JQuery is most preferable at this moment). (https://jira.jboss.org/jira/browse/RF-7569)
    2. Move duplicated code into the global library. (https://jira.jboss.org/jira/browse/RF-7570)
    3. Make code compatible with Portlet environment: use anonimous functions to hide internal code, pass all public methods names with ExternalContext.encodeNamespace(). (https://jira.jboss.org/jira/browse/RF-7571)
    4. Public JavaScript components API
    5. If possible, insert all RichFaces libraries at the page end as Yahoo recommends (https://jira.jboss.org/jira/browse/RF-7572)
    6. Pluggable/Configurable effects for components.
      1. We should consider that during design. Current 3.3.x (and older) components designe does not allow to plug effects on changing state.
    7. Advanced keyboard and accessibility support
      1. The same as for 6). Default keyboards shortcuts should present on components (all menus, trees, selection on tables, rich inputs and so on), need to design points and api to be able to attach shortcuts usign hotkey.

     

    Utility classes

    Review a number of utility classes used. Remove obsolette packages :

    1. XML serializer. (https://jira.jboss.org/jira/browse/RF-7553)
    2. JTidy (https://jira.jboss.org/jira/browse/RF-7554)
    3. Gif image format SPI ( included in the JDK 5 and late ). (https://jira.jboss.org/jira/browse/RF-7555)
    4. Remove Apache common-collections dependencies. Use google-collections instead or create own project-specific classes. (https://jira.jboss.org/jira/browse/RF-7556)
    5. Remove Jakarta Digitester dependencies. (https://jira.jboss.org/jira/browse/RF-7557)
    6. Review BaseRenderer/RendererUtils etc. Remove obsolette code from them. (https://jira.jboss.org/jira/browse/RFPL-41)
    7. Remove commons-logging. Create logger supporting various logging contexts. (https://jira.jboss.org/jira/browse/RF-7559)
    8. Remove obsolette JSF extensions ( listeners, StateManager etc ). Replace Components Tree walk, used by the RichFaces paginator and some other components by the JSF 2.0 events.

     

    Components

    1. Code rewiew and optimization.
    2. ??? separate iteration components ( tables, repeater, tree ... ) from UIData. (https://jira.jboss.org/jira/browse/RFPL-39)
    3. Performance improvment.
    4. Redesign components with semantic markup. Avoid <table> tags where it is reasonable
    5. Rewrite client-side markup and JavaScript.
    6. Use new JSF 2.0 features ( new System Events, methods etc )  to optimize components code. Use UIComponent#vistTree method to support virtual components inside iterables (e.g. support tabs inside ui:repeat etc.).
    7. Add built-in mouse hover effect where it is applicable
    8. Add built-in effects where it is applicable

    Functions

    1. Add support for current component context inside rich:* functions.