Requirements for a new component set

[bleathem]

As discussed in the ongoing RichFaces 4.Next discussion, we are looking to start work on a new component set to address providing components with a faster turnaround.  (I'd like to remind everyone that development will continue on the exisitng component set, both in terms of fixes, as well as adding new components).  This new comopnent set will leverage existing javascript libraries wherever possible, with the goal of committing upstream any fixes/enhancements we make to those libraries.

The purpose of this discussion is to come up with a consistent component design, to ensure the components are extensible and maintainable moving forward.  Some ideas I have:

1. We should have a list of preferred upstream projects where we pull javascript source from ("blessed" upstream projects)
   • This will aid in skinning efforts
   • This will make upstream contributions easier to track and maintain
2. Components should be consistently themable
   
   • As is the case with our current component set, the components should be consistently themed
     
   • We'll need a consistent theming approach or compatibility that can be applied to whatever upstream projects we "bless"
3. The components should be well tested
   • Tested independently and throughly at the javascript level
   • The interaction with the JSF and RichFaces should be tested with Arquillian and appropriate extensions
   • There is room for an entire discussion on it's own of how to test the components, we'll start such a discussion in a another thread shortly)
4. The component should be fully functional as a standalone javascript "widget" (jQuery Plugin)
   • This would allow the widget to be re-used with other web frameworks, allowing those of us creating mult-framework/language web apps to have a consistent L&F accross our application
   • Widgets shoudl have a well-defined and documented client-side API to allow RichFaces components and other web frameworks to interact with the widget
   • The widget should be coded in the pattern of a jQuery plugin, to ease on-borading of new devs, and facilitate consumption by other frameworks
5. All components should use the RichFaces CDK wherever possible
   • This gives a consistent programming model accross all out components

Let's continure the brainstorm, and grow this list of possible requirements! -- we'll follow up in a few weeks with a wiki page detailing the results of this discussion.

Brian

[lfryc]

Hi Brian,

great overview, I would add:

Minimal efforts when wrapping component with RichFaces CDK

• JSF can create the component DOM and call appropriate component constructor
• RichFaces calls component destructor when removing component DOM (when re-rendering)
• preferably this should be achieved with almost no effort