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

[Werner Punz]

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 at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090914/2b2a176d/attachment.html