[snip] > 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 sean
