6 Replies Latest reply on Jan 14, 2009 6:12 PM by Sergey Smirnov

    toward JSF 2.0 and RichFaces 4.0: javascript set

    Sergey Smirnov Master


      The current set and usage of the third party javascript libraries has more historical than technical reason.

      RichFaces ( since very first pre-Ajax4jsf library) uses Sarissa library for Ajax interaction. Earlier version of RichFaces (Ajax4jsf part) javascript code used to have less than 40K in total.
      The first components uses prototype.js and libraries based on prototype.js like script.aculo.us
      Than jQuery came to the scene. jQuery is an elegant, light-weight, well-documented, active javascript library with great community support. It avoided some disadvantages that prototype.js has.
      We started with rich:jQuery, then used jQuery come for development of other RichFaces components

      So, as a result, if application uses "ALL" loading script strategy, the total size of the loaded code exceed 400K. I.e. more then ten times bigger that is was at the very beginning.

      In the future RichFaces 4.0 we offer to avoid using Sarissa and prototipe.js (with utilities) and re-factor component and framework modules toward using jQuery

      WDYT?

        • 1. Re: toward JSF 2.0 and RichFaces 4.0: javascript set
          Jay Balunas Master

          I think that this is a great idea - 400K is a lot and standardizing on a single core js lib is important. It will also make it easier for new people in the community to get involved because there will be less learning curve.

          We'll have to investigate who uses what currently, and figure out if there are any missing pieces but something like this would be good for a 4.0.

          -Jay

          • 2. Re: toward JSF 2.0 and RichFaces 4.0: javascript set
            Sergey Smirnov Master

            In general, most components that uses prototype.js uses it implicitly without any public interface. So, replacing the code should not impacting the end application if developers do not try to use the interface code unofficially.

            Developers will still able to use prototype.js if it is used in the application code. Their just need to take care about including the own copy of prototype.js library as far as RichFaces is not going to bundle it.

            rich:effect uses script.aculo.us corresponded feature. jQuery has set of effects that are even richer and easy to use than script.aculo.us's one. However, the way how the effect parameters are set are different. I suggest, using the jQuery way is preferable even it might break the backward compatibility partly if some undocumented features are used hard.

            • 3. Re: toward JSF 2.0 and RichFaces 4.0: javascript set
              Tim Taylor Newbie

              I am relatively new to richFaces and find moving toward a standard js framework for RIA would be desirable. jQuery appears to be a widely accepted framework for 'widgets' and RIA features. Implementation appears easy and straightforward (even I can do it!).

              However, I have run into some problems concerning the 3.2.2 release of RF. I tried to use the jquery tab function in place of the RF tab (tables of the RF vs my own unordered list and stylesheet) but when I loaded the jquery library as a dependency all my RF widgets stopped functioning. I tried the rich:jquery for the initiation of the jquery tabs but to no avail.

              How soon do you think you will have some consolidation done on the jquery replacement?

              • 4. Re: toward JSF 2.0 and RichFaces 4.0: javascript set
                Sergey Smirnov Master

                 

                "2tcreative" wrote:

                However, I have run into some problems concerning the 3.2.2 release of RF. I tried to use the jquery tab function in place of the RF tab (tables of the RF vs my own unordered list and stylesheet) but when I loaded the jquery library as a dependency all my RF widgets stopped functioning.


                If you include your own copy of jQuery and do it after RichFaces extended the jQuery objects, the new instance of lib just overwrites everything.

                • 5. Re: toward JSF 2.0 and RichFaces 4.0: javascript set
                  Vladimir Kovalyuk Apprentice

                  Sergey, does it make sense to develop core js components and build Richfaces on top of them? So it would be easy to write clien-side event handler 'cause we would know js-components API.

                  • 6. Re: toward JSF 2.0 and RichFaces 4.0: javascript set
                    Sergey Smirnov Master

                     

                    "vladimir.kovalyuk" wrote:
                    Sergey, does it make sense to develop core js components and build Richfaces on top of them? So it would be easy to write clien-side event handler 'cause we would know js-components API.


                    Developing each components with rich client side functionality is started with developing a working prototype. If we were developing a js component (let name it js widget for differentiation), the widget is almost done at this moment. However, in case of creating a JSF component, this stage is only the beginning.
                    JSF component is like an iceberg. The 1/10 of it is located invisible under the water (i.e. on the server-side). JSF component is responsible for saving and restoring the state including the visual state, two-ways data binding, event handling, children component rendering and so on.

                    Sometimes, it is reasonable to use a "ready-to-use" js widgets if the license is suitable. It shortcuts the first stage (creating a working prototype), but the rest parts still ahead.