KSS now uses base2 (which is significantly faster than CSSQuery) for css node selection: it provides among others much quicker page loads.

The release comes with several syntax improvements:

• Multiple selectors are allowed in the same rule.
  

• Value providers can be recursive.

• url() and alias() value providers.

• Node selection can be specified together with client actions.

• Full form submits can be specified together with actions.

We provide improved demos and testing.

More details can be read in the release notes.

The following packages have been released, to be used with both Zope 2.10 or higher, and Zope3.

package	version	download
kss.core	1.4	cheeseshop
kss.demo	1.4	cheeseshop

There is a howto available that answers common setup and usage questions.

Plone 3.1 includes KSS 1.4. The Plone specific version of the same howto is here.

Many thanks to anyone who worked on the KSS code, and made this new release possible.

The predecessor of kss.base is the kss.core package, which depends heavily on the Zope 3 component architecture. Our new library only depends on Python and setuptools. This will widen our support for integration with other frameworks. We have already seen some fruits of the new approach in experimental support for both Pylons and Django.

kss.base is alpha, and at the moment not compatible with Zope or Plone. For those platforms, kss.core is still needed, as previously. Later, we will improve kss.base to also support Zope and Plone: we will introduce the kss.zope package. kss.base and kss.zope together will replace kss.core, which will be phased out in the end (with keeping complete backwards compatibility).

We suggest to test kss.base to anyone interested in KSS integration on Pylons, Django, or any other pythonic platform.

One main focus was making it easier for people to write KSS plugins. We arrived with the new kss.templates component that eases the creation of custom plugins. Thanks to Godefroid Chapelle we also have FireKiss that will bring a revolution to debugging KSS.

During the sprint we also started to use new technologies such as bazaar for version management and we also created the kissbooth project area on Launchpad. Launchpad offers repository storage for bazaar branches and a web interface for project management.

Sprinters were working on various topics:

• Jan Murre was working on enabling drag-and-drop in Plone, together with Jeroen Vloothuis and Balazs Ree. We failed to finish this: after realizing that more Javascript work is needed than the time available for us, we turned our focus to other subjects.
• Jan Murre started to integrate jQuery effects with KSS.  He also made a working demo of it in Plone.
• Massimo Azzolini was working on code to KSS that will enable the correct handling of browser history through AJAX operations.
• Daniel Greenfeld and Carsten Rebbien were creating a new KSS tutorial that is based solely on Zope3 technologies on the contrary of the existing ones that present using KSS TTW (through the web).

We also helped other teams to apply KSS:

• Jean-Paul Ladage and the XM team were working on the KSS application part of the eXtremeManagement tool and plonehrm.
  

We also made a big step forward with our platform support. Before the sprint we had KSS integration for the following platforms:

• Zope 2 & 3
  
• Grok (Godefroid Chapelle)
• and the pythonic platform Pylons (Jeroen Vloothuis)

and by the end of the sprint we were proud to present that

• Manuel Saelices has integrated KSS with Django!

He made this work by building on top of kss.base (which is also used for the Pylons integration, and will be for Zope). If you want to know how to use it head on over to the tutorial on Django and KSS.

There was also experimental work going on with a large potential impact on the future of KSS:

• Georg Gogo. Bernhard continued the work he started on the last SnowSprint on the eventPush project. His demonstration spoke for itself: we have seen a proof-of-concept application pushing KSS commands from the server to the client (as opposed to the traditional poll-style AJAX).
  

We would like to thank everyone involved in making this happen. It was a fantastic sprint!

One week after the release of Plone 3.0 - the first official release of a project which includes KSS engine, we had a development sprint for KSS. The sprint lasted three days (August 27-29, 2007), in BubbleNet offices in Louvain-la-Neuve, Belgium.

The focus of the sprint was threefold :

• Changes of KSS stylesheets syntax,
• Refactorings in client-side engine,
• Refactorings of server-side support in Python.
  

Four developers joined me to work on KSS project :

• Balazs Ree (from Greenfinity - Hungary),
• Jeroen Vloothuis (from Pareto - Netherlands),
• Jean-François Roche (from Pyxel - Belgium),
• Laurent Lasudry (from Netitbe - Belgium).
  

Additionally, Guido Wesdorp (of Pragmagik - Netherlands) joined us for one day. We could introduce Guido to our framework and get help from his experience gained among others when developing Kupu, the default visual editor of Plone and Silva CMS.

Let's get a bit more into the details of the work done during the sprint.

Changes of KSS style sheets syntax

We discussed and agreed on the following changes for the KSS syntax.

1) Declarations like the following were previously forbidden :

input.blurrable:blur, select.blurrable:blur {
    action-server:                kssValidateField;
    kssValidateField-fieldname:   kssAttr('atfieldname', true);
    kssValidateField-value:       currentFormVar();
    kssValidateField-uid:         kssAttr('atuid', true);
}

Multiple CSS selectors are now allowed, both when events that should be bound are similar like above or different like below.

form.inlineForm input[name=kss-cancel]:click,
form.inlineForm input.blurrable:keypress(inlineescape) {
    evt-keypress-keycodes: '27'
    evt-click-preventdefault: true;
    action-server: replaceWithView;
    replaceWithView-fieldname: kssAttr('atfieldname', true);
    replaceWithView-macro: kssAttr('macro', true);
    replaceWithView-templateId: kssAttr('templateId', true);
    replaceWithView-uid: kssAttr('atuid', true);
    replaceWithView-edit: true;
}

2) Value providers are now recursive. In other words, parameters of value providers can now be other value providers.

... {  
...
saveField-value: currentForm(kssAttr('variableName', true));
...
}

3) Value providers will be allowed in event binder ids. In other words, value providers will also be used for the selectors.

form.inlineForm input.blurrable:keypress(kssAttr('binderId', true)) {
...
}

4) kssParameters (action parameters which have a name starting with 'kss') will be allowed in the action name declaration. They will be space separated. In other words,

... {  
...
action-server: replaceWithView url(http://host/object/replaceWithView);
...
}

will be equivalent and will coexist with

... {  
...
action-server: replaceWithView;
replaceWithView-kssUrl: url(http://host/object/replaceWithView);
...
}

that works currently.

Changes 1) and 2) have been developed during the sprint and are NOW in the trunk and tested.
Change 3) is available in a branch developed before the sprint by Balazs : it will be merged as soon as possible.
Change 4) will be developed later.

We are very happy that Jean-François and Laurent could join Balazs and myself in developing those features : they have made their first steps in the knowledge of the Javascript code of the KSS engine. This implies that the number of developers able of supporting the engine is growing !

Refactorings in client-side engine

1) KSS is now 4 to 5 times quicker !

This is the result of integrating base2 (new library from Dean Edwards of cssQuery fame). Selection of nodes with base2 is much quicker than cssQuery because a native XPath engine is used when available in the browser instead of only slow Javascript code.

The work was started in May by Balazs and Jeroen during a week-end in Rotterdam. Balazs and Alec Mitchell spent another few days in June to benchmark and test the integration. Finally, Balazs and Jeroen made the last needed refactorings during the sprint.

2) Exception infrastructure does not swallow anymore the place where exceptions have been throwed.

Thanks to Jeroen and Balazs that did the refactoring, debugging of exceptions will be easier.

3) The KSS parser code has been refactored.

This allow for better readability and thus better extensibility or maintenability. (We need ...abilities.)

4) The Javascript unit tests page in kss.demo has also been improved. The parser code unit tests still run in IE, Firefox, Safari, Opera and Konqueror.

Thanks to Jean-François and Laurent that did 3) and 4) with me.

Refactorings in server-side Python code

1) kss.base allow us to distribute Javascript plugins as Python eggs !

Jeroen had written Python code for server-side integration of KSS : he presented his integration of KSS in Pylons at EuroPython in July 2007.

During the sprint, Jeroen refactored his code into the new kss.base module. It will serve as the base implementation for server-side integration of KSS in Python frameworks. One of the features of kss.base is the registration of KSS Javascript plugins by extracting metadata from Python eggs.

kss.pylons has already been refactored to use kss.base. In the future, we will build also build kss.zope above kss.base; it will replace kss.core that is now distributed in Plone 3.0.

2) Distribution of Javascript engine is now a step further !

As Laurent had worked with Jeroen on kss.base, he could also use it to develop kssconcatjs command-line utility. This will allow to easily produce the various flavours of KSS engine in a single Javascript file : development or production, with or without concatenated plugins.

Developers from frameworks built on Java or PHP will integrate the whole engine by integrating a single Javascript file.

All in all, a lot of work was achieved. Long life KSS !

--
Godefroid Chapelle

We spent a nice week in the beautiful region of Sorrento, Italy. For KSS, the sprint was a great success, even more than we had anticipated.

We arrived with a lot of to-do tasks and open bugs to the location. Since we recently realized that we are fixing the same bugs over and over again, the motto of this sprint was "tests, tests, tests". This means that we extend the selenium tests to cover the entire Plone application part of KSS and soon we will be able to run these tests in an automated manner with our kissbot.

We introduced KSS to a lot of developers, most of whom encountered the technology for the first time. After a one day tutorial, they were immediately able to start fixing issues and developing new functionality themselves. In addition, this time we also required that for each fix the corresponding tests must be written as well.

Writing selenium tests was a lot of fun and sometimes we encountered difficulties. It seems that we will soon need to make our life easier and improve this process. But we do not even stop here. We will make the creation of selenium tests as mandatory developer policy, accompanied with tests on different levels:

• functional doctests to test if a given html class or id, that is needed to activate kss, is present in a template,
• unittests that simulate the client's call to a kss server action, and check the command response that would be marshalled to the client.
  

A lot of issues were fixed or had a good progress, including the following ones:

• Enter and Escape works correctly for in-line editing, including Safari! (Simone Deponti, congratulations.)
• The zope3 event handling to refresh screen regions if content is edited, is fixed to work with the portlets engine again. (Rosario Di Somma, Simone Deponti)
• Fixed issues with the links in the body view of content. For this a new option created that can be used to prevent the bubbling of events. (Fabrizio Reale, Davide Moro)
• Fixed issues with the content menus to change the review state and the default display view (Massimo Azzolini, Rosario Di Somma). This involved improving the refresh of the content menu. (Jean-François Roche)
• Improved our test infrastructure which now use layers correctly (Daniel Nouri)
• Made the first functional doctest to check html ids and classes (Fabrizio Reale, Daniel Nouri)
• Kss-ify Contentrules; this involved using macros from a Zope 3 view (David Convent, Daniel Nouri)
• Kss-ify locking support (Jean-François Roche)
• Refreshing screen regions with viewlets (Jean-François Roche)

In addition, many more developers helped checking bugfixes and writing more tests. We also had a bugday fully dedicated to Internet Explorer, and we also discovered a code clash with kupu concerning the usage of the sarissa javascript library. This is yet to be solved later.

I believe this sprint was a milestone for this year and its success comparable with last year's BubbleNet sprint. I would like to thank to everyone for the great work we could achieve together for KSS and Plone.

Recently, we received a lot of comments that we were using too many names for the various parts of the project. This induced confusion within users and developers. We had both historical and strategical reasons for having multiple names. However, the time to clean up the situation has now arrived.

We want to confirm that the framework will be called

KSS

as an acronym of

Kinetic Style Sheets.

This name, already used previously, represents the principal nature of the framework : our behavior stylesheet, which has syntax and semantics similar to CSS (Cascading StyleSheets - hence the similarity between KSS and CSS). The word kinetic insists on the idea that the framework adds dynamicity to existing pages. From now on, KSS will imply the whole system, the stylesheet syntax and the javascript stack.

There is nothing settled today for the pronounciation. Some like to pronounce KSS as it is spelled (Kay-es-es). Some like to say "KiSS" . And some prefer to imitate the "Kssssss Kssssss" sound that the friendly snake called Python likes to make after dinner...

Simultaneously, to simplify things, the following names are deprecated and wont be used anymore.

• Azax  was used to differentiate the Zope product from our client-side javascript library. "KSS for Zope" will be used instead of Azax, and "KSS for Plone" will be used instead of PloneAzax.
  

• Kukit is the original name of the client-side javascript library. It was used as the global project name but we dropped it because of its negative connotations in certain languages. Although it still appears in directory and variable names in our code, it will remain an internal detail.

Merge in Plone 3.0

We will soon merge our Plone specific products into the 3.0 Plone repository. Simultaneously, our products will be moved out of the Zope 2 Products namespace. This will imply some package import changes:

• Products.azax will become kss.core (class names that have the word "azax" in them do not change for now, but will be gradually replaced in the future, with a proper deprecation policy). The namespace kss will be reserved to hold further packages for the development of the core framework.
  
• Products.PloneAzax will become plone.app.kss
• Products.ATAzax will become archetypes.kss
• Add-on products will go wherever they otherwise belong to. They do not have to go under any of the kss namespaces : each product can have its own kss stylesheets, command sets and javascript plugins that are activated from zcml and totally agnostic to their subdirectory locations. Those KSS addons are meant to be bundled with the product that uses them.
  

Since the external products will not need extensive import due to the newest enhancements, the change from azax to kss will not be painful and will affect few places in add-on products (in case there are some already ;-). In fact, there is a single interface that any product needs to import. The merge will happen in the next coming days. However, the package path changes will only affect the repository trunk versions: versions 1.0 and 1.1, working with Plone 2.1 and 2.5 will not  be affected at the moment.

The above information is still subject to small changes, until the merge will have been completed. If necessary, I will post further information to developers currently working on the code.

The Azax core developers featuring Godefroid Chapelle and Balázs Reé have had a 3-days mini-sprint on KSS in Belgium, in the BubbleNet headquarters. We would like to report about the work done since the Archipelago sprint.

1. We were looking for a new name to replace 'kukit" : we have decided to call it officially "KSS" since this is the most visible part of the framework. The Zope support is still called Azax and the Plone product PloneAzax. (The javascript file keeps its name "/blog/topics/general/kukit.js".)
   
2. We revised Balázs's KSS2 format. KSS2 had improvements to the syntax proposed at the archipelago. It had grown out the implementation of the first use cases. We have kept large part of the improved semantics of KSS2 but we have switched back to a syntax closer to the original proposal. We think we have come to a stable KSS syntax.
   We have put the new implementation on the trunk and updated all sample products to work with it. Docs will be brought up to date as well.
   
3. We fulfilled our promise made at the Archipelago sprint, and showed how existing programs written with prototype, without any previous consideration to KSS, can be transparently hooked into KSS event binding and KSS's command marshalling architecture. At the moment it just works with a single example. The same can be done with existing Bling components, although we have not demonstrated that yet. The codename of the project is "bluekit".

There is a lot to be done on the framework:

• refactor the code
  
• add missing features
• evaluate with use cases
• wrap up scriptaculous and Bling components into kss plugins to have some "effect lib"
• finalize the plugin API
  
• write tutorials, documentation
  

But it is now finalized to the level that other developers can start experimenting with it. And so the most important part begins: start to use it with real Plone usecases, and find out if additional support is needed from the framework. Also design a consistent look and feel of ajax for Plone.

It would be nice to have a sprint on this subject, where the main focus would be the Plone UI itself, but with the framework developers present to support the different teams. Nothing has yet been decided but it's in the plans.

Please visit this page to have information about the current bundles.

Hello everyone,

I started up this blog and documentation site to keep you informed about the proceedings of the ongoing AZAX development for Plone. You can check out a bit more information here, but at the moment there is not too much material yet. You can expect more things appearing in the near future.

At the moment we are in a bit of transitional state with the KSS description, which means there is preview code available but because of the changes I am currently implementing, I kindly ask everyone who is interested to wait a few days until I can prepare working code and demos, because that would make further discussion and development much easier.

I will make another announcement as soon as possible. Thank you for your attention and patience.

I am working on creating a proposal for a different KSS semantics, that would support our use cases in a better way then the current format. Work is under progress, I will report as soon as my proposal is ready for discussion.

Main motivation for this are the following:

1. I was the one that wanted to push the support for "more actions in one event". However while I still believe that there are use cases for this, I suggest to forget about this now. A particular problem is that all parameters will go into one line in our current  case, thus 90% of all selectors will be a one-liner and a large part of expressivity of KSS gets lost. I feel we are better off when we drop expressing the "more actions in one event" and get back the parameters to different rows We might find another way for extending the acions later on.
2. The second problem is that in the framework diagram we have "event nodes" with more incoming arrows ("the events") and more outgoing ones "the actions". Till now we were mainly dealing with events that simply dispatch to calling a remote action, but for some use cases more is needed. When we want to enable the creation of more complex events, we need to support a kind of object oriented structure, where an "event instance" is created when the event is bound, and it operates like a state machine, being able to execute more different type of actions ("the methods"). We want to be able to map this schema in some way, event though we might not implement this right now. What we do want to implement, though, is exception handling, and the other thing we want immediately is better interfacing possibility to existing Bling software (although Godefroid is currently working on a totally transparent method that might not even need this.) In other words not only we need a bit more natural reading format but we also want to be able to extend it later on.
   
3. A more sensible way to define action parameters will disqualify 90% of the need for creating new plugin actions. As it seemed till now that they were mostly necessary because we could not come up with a sensible way of parameters handling in actions.
   
4.  Last but not least there were a bunch of problems with the original kss syntax, that in this case don't need to be solved.

I apilogize for being too abstract here; indeed it is difficult to discuss this without concrete examples. All this and more is coming up soon.

Hello everyone, I proudly report that the new KSS format is working. (In fact, only KSS works with ResourceRegistries for Plone, so we kept the old XML format as well but all efforts are concentrated on KSS.) At the moment only the first zope-only azaxdemo and kukitportlets use it.

Also I forced myself to write some documentation, where - surprisingly - you won't get any information on the KSS format itself, but at least there is something that allows developers to start follow up.

Generally, I made an updated version of the original architectural overview of AZAX.

Also I put together some basic information on what is what in our svn repository. There is a bundle that you can check out, the document describes it.

As my first notes on the new KSS format I wrote a sum-up which is a low-level developer only document (since there is no doc yet that should explain KSS itself, huh?) and I would especially like to call Godefroid, Martin, and Florian to read it and reflect.

That's it for now, keep tuned for more material coming up, especially a roadmap would be necessary. Those who actually dare to try our demos, have fun.

Welcome, I just start this blog hoping it will allow developers to follow our efforts. I am not an experienced blogger and hope not to deserve the "Ugliest Ever Plone Blog" title here.

Why did we decide to start this site? Because more Plone developers are interested in seeing how we go on with the development, and possibly have a preview of what we have done. Also we would like to extend discussion to a wider range of developers.

All this, and possibly even more to come up. At the moment I just created this site and writing the text you are reading now. Possibly more to come up, with the really useful information, as soon as I have more time. Keep reading us!