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? ;-)

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

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

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>

3) The instance XML produced by that widget on the initial request (non-
AJAX):

<fi:field id="theField">
  ...
  <fi:styling suggest="true" />
</fi:field>

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>

5) The AJAX request string sent when the user enters "b" in the field:

{continuation-id}.continue?theField=b&cocoon-ajax-suggest=1

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

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>

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?

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.

--Jason

Reply via email to