2:35 a.m.
Ok this is getting into technical details on the api level:
You get a subset of what is given in the link out of the box (I assume since
I do not know the tag exactly), I assume the tag allows to trigger actions
automatically instead of waiting for onClick, and also allows onClick event
hooks for existing components etc...
f:ajax does it for onClick events (or similar events for other controls
which have to react with actions to ui input)
The foundation is there via the execute and option params on
jsf.ajax.request api level. Therefore nothing prevents any complib author,
to add a tag doing auto issuing actionEvents to the server.
All you need to do is to write a component issuing a jsf.ajax.request method
with proper executes, options, and renders set which then has to dispatch an
action event on the server side correctly.
Pretty much what the commandButton and commandLink in conjunction with
f:ajax or manual scripts do, but automatically instead of reacting on
onClick on the client side.
Werner
On Mon, Sep 14, 2009 at 8:01 AM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
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 <http://ocpsoft.com>
Author of PrettyFaces <http://ocpsoft.com/prettyfaces> URL Rewriting for
JSF