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
