cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: CForms: where and how to specify the suggestion-list?
Date Thu, 22 Sep 2005 19:05:29 GMT
Jason Johnston wrote:

>On Thu, 2005-09-22 at 17:35 +0200, Sylvain Wallez wrote:
>  
>
>>Jason Johnston wrote:
>>    
>>
>>>...
>>>I think this is closest to your last suggested solution above, in that 
>>>it can use any of the existing selection-list builders, but it 
>>>eliminates the need for a specialized pipeline.  Seems cleaner to me, 
>>>though I'm not sure about performance impact.  Just another possibility.
>>>      
>>>
>>I understand your point, but autocomplete is IMO somewhat different from 
>>the current CForms Ajax system.
>>
>>The current Ajax system in CForms is designed to update a number of 
>>areas in the page depending on what widgets have been modified by the 
>>processing of the current request. This means that we _must_ run the 
>>form template because this is where the form layout is defined.
>>
>>Suggestion lists, on the other hand, are decorrelated from the page 
>>template, firstly because they are used later, when the user does some 
>>input in a field
>>    
>>
>
>Sort of like validation error messages? ;-)
>  
>

Not exactly, as validation messages are persistent on the page whereas 
suggestion lists are transient and only last for the time where the user 
is typing.

>>and secondly because displaying a suggestion list has 
>>no impact on the page layout nor on other widgets. 
>>    
>>
>
>I don't get it... displaying the suggestion list is a modification of
>the DOM to display something not originally there, doesn't that count as
>impact on the page layout?  Sure, it's normally shown as a popup on its
>own layer, so it doesn't cause any shifting around of other page
>elements, but that's just one way of rendering it.
>
>It is possible also that it might have an effect on other widgets, if we
>chose to build it in a way that the AJAX request triggered on-value-
>changed event handlers which may affect other parts of the form.  That
>could either be considered a good thing or a bad thing, and could
>certainly be coded either way.
>  
>

The lifetime of a suggestion-list is the time where the user types in 
the input field. When focus is lost, the suggestion-list is removed and 
only a that moment in time the on-value-changed listeners are triggered. 
So their activation don't overlap in time with that of event listeners.

Suggestions are also different from selection lists, as selection list 
must be ready when the page is first displayed, which is not the case of 
suggestions. And contrarily to a selection-list, suggestions depend on 
the current value of the field on which suggestions are to be made.

>>Adding it in the form 
>>template would therefore mean having different sections in the template, 
>>one for the form layout and other for the rendering of suggestion lists.
>>
>>Hence the idea to separate the rendering of suggestion lists in 
>>different pipelines.
>>    
>>
>
>Would it really require separate sections in the template?  I was
>thinking it would be handled entirely by the forms-field-styling XSLT,
>and therefore transparent to the form template except for the styling
>hint.
>
>Perhaps some sample code to illustrate my idea would help (very rough of
>course):
>
>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?

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

>3) The instance XML produced by that widget on the initial request (non-
>AJAX):
>
><fi:field id="theField">
>  ...
>  <fi:styling suggest="true" />
></fi:field>
>  
>

Ok.

>4) The initial HTML result of that template snippet, post-XSLT:
>
><span id="theField">
>  <input id="theField-input" name="theField" value=""
>onkeypress="CForms.getSuggestions(this);" />
>  <span id="theField-suggestions" ... />
></span>
>  
>

Right.

>5) The AJAX request string sent when the user enters "b" in the field:
>
>{continuation-id}.continue?theField=b&cocoon-ajax-suggest=1
>  
>

Ok.

>6) The instance XML produced by that widget in response to the above
>request:
>
><bu:suggest id="theField">
>  <fi:field id="theField">
>    ...
>    <fi:suggestion-list>
>      <fi:item value="Ben" />
>      <fi:item value="Bob" />
>    </fi:suggestion-list>
>  </fi:field>
></bu:suggest>
>(other elements in the template would of course be removed by the BU
>transformer, so this is all that's left.)
>  
>

Yep. But the fact that we know in advance that we'll have to remove all 
except the suggestion-list is what led me to want a different pipeline.

>7) The result of the field styling XSLT:
>
><bu:suggest id="theField">
>  <ul id="theField-suggestions" onclick="..." ...>
>    <li>Ben</li>
>    <li>Bob</li>
>  </ul>
></bu:suggest>
>  
>

Yep.

>8) The client-side JS would then insert that snippet into the DOM in the
>correct spot, and hook up whatever additional event listeners it needs.
>I'm not familiar with the details of Scriptaculous in this regard.
>
>WDYT?
>  
>

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.

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

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message