On 11/14/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> [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.
... which is nice, but not as nice as actually having the actual
component instance.
> > 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.
Certainly not - but that's just about what we can do today.
If this could scale, you've got more options.
> In inputSuggestAjax, the list of
> possible choices is meaningless. It's not necessary to store in the
> state. Only their final answer is important.
But OTOH, the component - and what model its bound to -
is of course correlated to which list of possible choices make
sense.
It'd be excellent to have:
<t:inputSuggestAjax value="#{theValue}"
possibleValues="#{aListOfPossibleValues}"/>
... and this is worlds simpler than setting up an XMLHttp
endpoint. The problem is that today this simply isn't scalable;
the issue for JSF is making it so.
> 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.
A good candidate for mixing in some component-tree-based AJAX
requests, though you'd certainly want to buffer them up
instead of sending requests on very expand/collapse, unless
you needed extra data sent across (another example of something
that's far easier to achieve with the component tree than without).
BTW, other than following existing hype conventions, what's
the reason for putting "Ajax" in the name of these tags (or,
even worse, Java method names)? The abstraction
(asynchronous granular requests) is what matters, not the
latest rubric or the particular transport protocol.
Cheers,
Adam Winer
