Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Subject: Re: CForms: where and how to specify the suggestion-list?
From: Jason Johnston <jason.johnston@Intrado.com>
To: dev@cocoon.apache.org
In-Reply-To: <43330079.7040900@apache.org>
References: <43327CE1.9000905@apache.org> <4332BD32.6000703@lojjic.net>
	 <4332CF3D.2090304@apache.org> <1127407142.23907.50.camel@jjohnston>
	 <43330079.7040900@apache.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Thu, 22 Sep 2005 13:51:57 -0600
Message-Id: <1127418717.23907.99.camel@jjohnston>
Mime-Version: 1.0

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! :-)