3 Replies Latest reply on Aug 30, 2012 10:58 AM by Brian Leathem

    Richfaces 5, migration path

    gonzalad Apprentice



      We're just migrating from RF 3.x to RF 4.x in my company. The process is not trivial.


      I just looked at the comment on https://issues.jboss.org/browse/RF-11453.

      Apparently RF next-gen component suite is going to be based on bootstrap.

      And I'm worrying about the migration path difficulty (CSS / DOM completely changed) - it appears to me to be similar to RF 3.x to RF 4x.


      Ok, on first versions RF 4.x components and BS RF Components will be usabled side by side.

      But what's next ? What's the expected lifetime of RF 4.x before I have to migrate to RF 5.x (RF BS ?) ?

      Is there a way to ease the future migration ?



        • 1. Re: Richfaces 5, migration path
          Brian Leathem Master

          Right now the RichFaces Bootstrap effort is very much a Sandbox project where we are experimenting with some new approaches for delivering new components.  This approach is unique for two significant reasons:

          1. Components are based on stand-alone JavaScript widgets - so they will be reusable across multiple backend technologies, allowing you to give your users a consistent L&F across your polyglot/poly-framework web applications
          2. Components are built leveraging existing OSS widgets to allow us to work with the more diverse upstream JavaScript projects, and enable us to reduce our overhead in keeping our components up-to-date with new browsers, as well as improving support for older browsers


          How we will deliver these new components as a released project is not yet clear.  One possibility is to spin them as RichFaces 5, as you suggested above.  If we did follow this approach, the migration to these components would be easier than the migration from RF 3, as both our Bootstrap components and the current components are based on JSF 2.x.  A big reason the RF3 -> RF4 migration is so tricky is the degree to which the underlying JSF APIs and implementation changed, particularly w.r.t. AJAX.


          There is another possibility I would like to explore, and that is a gradual replacement of the existing JavaScript implementations in the current components with the newer JavaScript implementation from the bootstrap project.  Take the new Bootstrap orderingList for instance.  The JSF back-end for this component uses the same bits as the current orderingList component, it is merely the html rendering and the JavaScript implementation that have changed.  Yet the new widget is much more feature rich, with strong support for drag and drop, and built on an underlying JavaScript framework (jQuery UI) that is in use in many more projects than any JSF component suite.  The only step required to make this work today is to put the hooks in place to get the existing CSS classes in place in the new widget - something we will look into in the near future.


          Finally, RichFaces is a community driven OSS project.  If you (or anyone else) are keen to make sure the migration path moving forwards suits your needs, get involved in the development of the new components and help us make sure they are headed in a direction that will be useful to you!


          Brian Leathem

          • 2. Re: Richfaces 5, migration path
            gonzalad Apprentice

            Thanks for the clarification Brian !


            The only step required to make this work today is to put the hooks in place to get the existing CSS classes in place in the new widget - something we will look into in the near future.


            Yes, I imagine you'll need to create a RF theme for bootstrap or jQuery UI components ?

            Or add RF CSS classes to those components ? (but in this case, it will be harder for you to merge jQuery UI / BS evolutions)

            • 3. Re: Richfaces 5, migration path
              Brian Leathem Master

              In our new js-widget approach to building JSF components, where we want the widgets to be usable from other web frameworks/languages, I now consider the initial markup of the widget to be API, and we are being careful to keep that initial markup clear, concise, and semantic.  To enable this, we are doing some DOM manipulation at the JavaScript level, adding the required elements and classes to create a fully functioning widget.  As such, it should not be a problem to create a small JavaScript shim to add the existing rf-* CSS classes to those components.  This would maximize the compatibility of the new widget when replacing the old one, as well as keep the themeing approach across the current components consistent.


              Given that we could align the JavaScript widgets in this way, I think it will be the themeing approach that sets apart the current components from the Bootstrap components in the end.  The LESS approach takes a lot of the ideas found in ECSS and improves on them, providing an overall much more powerful approach to style and themes.  It also allows the RichFaces community to tap into and participate in the larger Bootstrap/LESS themeing community (see http://bootswatch.com/ for instance).