Forgot your password?
New user?
Document Actions
#171: Include KSS in Plone
- Contents
- Proposed by
- Balazs Ree
- Seconded by
- Godefroid Chapelle
- Proposal type
- Architecture
- Assigned to release
- Repository branch
- kss-base-bundle
- State
- completed
Definitions
Base terms
AJAX stands for Advanced Javascript And XML which means that the page has dynamic behaviour and contacts the server between page loads. It is a rather overloaded term with increasing popularity.
KSS is our main resource language, similar to CSS but with a different semantics: it is a stylesheet describing dynamic behaviour of the page. It has been also promoted as the name for the entire framework.
Azax is the name of the server side support for Zope2 (and Zope3) and the corresponding Zope product. (update may 2007, Azax name has been deprecated; we now have a python package : kss.core)
PloneAzax is the name of the Plone product that contains Plone-specific support and extensions for KSS. (update may 2007, PloneAzax name has been deprecated; we now have a python package : plone.app.kss)
A KSS plugin is an extension of the KSS system, that is embedded into a Zope product, and once the product is installed it becomes transparently available.
Developer roles
We distinguish the following developer roles:
KSS designer: is a person that designs the required behaviour of the page by writing the KSS resource file. Does not know javascript and only uses the installed components.
KSS server action programmer: is a person that writes python-only code on the server side that describes custom manipulations that need to be done in a page, as a response to some KSS event.
KSS plugin developer: is a person that develops plugin components for use with KSS, requires a profound knowledge of both KSS itself and javascript.
Architectural elements
We use the following base terminology:
A KSS event is something that gets triggered on the browser, due to the user's interaction.
A KSS action is what gets executed when an event is triggered, we distinguish client and server actions.
A server action marshalls KSS commands that, returning to the client, execute the desired effects on the page.
Motivation
Plone UI does need to be improved through AJAX.
This could be achieved by using one of the existing AJAX frameworks. However, most - if not all - Javascript libraries offer only client side support, thus forcing us to put aside our beloved pythonic server side development practices.Further, AJAX increases the coupling between client and server. This can lead to a maintenance hell.
KSS is a js framework that support AJAX development so that
- no javascript should be written by the developer to add basic AJAX dynamicity to a page;
- AJAX is in its own layer that can be activated or not - allowing to keep accessible pages;
- the server is always in control, allowing to build thin client solutions easily;
- control resource (KSS) is 100% decoupled from templates and code;
- control resource (KSS) is designer-friendly, since it is similar to CSS in both syntax and logica;
In addition we wanted to offer a solid server side support that
- is testable;
- enables extension of the system with custom extensions to the core;
- enables the building of fat Javascript client solutions in a componentized way;
- plays well with Zope3 and full support its technologies;
Finally, it is important that:
- the framework targets different developer roles (designers, programmers, plugin developers) in an appropriate, levelled way, thus enabling the easy deployment of the system,
- rapid prototyping should be possible by starting with a thin client solution and fatten the client gradually,
- enough debugging information would be provided to avoid to get lost in Javascript's hell.
To sum up, the motivation to include KSS into Plone now is to enable the developers with quickstart with KSS for their AJAX development.
The technology itself is not depending on Plone but it could benefit a lot from the many needs of Plone UI development, in the same way as Plone can also benefit from using KSS.
Assumptions
This proposal is not about the Ajaxification of all Plone UI. It is about the inclusion of a tool that allows this ajaxification and of code that implements some of the AJAX bits, showing that the tool is rich enough to cover a lot of use cases.Proposal
Include the following products in the Plone distribution:- azax - which includes kss js framework and the server-side support
- PloneAzax - which includes setup in Plone and the implementation of UI improvements (see use cases below)
(update may 2007, Azax and PloneAzax products exist now as python packages : kss.core and plone.app.kss)
Implementation
Because KSS tries to not be disruptive in the development process, the inclusion and the installation of the Products should be enough.Deliverables
azax, PloneAzax products, (update may 2007 : those products have been transformed to python packages - plone.app.kss and archetypes.kss)
- migration code,
documentation, which is now on http://kssproject.org. The first tutorial is http://kssproject.org/documentation/tutorials .
Risks
Concerns are mostly performance issues.
In general, delegating part of the CPU need to the clients is a Good Thing. Normally the drawback is that controllability and debugging becomes so difficult that these methods become very expensive. This is exactly the strengness of KSS: the no-javascript policy and componentization offers the way to a maintainable, debuggable solution even when talking about more complex system.
However as a price the client browser needs to load more javascript, the core framework plus the extensions. This, coupled with effective caching and the on-the-fly compression of all the javascript code, leads to a quite manageable solution. In other words, the price of doing things simple results in the need to use more general purpose javascript code.
There is also some additional CPU load on the client side, that happens on each page load. This depends on the overall number of KSS rules loaded, and succesfully bound to page elements. In our use cases however, we could not measure a noticable slowdown due to the usage of KSS. (There is a noticable slowdown when debugging with caching disabled, due to a lingering ResourceRegistries problem, but that is not directly connected with KSS itself.)
Finally, dynamic requests put an increased payload on the server, which is again not a consequence of KSS but of the AJAX technology itself. However it may well turn out that this in fact leads to a decreased and more balanced payload, since instead of reloading a whole page we can often just replace a part of it, thus decreasing the overall server load.
Progress log
Core bundle created in the review repository.
First tutorial written.
There are a few use cases in different state of completeness.
- switch tabs
- autorefresh of portlets
- validation of AT fields on onblur event (in ATAzax product) (update may 2007, ATAzax product is now a python package : archetypes.kss)
- validation of the entire AT form when save button is clicked, showing error messages without reloading if there are some errors (in ATAzax product)
- livesearch is now bound to its input with kss (iow showing that external components can live with kss and existing code can be wrapped with lightweight modifications) (in livesearch product)
Plan
There will be a sprint in Belgium in September where we will focus :- on extending the validation of AT fields to all standard widgets;
- on suggestions done by the framework team when reviewing this PLIP,
- improve test infrastructure;
- implement the wrapping of scriptaculous effects.
Participants
KSS core developers:
- Godefroid Chapelle
- Florian Schulze
- Balázs Reé
- Martin Heidegger
