First design patterns. KSS is different to most other ajax solutions in
that it says that business logic should be computed on the server. They’re not
shipping data to the browser to let javascript compute things there. All
computation is done on the server. It is so easy to let the normal python
code and the javascript code drift apart: keeping everything in python is
best. An extra advantage is that KSS integrates well with the current
development process. And it limits the amount of javascript. Javascript is
hell and the various implementatios differ a lot. Debugging is hell.
Core of the design is kinetic stylesheets: KSS. Such KSS files define the
client-side binding of site elements to javascript behaviour. This way you
have a generic set of javascript that can be tested independently from
whatever you want to do with it. If you hand-code all javascript
functionality, you have to test every page on all browsers. The generic
client-side engine allows html snippet manipulation.
Next some development patterns. First create regular html-only pages: for
accessibility and cross-browser reasons. Afterwards, you bind events to the
html using css 3 selections.
Intermission: firekiss is an essential extension to
firebug to debug KSS files. Godefroid demo’ed it and
it looked great. The download link is
http://kssproject.org/downloads/firekiss.xpi
.
KSS has three “command sets”, of which the client side only knows one:
kss.core. The core knows about removing/adding html, popping up a message box,
etc. The other two sets, one for zope and one for plone, are convenience
sets. reloadPortletsByInterface() for instance.
Now test patterns. First things first: do not use selenium (unless you
create a new javascript plugin). Instead check the commands in a KSS response
and check the resulting html elements, classes and IDs. Look at some of
tests inside KSS for examples.
Technorati tag: ploneconf2007
Reinout van Rees: Ajax with plone 3, KSS development patterns – Godefroid Chapelle (__gotcha)
Originally from Planet Plone
