<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0">
</HEAD>
<BODY>
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:<BR>
<BR>
<A HREF="https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=613">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=613</A><BR>
<BR>
Not sure where it stands right now.<BR>
<BR>
--Lincoln<BR>
<BR>
On Sun, 2009-09-13 at 23:53 +0200, Jim Driscoll wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
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
</PRE>
</BLOCKQUOTE>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
--<BR>
<B>Lincoln Baxter, III</B><BR>
Co-Founder of <A HREF="http://ocpsoft.com">OcpSoft</A><BR>
Author of <A HREF="http://ocpsoft.com/prettyfaces">PrettyFaces</A> URL Rewriting for JSF<BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>