[jsr-314-open] AJAX library in JSF 2.0

[Lincoln Baxter, III]

The only enhancement I would push for at this time is the ability to
call a server side action method and return a result to the page
javascript. That's really the only thing I see missing:

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=613

Not sure where it stands right now.

--Lincoln

On Sun, 2009-09-13 at 23:53 +0200, Jim Driscoll wrote:

> On 9/13/09 8:26 PM, Ryan de Laplante wrote:
> > What I'm
> > asking is why did the EG not standardize more of what the many JSF AJAX
> > frameworks have created and improved up on over the years. I'm certainly
> > not suggesting you invent new APIs. I'm saying many APIs exist, are
> > proven and battle tested already.
> 
> What APIs are you thinking of?  I could better answer if I had specific 
> examples.  The examples that come to my mind (push, queuing, request 
> aggregation) don't really fit into that category - they're either very 
> library specific, or (IMO) still unproven.
> 
> > I am not very knowledgeable or experienced in AJAX, even with the
> > component libraries for JSF 1.2. Still, from my perspective it looks
> > like only the fundamentals were standardized. Not enough to be fully
> > usable in a full featured UI component library, and therefore it will go
> > mostly unused until it standardizes more of what the major UI component
> > libraries need.
> 
> Among my examples in my blog, I've implemented a polling component, 
> editable text, created a passable shuttle component, and integrated in 
> the YUICalendar widget.  I've even got a clunky Comet example I'll be 
> publishing this week.  In fact, I've not yet come across a use case that 
> CAN'T be solved with the existing framework.  And ICEFaces has certainly 
> indicated that they'll be building their very fancy and capable push on 
> top of the existing APIs in their new release.
> 
> Perhaps if you could suggest specific page actions that can't be 
> implemented using the existing framework, or better, that the existing 
> structure forbids, we could have a more in depth discussion on those 
> points.  I'm sure there must be some, I just don't know what they are. 
> Push, certainly, needs to be standardized, but that doesn't seem to be 
> what the AJAX4JSF guys are doing - and we had good reason for leaving 
> that out this round.  And as I mentioned, I've already got that 
> implemented (badly) using the current APIs, without changes to the base 
> API - and the ICEFaces guys haven't been complaining that I've heard.
> 
> >> The goal of the JSF Ajax framework is to provide an easy to use set of
> >> basic functions which will be built upon by other members of the JSF
> >> ecosystem.
> > I hope that AJAX4JSF is modified so that it builds on top of the JSF
> > standardized APIs instead of being a complete replacement for them.
> 
> That's something that can best to achieved by their customers lobbying 
> the AJAX4JSF people.
> 
> AFAIK, there's nothing to stop them specifically from adopting the 
> current API set - other than their reluctance to rewrite an existing 
> codebase.  But that's based on the one link that you sent on - you'd 
> have to ask them directly if that's true.
> 
> Jim

--
Lincoln Baxter, III
Co-Founder of OcpSoft
Author of PrettyFaces URL Rewriting for JSF


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090914/75017d4f/attachment.html