I really enjoy the graceful degradation approach. It's a pleasure to enhance CPS user interfaces that way.

Last time the edit form for simple document was ajaxified in order to give the user a fast way to get feedback when she changes the data.

The next challenging step on these form is to enable file uploads so complex documents will be ajaxified as well. The iframe technique is the only technique i've hurd of for this task. Some guys over the Ruby ML also explained me how to do it with a bit of Flash in the form but this is a dependency we don't want. Anyway, this enhancement will be exposed in round #3 or #4.

Round #2 is about a quick and lazy todo, yet powerfull feature: autocompletion.

This is just great: with Scriptaculous there's absolutely nothing to code :). The well-thaught Ajax.Autocompleter class knows automatically how to grab an input field and link it to a server-side or a client-side data provider.

The class deals with all the hard work, automatically showing and hiding the panel that contains the choices. Every command you would think of to select an element from the list (keyboard, mouse) just works as expected.

I won't expose how all this works, just take a look at this demo and enjoy their work.

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 !


	Web Artima.com