Roadmap and Planning for RichFaces 4.3 and beyond

[bleathem]

With our 4.1.0.Final release at hand, it’s time to discuss what we want to do with RichFaces 4.2, and beyond.  4.1 addressed rounding out the 4.0 effort of migrating the 3.x component set to JSF 2 (and also making the components mobile compatible!).  We need to bring over the last couple remaining components, and identify any features lacking from the existing components, so that we can complete the RichFaces 3.x to 4.x story. 

Some things I’d like to see addressed are:

• RF 3 components -> RF 4
  • contextMenu (currently a sandbox component by Bernard Labno)
  • hotKey (pull request from Ilya Shaikovsky )
• Existing component improvements
  • fileUpload
    • server-side clear event listeners
  • dataTables
    • prevent backing bean evaluation when the table is not rendered
• Seam Forge integration
  • RichFaces plugin with support for both Java EE and servlet projects
  • Look more at RichFaces scaffolding integration
  • CDK plugin for Forge
• JSF 2.2
  • This will be released at some point over the 4.2 release cycle
• HTML 5 & mobile support
  • Framework support for device detection
  • Device specific renderers
  • HTML 5 components
• A new component initiative
  • Accelerate the delivery of new components
  • Standalone js libraries that are integrated with Richfaces
    • js “components” that can be used with other web frameworks
  • Focus on leveraging existing OSS javascript libraries
    • contribute back upstream wherever possible
• Testing
  • Arquillian/Selenium 2 based tests
• What else?

The idea behind this new component initiative is to create a component set that is more focused on rapid component development by leveraging existing OSS javascript projects - and contributing back upstream to those projects wherever possible. 

I want to be clear up front that this in no way implies we are giving up on the existing components - they are here to stay, and we will continue adding to and improving them as necessary.  This is moreso about looking for a more streamlined way to deliver new components that address more use cases.

A proof-of-concept can be seen in my recent CDK blog series.  There are still however many more details to be worked out, such as:

• The javascript development model
  • I’d like to see js development done as jQuery plugins
    • this would make it easier to “onboard” new developers and solicit contributions from the community
  • Bridge the events from the standalone javascript components into JSF behaviours (as required)
• Re-use existing code from the current component set
  • this will likely involve moving some of the renderer base classes into ui-common.
• Our themeing story
  • All components in this new component set should be easily and consistently themed
  • The current components should have a skin to ensure interoperability of all RichFaces components

In short, further prototyping is required!  We’ll setup a github repository to house these efforts once we get the 4.2 effort underway.  Thoughts and ideas are welcome as always!

Looking forward to hearing your feddback on what you’d like to see in RichFaces 4.2...

Message was edited by: Lukáš Fryč (Renamed to RichFaces 4.3)

[vrelits]

Firstly I would like some focus on fixing bugs. I still have some real showstoppers, especially with regard to collapsibleSubTable. When you look at 4.2 tracking there is a lot of end user bug reports that I think should have been adressed well before a 4.2 release.

Secondly I would like focus on existing ajax functionality with regard to performance. It seems a lot of the components in ajax mode doesn't really give any boost in performance because the backend beans are always called no matter what. An example is collapsiblePanel and collapsibleSubTable.

Thirdly I would like enhancement of the most used component: dataTable. Easier sorting, filtering, exporting and this also on server side (It must be possible to do this simpler than today, where a lot of coding is required).

And better documentation too. RF 4 documentation is not up to RF 3 level, and the component reference does even not describe the different attributes and the possible values (and default values).

Then, lastly, after all the above stuff is fixed, I would like the following new components: contextMenu and a focus component. Focus of fields seems to be a totally unadressed issue in Richfaces.

[bleathem]

Thanks for the feedback Jesper.  We strive to achieve a good balance between fixing issues, and providing new components.  We've fixed a lot of issues in the 4.1 release, and we'll continue to fix more, with a priority given to the more common use-cases and scenarios.  We do however have to continue to provide new features and components that developers are looking for, to build their applications.

I agree that we need to address the ajax lazy-loading issue.  I touched on that with my comment about the lazy-loading of data tables.  I expect there is a systematic fix that can be applied here, resolving the lazy-loading issue with all effected components similarly.  We've started using the "lazy-loaded" label on issues that address this.

For data tables, i see issues

• RF-8125: Tables: built-in sorting/filtering
• RF-7878: Tables: client-side sorting/filtering
• RF-9153: CSV export component of rich:dataTable/rich:extendedDataTable

If these are of significant interest to the community, let's see if we can get some more activity on the issues in the form of votes, watchers, and suggestions in the comments.

We've identified the VDL tag doc as requiring some work to fill out the attribute descriptions and default values, and the migration guide needs a detailed run through to make sure it's accurate.  Other than that, I feel the documentation is in pretty good shape for 4.1.  What areas specifically do you feel the 4.x docs are lacking compared to the 3.x docs?

ContextMenu (RF-10197) is a highly voted issue, and preventing a lot of folks from migrating off of RichFaces 3.  It's one we are hoping to get in ASAP.  Your comments about a focus component are great, but RF-8606 isn't seeing a lot of attention.  Perhaps this discussion will serve to highlight the need for the component.

Thanks again for your feedback, and I hope you appreciate the balance between features and fixes we are striving for.

[blabno]

Jesper, thanks for feedback. Have you seen this page : http://community.jboss.org/wiki/4XSandboxComponents. There is a focus component for RF3.X and for RF 4.X it says "Download: not available yet (community feedback required)".

If you need it so much, just drop a comment at appropriate thread.

Also contextmenu is available in sandbox.

Brian,

I think it's great you are open to rapid component development. This is where PrimeFaces was beating RF. They just were grabbing existing jQuery plugins and were adding  JSF backend (very,very poorly). I think that sandbox is a place for this. Currenlty keruke is working on creating sandbox assembly so that we could release whole bunch together.

We must realize that current CDK guides and documentation are not enough (especially for beginners) and this should be primary issue if we want to attract more developers to contribute.

You can count on me in further sandbox initiatives. Creating RF components is a pleasure.

[clerum]

Currently RF is lacking a way to search for a POJO via an autocomplete method and select a POJO to a backing bean value.

rich:select does not have an autocomplete method and rich:autocomplete is meant for text

https://issues.jboss.org/browse/RF-11453

What would be great to see here is a component like the JIRA version select.

Being able to select one POJO via an autocomplete method and be able to clear it is a must.

Ability to support a multiselect would also be nice but not mandatory.

[bleathem]

Bernard, thanks for the feedback, it's great to hear that this is an initiative in which you'd like to be involved.

I think the we should definitely follow the Sandbox model with this idea for a new component set - but we can't call it a "Sandbox"

In all seriousness, I'd really like to see this component set setup in a way to facilitate community contributions, and the sandbox will play a key role in providing a communal playground where we can see what works, and what doesn't.  As components mature in the sanbox, they will graduate to this new component set, where they will be assured of meeting a well defined standard in terms of code style, visual style, interoperability, QE verification, tests, etc, with a well versioned release scheme.

The first step in the process is to migrate the sandbox from subversion to git, something I hope we'll have resolved shortly.  We can then use the sanbox to prototype excatly how we want the new components to be laid out.

Lastly, I agree the CDK docs are insufficient.  All current CDK docs are listed here:

http://community.jboss.org/wiki/RichFacesCDKHowTos

but we definetely need to make this more cohesive and complete.

[bleathem]

Cody, indeed you've pointed out a hole in the coverage of our current component set.  An object based autocomplete component would make a good addition to the 4.2 compoennts.  It should not be a complex process to port the autocomplete logic from the autocomplete component to the select component.  We'll just have to make sure we keep the code DRY as much as possible while doing so.

[cagatay]

This is where PrimeFaces was beating RF. They just were grabbing existing jQuery plugins and were adding  JSF backend (very,very poorly).

Can you give me an example of how poor it is Bernard?

Brian, congrats on becoming the RichFaces lead by the way.

[blabno]

Cagaty,

ImageCropper requires image to be on context path and not from some bean attribute. Why did you limit this awsome tool to cropping? Check out ImageSelectTool, it's much more flexible.

Dashboard requires some special datamodel. It could use any datamodel or list (anything acceptable by JSF iterating components), check out RF sandbox Dashboard.

Dock requires some p:menuItem children while it could accept much more like RF sandbox Dock. Currently we're limited to JSF submit (by providing action) or to raw URL, with no place for sth like s:link.

Please don't be offended by my previous post. If it hurt you, I apologize. PrimeFaces is great inspiration to me, but it is like pre-sandbox. We've tried using it in our projects, and it was great for building great looking prototypes (view layer only) way fast, but when it came to plumbing data and more complex functionalities we were hitting the wall.

[cagatay]

Hi Bernard,

I guess you were using a very old version;

- ImageCropper can crop images in context, external web pages whose value you can retrieve from beans.

- DashboardModel could be a list but DashboardModel is still handy as it defines the model fine grained, we have a DashboardColumn to represent a table column whereas a using nested lists might be a bit confusing. Model API is added so we can extend it in feature to implement sth like portlets. So I think it is a matter of preference.

- Not sure, I don't see anyone who needed custom content in dock. It is a menu in the end, but you can place custom content inside p:menuitem, if you have a menuitem with a child, menuitem just renders that so you can place an s:link inside a dock.

Please don't be offended by my previous post. If it hurt you, I apologize. PrimeFaces is great inspiration to me, but it is like pre-sandbox. We've tried using it in our projects, and it was great for building great looking prototypes (view layer only) way fast, but when it came to plumbing data and more complex functionalities we were hitting the wall.

We are using PrimeFaces in a couple of client projects and thousands also do, I know many happy users of course no framework is a silver bullet, maybe you were using an older version with some issues, PF is really improved with 3.x. I've realized that your work in RichFaces Sandbox was inspired by PrimeFaces, it is good to hear that from you as well.

Anyway, this topic is about RichFaces Roadmap, I shall not continue writing about PrimeFaces.

@Brian, if you are open to discussions for compatibility between Rich and Prime, I'm ok with that. I guess all the problems I heard are because of both libraries using jQuery, I think that could be fixed if we include jQuery once, hopefully the same version

Good luck with RichFaces!

[lfryc]

Bernard, Cagatay, I would like to ask you for staying strictly technical here, this is Development related forum.

[blabno]

How about putting jquery in the same folder in both rich and prime jars?

library="jquery.com" name="jquery.js"

Or let's even create separate project which produces "jquery.jar" and it could contain all the jquery related resources (css,js,img).

[blabno]

Yes Sir!

[lfryc]

Hi Catagay, Bernard,

I have opened new thread for addressing interoperability: Working towards RichFaces / PrimeFaces compatibility

[lfryc]

What I would like to address...

...from component level view?

• leverage JavaScript-based component libraries
• HTML5 based components
• enable component initialization on page-load (using JavaScriptService class)

...from CDK point of view?

• rapid development turnaround with CDK
  • incremental compilation
  • hot-deployment

...from programming model view?

• employ CDI mechanisms to address lacks in JSF programming model
• enhance programming model to enable moving more control to client-side
  • behaviors like rich:componentControl is the base
• enhance programming model for addressing mobile devices needs
• extended partial component rendering
  • currently having e.g. table@body
  • other components are candidates: tabPanel@tabs, tabPanel@body
• simplification of dynamic contruction of views
  • fluent API for view construction

...from JSF impl gaps point view?

• validate the generated code against Yahoo performance recommendations
  • and address the issues on the framework level
• support for multiple events in behaviors
• dynamic addition of components
  • resources are not rendered correctly for AJAX requests

...from Tooling point of view?

• Forge plugins
  • for both RF and CDK
• JBoss Tools IDE - address some drawbacks when developing in IDE
  • component ID recognition in order to validate the tree, navigate quickly through tree and for ID autocompletion

...from Test tools point of view?

• Arquillian Ajocado extension
  • support for Selenium 2
  • simple testing of Ajax/WebSockets
  • testable component model
    • encapsulating Selenium actions under high-level API (designed from component user point of view)
  • auditing
    • standard compliance
    • performance rules compliance
• Arquillian JSFUnit
  • support for Selenium 2
  • enabling lifecycle phases testing
  • enabling spying on JSF API objects
• Arquillian Drone
  • support for managing lifecycle of mobile devices
• automated visual testing
  • Arquillian RushEye (incubation)
• testing UI components separately (with no server bindings)
  • running qunit tests using Arquillian Drone
• targetting rapid UI test development
  • tests running from IDE