cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Johnston <>
Subject Re: CForms: where and how to specify the suggestion-list?
Date Thu, 22 Sep 2005 19:51:57 GMT
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! :-)

View raw message