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