Client-side data or server-side data ?

Like said previously, a decision has to be made when this kind of widgets are used: where does the data that feeds the popup panel live ?

That's a topic you can talk about for hours with Paul Everitt, who is a preacher of the full client-side approach. In his demos, Paul loads data at startup and play with it on the form through javascript.

It's very impressive, as the whole screen can be repainted without calling the server ever.

If I were working at BuzzwordMakers Corp., I would call this approach the Lazy Ajax Painting (LAP).

But too much LAPing can deteriorate the user experience: the lag involved can be really bad, and she might try to refresh the page over and over again, because it seems locked or some similar feeling.

Furthermore, the retrieved data is dead: if someone else changes it on the server it won't change on her client browser, unless an expensive observer that recheck datas once a while is settled.

On the other hand, too much asynchronous server calls can drawn everything as well...

But autocompletion means the output is beeing filtered out at least by the first character, so the amount of data is not so bad.

For example, if the widget is used to select some people over a LDAP directory that contains 5k users, the first data packet will be composed of an average of 200 entries at most. The second character put this number down to 8 entries or so. In case of a big directory, a smart approach would be to block the autocompletion feature until the user has typed a few characters.

Anyway, this is the same scale than regular queries over directories, so a full server-side data provider is probably the way to go in most case.

If needed, the widget can combine both ways, and decide which one to use depending on the amount of data.

CPSAutoCompletionString widget

Back to CPS: I've created a new widget called CPSAutoCompletionString that is just a simple String widget with an extra piece of javascript. It adds a class initialization and roughly renders someting that looks like this:

<input type="text" name="field" id="field" value="cool value"/>

<div id="field_choices"/>
<script type="text/javascript" language="javascript">
    new Ajax.Autocompleter("field", "field_choices", "server_method", {});'>

</script>

The input will use the div, feeded with value asynchronously retrieved with the server_method. That's it. cough cough. (Some may argue it's even shorter in Ruby on Rails, but it looks short enough to me ;) )

Now the cool part: the server method has been kept totally out of the widget code in order to let the developer code it as he wants. A Zope 3 view can be done, or a raw Zope 2 skin as well.

The server side has to send a <UL> tag with all entries in it.

Since this javascript code works with the raw responseText, we don't need to implement a special transport protocol (json, rpc, ..)

The result is just used to fill the div.

Example of Zope 2 skin:

##parameters=
# I wish I had Five installed so I would do a view here :')
return '<ul class="cpsskinsMenu"><li>one</li><li>two</li><li>three</li></ul>'

There's no filtering in this example, but it's really simple to send the current input in order to filter entries, and I'm still working on it.

Conclusion

CPSAutoCompletionString has been integrated for CPS 3.4.0 but won't be used in any CPS forms yet, as this will be done later on. You can already use it though, in your custom CPSSchemas layouts, or through CPSTypeMaker.

CPS Developpers, if you give it a try, let me know !