Client-Side Ajax vs Server-Side Ajax

[mehdiabn]

I need to know about compatibility of jQuery and/or Prototype, Dojo, MooTools with some server-side frameworks(like JSF + Richfaces, which are my goals).
I’m researching about the compatibility of them and also the possibility of replacing the Ajax-based server-side libraries with a client-side one (as mentioned above).
On the other word, actually, I'm researching about Richfaces's lacks in client-side JavaScript (both simple and Ajax based).

[sergeysmirnov]

jQuery and Prototype are parts of RichFaces.

JSF has two fundamental parts:
1. Component tree
2. 6 phase Lifecycle

What you see in the browser is a representation of the component tree. RichFaces' Ajax keeps the browser's representation and component tree in sync. Each Ajax request is a standard JSF request, but applied to the part of the component tree. Request is passing JSF lifecycle, including validation and convention, updating model and invoking the application logic. RichFaces' Ajax response is a synchronization of the browser's representation with the changes made in the component tree based on the Ajax request.

Developing RichFaces component (including the one based on jQuery or Prototype.js), we are starting with client-side prototype. This prototype shows how the component should look and how should interact on the client side. For Client Side Widgets, this is a final destination. However, for the RichFaces' component , it is just a 1/10 on the way to go. The component should care about state saving, data or/and component building, plugging two-way conversion and validation and so on, so far.

Can Dojo and MooTools widgets be compatible with JSF. Sure, Why not. It just depends on the your personal effort.
They have no idea about component tree and lifecycle. So, you have a dilemma: to have a 9/10 work still ahead or just forget about JSF.

P.S. Usually, developing end applications, people do not care about blue print JSF architecture approaches. Application might work even without them. Further modifications, upgradings, scalability? Who cares when deadline is close! So, frankly speaking, it takes much less then 9/10 to make it working on practice.

[mehdiabn]

thanks Sergey, your detailed answer encouraged me to ask you more.
Let me tell about one of my problem as a scenario. Think about a table with editable cells or rows. As Richfaces, we need one request per each cell/row editing, which is not my prefer. Instead, I would prefer that client be able to edit more than one cells/rows of tables (as need), and after all, send whole table to the server as just one request.
Also, I need a more ability in UI customization as it's exist in Richfaces (by refer to JavaScript).
At the end, let me ask you a question. As your mind, which stack is preferable, JSF+Richfaces or JSF+one of those framework (JQuery, ...)?

again, thanks for your help.

[sergeysmirnov]

RichFaces dataTable has no cell editing functionality out of the box. I am not sure I understand why you ask how to prevent the unimplemented behavior.

http://livedemo.exadel.com/richfaces-demo/richfaces/jQuery.jsf?c=jQuery&tab=usage shows how four lines of jQuery add functionality to the dataTable that does not exist out of the box.
However, be aware that in case you re-render the whole table of part of it, the DOM nodes are replaced (deleted and created from scratch). So, you need to re-apply the queries to avoid losses.

Preferences depend of many factors including your personal experience and priority, using other technologies and so on. Personally, I prefer jQuery as a very easy and elegant way to make client side behavior much richer. This is why jQuery is a part of RichFaces and widely used inside latest RichFaces components.

[mehdiabn]

Sergey
Thanks, thanks, and more...