myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Schofield <>
Subject Re: Ajax lifecircle integration
Date Mon, 14 Nov 2005 22:18:11 GMT

> You cannot expect that you want to show the same autocomplete to every
> user that comes in - this really is a very seldom case. You want to
> depicture I18N, session information and user permissions just like
> with a JSF component.

I have been reading up on Craig's remoting solution for the (b) case. 
The o.a.s.r.RemoteCommand sets up the FacesContext for you so you can
access it in your code using FacesContext.getCurrentInstance().

This means that you *can* have some of the JSF goodness without the
overhead of the lifecycle.  You can use method and value binding
expressions as well as locale stuff.

> Remember - the JSF framework was an outcome of seeing  the necessity
> of componentization, state saving, etc. Why should that be any
> different for AJAX components?

Because it may be overkill in some instances.  I don't think an Ajax
component that goes through the entire JSF lifecycle with every
keystroke will scale very well.  In inputSuggestAjax, the list of
possible choices is meaningless.  It's not necessary to store in the
state.  Only their final answer is important.

I agree that more complicated components (like an AjaxTree) would need
to worry about this.  In fact, that is a big PITA right now with tree2
and the client side script.  You need to post back (via a cookie) your
client side state changes so you can sync them up.

> Only exception: the performance is bad. Well, with every new
> technology, the performance was bad in the beginning when taking the
> abstraction to a new level. Then the programmers of the world worked
> hard to find remedies to this. And today, we seldom use Assembler to
> programm ;)

Ah yes but how many Java GUI programs were you writing when Java 1.0.2
was out and all you had was the crappy AWT?

> regards,
> Martin


View raw message