myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Schofield <sean.schofi...@gmail.com>
Subject Re: Ajax lifecircle integration
Date Tue, 15 Nov 2005 03:41:34 GMT
On 11/14/05, Adam Winer <awiner@gmail.com> wrote:
> On 11/14/05, Sean Schofield <sean.schofield@gmail.com> 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.

In the case of inputSuggestAjax we don't need the component instance. 
We just want a refined list of possible choices based on the user's
latest keystroke.  I think the Tomahawk components that use Ajax will
want to allow this option.

> > > 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.

But for right now we need something other then complete JSF lifecycle
for certain ajax components.  So what do we do about that in the here
and now?

My suggestion is that we don't require a JSF postback every keystroke.
 I think we can modify inputSuggestAjax and other similar components
that fall under the (b) case and make them more flexible.  Allow the
user to use Shale's remote command if they want to.  Don't lock them
into the full JSF lifecycle.

> >  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).

I thought about the buffering issue.  While it speeds things up, it
also certainly complicates things.  For large trees, the client-side
toggle is too slow (especially on IE browsers.)  So some type of Ajax
solution would be nice.  I'd definitely consider working on an Ajax
tree with anyone who was interested.  I just don't want to get stuck
doing all of the work myself.

> 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.

Well I had already contributed an inputSuggest to the sandbox that did
*not* use Ajax.  So the authors of this one decided to distinguish it.
 I've lost interest in the original inputSuggest, however, because its
just not very good with large lists (too slow.)  It has some good
javascript and DHTML that we can make use of in the Ajax version but
perhaps its time to abandon it.

I'm ok with dropping "ajax" from the names but you'll have to convince
a bunch of others.

> Cheers,
> Adam Winer

sean

Mime
View raw message