On Thu, 2005-09-22 at 21:05 +0200, Sylvain Wallez wrote: > >1) The form definition, where the list of possible suggestions is > >defined: > > > ><fd:field id="theField"> > > ... > > <fd:suggestion-list> > > <fd:item value="Ben" /> > > <fd:item value="Bob" /> > > <fd:item value="Chris" /> > > <fd:item value="Doug" /> > > </fd:suggestion-list> > ></fd:field> > > > > > > Ok. But what if it's e.g. a query in the corporate LDAP directory?
JavaSelectionList? Like you said we can use any of the existing selection list builders. > > >2) The form template where we have a styling hint indicating auto- > >suggest is desired: > > > ><ft:widget id="theField"> > > <fi:styling suggest="true" /> > ></ft:widget> > > > > > > Right. BTW, we should not have to write suggest="true" if there is a > suggesion-list. That should be implicit IMO. Yes, true. > Yes, that can work. Now this seems overkill, as the client knows exactly > *what* part of the DOM has to be updated. I mean in this case there's no > need for the browser-update stuff since we know in advance what to > update, contrarily to event-handlers that can potentially impact any > part of the page and therefore require to be able to update several > areas not known in advance. > > Also, suggestions updates must really happen as fast as possible, as > they happen on user's keypresses, i.e. more often than change-listeners > that are triggered by the fied loosing focus. Traversing the full page > template just to keep a single list is in this regard not efficient. Yes, I agree. I suppose it comes down to a tradeoff between efficiency of processing and transparency to the author. I don't like the idea of having to maintain a separate (set of) pipeline(s) for something that should ideally be a transparent part of the framework. Given a choice, though, I'm with you that the end-user experience should trump all. > >I'm not disregarding your proposal of course, and am curious how the > >special pipeline knows how to get to the Field object to generate > >appropriate suggestions? It seems that it would have to call the > >continuation somehow, but I didn't see that in your sample code. > > We don't have to _call_ the continuation as we don't need to validate > the form, but only access this continuation to have access to the form > and from there to the widget and its suggestion-list definition. > > A WebContinuation is actually a webapp scope that sits inbetween session > and request, and we can therefore allow attributes here as well. > > I updated (not committed yet) the flow engine to allow this, and in > form.showForm() the form is stored in a continuation attribute. In the > suggest pipeline, knowing the continuation id we get the continuation > from the ContinuationManager and then get the form. Quite easy from > there on :-) Interesting. I look forward to seeing this come together! :-)
