-
1. Re: toward JSF 2.0 and RichFaces 4.0: javascript set
jbalunas Jan 5, 2009 3:19 PM (in response to sergeysmirnov)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
sergeysmirnov Jan 5, 2009 5:14 PM (in response to sergeysmirnov)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
2tcreative Jan 9, 2009 3:09 PM (in response to sergeysmirnov)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
sergeysmirnov Jan 9, 2009 3:24 PM (in response to sergeysmirnov)"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 Jan 14, 2009 4:27 PM (in response to sergeysmirnov)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
sergeysmirnov Jan 14, 2009 6:12 PM (in response to sergeysmirnov)"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.