Direct-to-DOM-Rendering ?

[nimo22]

In compare to IceFaces, Ajax in RichFaces is not rendered by Direct-to-Dom.

So much manual effort must be made to synchronize events.
Also we have to declare explicitly, what should be reRendered and in which order (rich:queue) and so on to avoid things like Traffic Floods or the message: "The conversation ended, timed out or was processing another request"

Is there a plan to redenominate to Direct-to-Dom-Rendering in RichFaces?
Maybe richfaces version 4 or the like??

And when not, why? Is it better to have not Direct-to-Dom?

I mean, it is really lengthy and time-expensive to declare all the reRender-Attributes, selfRendered, the queue, the ajaxSingle, the requestDelay and so on. It can became very complex and very un-manageable to maintain the overview of what components are in these queues or in that or in reRender-Lists or the kind.

Is it better to have not Direct-to-Dom? Why?

[tedgoddard]

Of course, this is not the sort of reply they are looking for on the RichFaces forum; but why not just use ICEfaces?

[nbelaevski]

Hello,

Is there a plan to redenominate to Direct-to-Dom-Rendering in RichFaces?
Maybe richfaces version 4 or the like??

Looks like this feature is not very popular among community, it's absent here: http://labs.jboss.com/wiki/RichFacesFuture
and there: http://jboss.com/index.html?module=bb&op=viewtopic&t=118648.
Please cast your vote for it if you like it: http://labs.jboss.com/wiki/RichFacesFuture

More on the topic: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=135643

[alexsmirnov]

Each engineering task is all about compromise, and JSF frameworks are not exceptions.
Direct to dom approach is much simple for development, but it has its own costs:
1) application has to keep rendered dom content in addition to every components tree state, what means memory consumption. For the browser 'back' button support, the history should be long enough.
2) For correct comparison, An entire components tree has to be rendered at every request, even thought is only one component was changed. There is little way for performance optimization.
3) Two consequence dom trees has to be compared element by element ( really, character by character ).
On the other hand, the RichFaces architecture requires a much more from application developer, but it allows developer to optimize application code as well.
We are not going to migrate to direct-to-dom like architecture, but have a plan to simplified application development from different point of view. JSF component rare change rendering code from their different logic. Usually, a generated HTML code depends from beans or component attributes. Therefore, changes in the beans or attributes is closest point to detect components for update, which can be detected from two-way 'binding' approach, as defined in the 'Bean binding' JSR 227.
I'm not sure about RichFaces 4.0, but we are going to integrate RichFaces with JSR-227 or use JavaFX with their 'binding' features as page description language.

[nimo22]

Hello,

Thank you for your respond.

..have a plan to simplified application development from different point of view..

I had thought about a graphical tool which shows the order of ajax-calls or gives a abstract overall as a graph or the like - but for now, the a4j:log does it well:-)

I like richfaces very well - the components are amazing and the ideas behind are great - JSR-227 or JavaFX is the right way to go. By the way, the richfaces-team is very helpfull and nice!!

bye