Return-Path: Delivered-To: apmail-myfaces-users-archive@www.apache.org Received: (qmail 35133 invoked from network); 13 Sep 2006 16:13:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Sep 2006 16:13:44 -0000 Received: (qmail 69822 invoked by uid 500); 13 Sep 2006 16:13:40 -0000 Delivered-To: apmail-myfaces-users-archive@myfaces.apache.org Received: (qmail 69369 invoked by uid 500); 13 Sep 2006 16:13:39 -0000 Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Discussion" Delivered-To: mailing list users@myfaces.apache.org Received: (qmail 69358 invoked by uid 99); 13 Sep 2006 16:13:39 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Sep 2006 09:13:39 -0700 Authentication-Results: idunn.apache.osuosl.org smtp.mail=ABrod@intralinks.com; spf=permerror X-ASF-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE Received-SPF: error (idunn.apache.osuosl.org: domain intralinks.com from 64.18.3.90 cause and error) Received: from ([64.18.3.90:56943] helo=exprod8og54.obsmtp.com) by idunn.apache.osuosl.org (ecelerity 2.1 r(10620)) with ESMTP id E9/40-10194-E3E28054 for ; Wed, 13 Sep 2006 09:13:52 -0700 Received: from source ([12.110.141.25]) by exprod8ob54.obsmtp.com ([64.18.7.12]) with SMTP; Wed, 13 Sep 2006 09:13:29 PDT In-Reply-To: To: "MyFaces Discussion" Subject: RE: AJAX for JSF MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 Message-ID: From: Adam Brod Date: Wed, 13 Sep 2006 12:14:51 -0400 X-MIMETrack: Serialize by Router on IntraMail_MA_01/Intralinks_NY(Release 7.0.1FP1|April 17, 2006) at 09/13/2006 12:14:57 PM, Serialize complete at 09/13/2006 12:14:57 PM Content-Type: multipart/alternative; boundary="=_alternative 00593F74852571E8_=" X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multipart message in MIME format. --=_alternative 00593F74852571E8_= Content-Type: text/plain; charset="US-ASCII" Avatar / Dynamic Faces is not production ready (see the website: jsf-extensions.dev.java.net). However, it does have the backing of many JSF spec members. The Ajax4Jsf team is working with the jsf-extensions team and they have committed to being compatible in the future. So Ajax4Jsf is a great place to start right now. Adam Brod Product Development Team "Frank Russo" 09/12/2006 03:59 PM Please respond to "MyFaces Discussion" To "MyFaces Discussion" cc Subject RE: AJAX for JSF What about the JSF-Extensions project? Isn't the Avatar solution there closer to what will be in the future spec? If so, I think it might be better to start with that. Does anyone know if it is production ready, though? That would be my only concern... Frank Russo Senior Developer FX Alliance, LLC -----Original Message----- From: Aleksei Valikov [mailto:valikov@gmx.net] Sent: Tuesday, September 12, 2006 11:21 AM To: MyFaces Discussion Subject: Re: AJAX for JSF Hi. > AJAX and JSF can definitely work together, but it's tricky because > AJAX can't be added incrementally; it has to be built into the JSF > components themselves. ajax4jsf is capable of adding AJAX functionality to the existing JSF components. That's the incremental addition you talk about. > You might also want to some commercial JSF frameworks that support AJAX. > I've looked at ICEfaces a little and it seemed like it was on the > right track. There may be something along those lines in Oracle ADF > at some point as well. And the status of the open-source ones seem to > change monthly if not weekly. ICEFaces has a pretty nice idea that, I think, can be adapted. They hav so-called direct-to-DOM render kit. That is, components are rendered not as plain text but as a DOM tree. This allows easily identify subtrees that have to be synchronized with the client. What client sees in his browser is just a replication of the server-side DOM tree, synchronized via AJAX. ajax4jsf uses a different approach. When you use AJAX controls from ajax4jsf or ajaxify existing controls with their a4j:support, you provide (1) hook onto client-side event that triggers AJAX synchronization and (2) (possibly via value binding) a ids of the components which have to be rerender. Server-side AJAX handler then renders selected components and sends the result back to the browser. The only problem with existing controls is that they need to be rendered as valid XML in order to be transferrable and parseable on the client side. ICEFaces solves this problem with own render kit (if you render DOM, it's already valid XML after all), ajax4jsf uses JTidy filter to clean up possibly malformed XML produced by components and their renderers. By the way, requiring HTML but not XHTML was in my point of view an awful decision. Otherwise all the JSF component were ajaxifiable out of the box. Bye. /lexi Disclaimer: This electronic mail and any attachments are confidential and may be privileged. If you are not the intended recipient, please notify the sender immediately by replying to this email, and destroy all copies of this email and any attachments. Thank you. --=_alternative 00593F74852571E8_= Content-Type: text/html; charset="US-ASCII"
Avatar  / Dynamic Faces is not production ready (see the website: jsf-extensions.dev.java.net).  However, it does have the backing of many JSF spec members.  The Ajax4Jsf team is working with the jsf-extensions team and they have committed to being compatible in the future.  So Ajax4Jsf is a great place to start right now.

Adam Brod

Product Development Team




"Frank Russo" <frank.russo@FXALL.com>

09/12/2006 03:59 PM
Please respond to
"MyFaces Discussion" <users@myfaces.apache.org>

To
"MyFaces Discussion" <users@myfaces.apache.org>
cc
Subject
RE: AJAX for JSF





What about the JSF-Extensions project? Isn't the Avatar solution there
closer to what will be in the future spec? If so, I think it might be
better to start with that. Does anyone know if it is production ready,
though? That would be my only concern...

Frank Russo
Senior Developer
FX Alliance, LLC


-----Original Message-----
From: Aleksei Valikov [mailto:valikov@gmx.net]
Sent: Tuesday, September 12, 2006 11:21 AM
To: MyFaces Discussion
Subject: Re: AJAX for JSF

Hi.

> AJAX and JSF can definitely work together, but it's tricky because
> AJAX can't be added incrementally; it has to be built into the JSF
> components themselves.

ajax4jsf is capable of adding AJAX functionality to the existing JSF
components.
That's the incremental addition you talk about.

> You might also want to some commercial JSF frameworks that support
AJAX.
>  I've looked at ICEfaces a little and it seemed like it was on the
> right track.  There may be something along those lines in Oracle ADF
> at some point as well.  And the status of the open-source ones seem to

> change monthly if not weekly.

ICEFaces has a pretty nice idea that, I think, can be adapted. They hav
so-called direct-to-DOM render kit. That is, components are rendered not
as plain text but as a DOM tree. This allows easily identify subtrees
that have to be synchronized with the client. What client sees in his
browser is just a replication of the server-side DOM tree, synchronized
via AJAX.

ajax4jsf uses a different approach. When you use AJAX controls from
ajax4jsf or ajaxify existing controls with their a4j:support, you
provide (1) hook onto client-side event that triggers AJAX
synchronization and (2) (possibly via value
binding) a ids of the components which have to be rerender. Server-side
AJAX handler then renders selected components and sends the result back
to the browser.

The only problem with existing controls is that they need to be rendered
as valid XML in order to be transferrable and parseable on the client
side.
ICEFaces solves this problem with own render kit (if you render DOM,
it's already valid XML after all), ajax4jsf uses JTidy filter to clean
up possibly malformed XML produced by components and their renderers.

By the way, requiring HTML but not XHTML was in my point of view an
awful decision. Otherwise all the JSF component were ajaxifiable out of
the box.

Bye.
/lexi



Disclaimer: This electronic mail and any attachments are confidential and may be privileged. If you are not the intended recipient, please notify the sender immediately by replying to this email, and destroy all copies of this email and any attachments. Thank you.

--=_alternative 00593F74852571E8_=--