Yes - I needed to make a distinction between the inputSuggest that
originally was there and the AJAXified version.
Of course, it would be better to don't reflect that in the name.
As for the performance: there is work in progress to change the
available HTTP-Servers to better cope with frequent request which
deliver small data - that might help in the future.
regards,
Martin
On 11/15/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> On 11/14/05, Adam Winer <[EMAIL PROTECTED]> wrote:
> > 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.
>
> 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
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
