Ajax with plone 3, KSS development patterns - Godefroid Chapelle (__gotcha)¶

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