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
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.
The first use case in CPS is to embed existing forms used to change
that is sent asynchronously through an XMLHttpRequest object, to get
The feedback is then used on client-side to either:
- Update the form on errors, to point out the fields that are not
- tell the user changes where made, optionnaly changes the page title
when the user has change the title, and eventually redirect the
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:
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)
This is one of the most interesting thing to work on: make the pages
all accessibility levels.
This is simply done by an unobtrusive way of doing thing: when
action and its submit buttons.
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
two parts: browser-side testing and server-side testing when AJAx is
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.
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.
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
The next use case fits better for presenting how AJAX helpers can be
done on Zope side: drag'n'drop in folderish objects.
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.
(1)tries to send a file: You cannot send
(Post originally written by Tarek Ziadé on the old Nuxeo blogs.)