Kukit.js and Azax description
Update : the project has evolved into KSS
If it was only learning a new language, it could be acceptable. But we want sites that work cross-browser..., and cross-browser compatibility is very difficult to achieve, especially in a world where IE-mega-buggy is still around, hum, I mean predominant :-(
The main objective pursued is then the following : no JS should be needed to code Ajax (or more realistically to code most Ajax use cases).
To avoid JS coding, one of the ideas is that the Ajax code should be generic enough that it can be written once (and hopefully debugged once ;-). In my opinion, this cannot be achieved if the application model/logic is brought to the browser : this would imply that each application would need specific browser code (JS code) that manipulates the model.
We need to think of what the browser does. The browser is agnostic about application logic; it only knows how to render the HTML plus CSS it gets. It is a very complex and generic renderer that we can reuse in a myriad of contexts.
The Ajax engine should be exactly the same : totally ignorant of the application model/logic. In the begin, it will only cover a set of simple use cases. Nevertheless, adding more complex use cases later would then only demand to extend the Ajax engine in the same way browsers have been extended to cover CSS2, when it added complexity to the CSS1 use cases.
Currently, the browser makes no decision about application logic : for each click, a request is sent to the server, a whole page is calculated and the browser renders it. Why would this need to change when we switch to Ajax that allows to refresh only parts of a page ? It will already be a very big win when we calculate only parts of the page.
To sum up :
- the Ajax engine will still notify the server each time a user interaction demands it; it will not make any application-level calculation.
- the server will decide how to react to the user interaction, will calculate the markup needed to render the information and send it back to the browser together with instructions how to manipulate the existing page to transform it.
I am proposing an architecture where the implementation of the JS engine is totally decoupled of the server it would speak to (and in particular should remain independant of Zope).
The JS engine only knows how to manipulate the DOM of the X(HT)ML document it is attached to. The engine processes some XML payload describing which nodes need to be manipulated, which actions need to be performed, and which markup has to be included.
There is another important objective to keep in mind : ajaxifying sites should not lessen accessibility. In other words, it should remain possible to use our applications without Ajax in the same way that we can currently use Plone without its CSS. This implies that instead of inserting the code needed for the Ajax comportment directly in HTML-only pages, we should be able to use another layer to inject it. As with CSS, where styling is described in an external resource, Ajax comportment could be described in an external behaviour stylesheet.
At the end of the sprint, the kukit.js code implements an engine that complies to those main ideas. It can be found at http://codespeak.net/svn/kukit/trunk.
It gets included in the <head> of the page, starts on the onload event, looks for <link rel="kukit" href="xxx"> elements, fetches the behaviour stylesheets, parses them and inject calls to notify the server on the nodes/events specified by the stylesheets.
When the user triggers one of those events, the engine instantiates an XmlHttpRequest, notifies the server and wait for the XML payload that contains the commands to be exectuted. The engine parses the payload and modifies the DOM accordingly by, among other actions, inserting the HTML included.
Both the events injection and the command processing use CSS selectors with the
support of CSSQuery to select the nodes that are the targets. IOW, some of your
CSS knowledge can be reused.
As stylesheets and commands are XML, they can be implemented with page templates only (in the Zope world) or with any of the techniques used by other servers.
There are some simple demos available in the azaxdemo directory of the azax product. It is located at http://svn.z3lab.org/z3lab/azax/trunk.
The azax product attempts to provide a server-side infrastructure to communicate with the kukit engine less generic than just page templates. It depends on Five and lxml. It proposes an API. The azaxview.py module of the azaxdemo directory should be self-explaining.
The azaxdemo directory should be installed as a Zope product besides the azax product (for instance with a symbolink link on *nix platforms).
You can then go to the ZMI, instantiates an AzaxDemo SimpleContent and access its index.html view (like in http://localhost:8080/demo/index.html) to get to a summary page with links to the various demos.
The kukitportlets product contains first step at integrating kukit.js in Plone. It depends on azax as well. It can be found at http://svn.plone.org/svn/collective/plonekukit/kukitportlets. It can be installed as a normal Plone product. Read the azaxview.py code again and lemme know if you understood what it does.
I'd like to thank all the sprinters and in particular Florian Schulze for the big steps made in Bern to get the embryonic code I brought to a foetal state.
All this code is nevertheless not production ready and we will made good use of
the energy of people interested in this whole thing.
As a last remark, I need to speak of the name kukit; it has be chosen for the following reasons :
- it sounds like cook-it and the engine is actually cooking HTML excerpts it gets from the server.
- it sounds like kupu and I hope it will put the Ajax engine in the same family of client-side server agnostic code.
- both kukit.org and kukit.net are available
Nevertheless, the first reaction of some norwegians is that kukit is an offensive term in their language. I'd like to get feedback about this name. *Please do not use and pollute plone-devel to send your advice or new name suggestions*