In my
last blog I said I would select some toolkit out there to compare the
result, but after some mails exchanged on Z3 mailing list (
Ajax in Zope 3 Thread), I agreed with what Benji York and Gary Poster said
in this subject:

"I'm very interested in coming up with a one or more relatively simple
server-side proposals to make Ajax stuff easier, but I think the Ajax
stuff (and even the whole JavaScript world) is too immature to settle on
one client-side implementation. Therefore we should concentrate on doing
things that help most or all of the JS toolkits be more usable with Z3."

So I have started the work over CPS with Scriptaculous, focusing on
uses cases and when doable, on the server-side infrastructure.


CPS Use case #1: CPSDocument AJAX form controller with graceful
degradation


The first use case in CPS is to embed existing forms used to change
document fields. The Javascript needs to let the user validate a form,
that is sent asynchronously through an XMLHttpRequest object, to get
direct feedback.

The feedback is then used on client-side to either:


  • Update the form on errors, to point out the fields that are not
    correct;

  • tell the user changes where made, optionnaly changes the page title
    when the user has change the title, and eventually redirect the
    user.


Since this is an ajaxification of existing server side Z2
infrastructure, it was very hard, even overkill to start doing server-side
work, so for this use case I have just added a bit of code on server side
to make it work, without trying to do a clean infrastructure.

The constraints are:


  • Graceful degradation: if JavaScript is not available, the form has to
    work as usual

  • If the user tries
    to send a file(1) in the form, the classic form will be used

  • Use Object Oriented approach (OO)

  • Use Test-driven development approach (TDD)

Graceful
degradation


This is one of the most interesting thing to work on: make the pages
still work when Javascript is unavailable, so CPS stays compliant with
all accessibility levels.

This is simply done by an unobtrusive way of doing thing: when
initialized, the Javascript code hook itslef to the form, degrading its
action and its submit buttons.

TDD and OO


The OO approach is very easy under Scriptaculous, wich is built on the
top of Prototype. So this is as easy as
Mochikit, and I would say, as easy a coding some classes in Python !

The TDD approach is very simple too: Scriptaculous comes with a
unittest framework that provides usual tools you would find under Python
(assertXXX methods, test fixtures, etc.). Doing TDD in Javascript come in
two parts: browser-side testing and server-side testing when AJAx is
involved.

browser-side testing


browser-side testing is done by creating a simple HTML file that
contains all use cases to be tested, wich is the HTML environnement
where the JS has to evolve, and the test object itself with all tests.
When the HTML file is called, all test are called and you can even
display feedback with green divs and red divs a la selenium.

server-side
testing


I won't discuss this part in that blurg, but to cover the whole code,
we need to validate the code that generates AJAX answers as well.



Conclusion


CPS now has a nice AJAX form validation that will be available in the
next releases, and wich is still beeing worked out in a
branch
at this time.

This was quite simple to do, thanks to the nice, smart js toolkit, and
thanks to the scriptaculous community out there, that helped me out on
some small problems

I didn't talk about two things yet:


  • Server-side infrastructure

  • Test automation

Server-side infrastructure


The next use case fits better for presenting how AJAX helpers can be
done on Zope side: drag'n'drop in folderish objects.

Test
automation


In my next blurg I will explain how to automate this tests and add
them in a Zope environment, to be able to call them in a Python test
suite, try out several browser types, and get feedback about it.

-- footnotes

(1)tries to send a file: You cannot send
file with Javascript (security hole) unless you use some iframe
artifact.




(Post originally written by Tarek Ziadé on the old Nuxeo blogs.)