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.

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.

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.

We had a great time in Sorrento this year. The KSS work was centered around testing Plone and the PSPS #7841 topic.

• Simone Deponti, Tom "Spanky" Kapanka, and Balázs Reé worked on extending the kss.demo testrunner to deal better with application level selenium tests. Besides testing Plone itself, it also aims at enabling testing of applications written with Plone, Zope or Grok.
  
• Beppe Zizza wrote documentation that explains how to install the test running environment, how to run the existing tests, and how to write new ones, The document is targeted towards Plone developers but is also meant to be generic with respect to other Zope based frameworks.
• Simone Deponti and Massimo Azzolini championed the review of the Plone tests we wrote last year. They fixed those and tried to write new ones. During this, we identified and solved important problems, such as site creation (adapting the code written by Davide Moro at the last Sorrento sprint), login and logout as different users (test suite layers). We also realized it is sometimes difficult to carry out the tests we want with Selenium.
  
• Sylvain Viollon worked on Funittest integration. After discussing the topic, we agreed that this method should live in parallel with the already existing one that uses prerecorded tests. Because of platform dependency problems and the challenge of the different testing models, the evaluation and adoption of Funittest might be a longer process. As a first step, Sylvain made a buildout that contains all package dependencies, and wrote example tests for Plone with the help of Massimo Azzolini. We also explored the possibility of converting Funittests testrun snapshots into a sequential format that can be played directly with Selenium IDE and thus used with the existing KSS testrunner.

We also looked into future possibilities. We started with the help of Robert Niederreiter the evaluaton of Cornerstone, the ajaxian widget framework of Devilstick. We definitely need more time to evaluate this component, and consider the possibility of adopting code and/or ideas for widget support into KSS.

Check out material

The documentation that explains how to install the test running environment, how to run the existing tests, and how to write new ones, can be found here. Check it out!:

The ploneout branch that enables selenium testing of Plone 3.1 is here:

https://svn.plone.org/svn/plone/ploneout/branches/3.1-kss-test

The kss.demo extensions are still subject to change, but you can simply drop new tests inside plone.app.kss, under the selenium_tests directory and they will be picked up automatically.

Funittest

The experimental Funittest integration buildout is here:

https://svn.plone.org/svn/plone/ploneout/branches/3.1-funittest

Actual tests are in funittest.plone, in the lib/plone/kss directory. More information on using Funittest is available on OpenPlans, together with more technical reports as well.

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).

• 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!

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).
  

The design started with a new logo designed by Thijs Jonkman.

After this was approved, Linda Verhagen designed a draft theme for the website.

Jola Hyjek helped to choose the main color of the site.

At Plone Conf 2007, Jarno de Wit and Thijs pulled together to finish the theme.

Balazs Ree and Jeroen Vloothuis have put it in production.

We want to thank everyone who helped, especially all the nice people at Pareto for having worked for the project.

• 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).
  

Changes of KSS style sheets syntax

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;
}

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

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

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

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

Refactorings in client-side engine

Refactorings in server-side Python code

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.

We have worked on the following areas during Snowsprint 2007:

1. Godefroid was improving the testing framework, and built the kissbot with help of Andreas Zeidler and Thierry Benita. It is based on buildbot and buildout components. We can now test automatically our Selenium functional tests on a farm of servers.
2. Balazs and Godefroid made some refactoring on the framework in order to support the drag-and-drop plugin better. The drag-and-drop plugin is still under development.
3. Jean-Nicolas Bes and Balazs worked on eventPush with the help of Thierry Benita. This is an  experiment based on Twisted and with technology borrowed from the "Comet" library. We tried to enable the server to send asynchronous commands to the clients. With this, we want to demonstrate, for example, that changing the title in one client would simultaneously change the title in all clients viewing the same page. The goal of this experiment was to show a proof of concept and proceed with the exploration of this area. This is NOT targetted for Plone 3.0 or any close release.
   
4. After the sprint, Phillipp von Weitershausen refactored the server side event handling, fixed the pending issues and reported that he successfully used KSS with Grok, on Zope 3.
   

During the Plone 3.0 Baarn UI sprint, some progress was done in the following fields:

1. Refactoring done to get rid of the "executeCommand" workaround. We can now use a selector with any client action to express on which nodes the action will be executed.
2. Several bugs were fixed in Plone 3.0 integration, including kupu related ones and the issues about the "Do you want to leave this page ?" query. Most issues were caused by other components that had changed and unwillingly broke KSS. The importance of testing is proven again.
3. More progress was done on the testing infrastructure. The demo tests are now exercised on Firefox-Linux and IE-Windows platforms. Jeroen Vloothuis worked on a script that generates Python modules (that run the Selenium test cases) from the Selenium HTML recorded with Selenium-IDE.
   

We would like to thank everyone for providing great work for Plone and KSS, and hope more will join in the future too.

We would like to mention that KSS has a FreeNode IRC channel (#kss).

There is a new mailing list on codeSpeak.net : kss-devel. It is dedicated to KSS development issues and generic use cases. There is also a mailing list that monitors the KSS subversion repository : kukit-checkins. Both lists have been subscribed to gmane.org : news:gmane.comp.web.kss.devel and news:gmane.comp.web.kss.scm .

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

• 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 Plone conference and sprint has finished in Seattle. Lot of people say it was the largest and most interesting conference so far. Well, it was also an important step for the development of KSS.

We gave an introductory tutorial about KSS. We were running at the same time than Philikon and had the same feeling as him that we spoke in front of a not so full room. After all, it was afternon of the last day and people might have grown tired.

Nevertheless, we received lots of positive feedback that reassures us that the initial goals are valid, and that we are moving into the right direction with the implementation. At the sprint following the conference, new developers started to work with and on KSS; once again, we could experience that, after a short introduction, they were able to contribute to the code.

Although the sprint lasted for two days only, we made good progress, especially in the following areas:

• Jan and Massimo have fixed most of the bugs that had crept in after the Louvain-la-Neuve sprint. (They were either the consequence that we are using the development trunk of Plone, or that we provide backports of the software to practically all Zope and Plone versions. - In other words, we have many branches to maintain and that gives a higher chance to dependency problems.)
  
• Balazs has refactored the way the plugins use the Zope3 component architecture : as a consequence, all our plugin components are now really independent of their import locations.
  
• Jan, with Aaron and Josten, went on with implementing the Plone 3.0 use cases. We can, now, for example,  quick-edit the data rendered in the event summary table.
  
• Last, but not least, we have a working version of a solution to the following problem : when some data on the server is modified by an Ajax request, the client should update all parts of the screen that are displaying the modified item. For instance, after quick-editing the title of a content item, not only must the title be updated in the content area, but the navigation portlet, the breadcrumbs, the recent items portlet have also to be updated. We can see how a generic solution is needed for this generic problem : custom portlets might also need to be updated. Jeroen (with Luca, Gotcha and Philikon), has built a Zope 3 event based solution that emits an event (IAzaxEvent) when some state is modified on the server. Handlers can be registered to automatically update all dependent parts of the screen.
  

There is still a lot to do in the future. Without being exhaustive, the following key points are foreseen:

• Move our code out of Products. Merge PloneAzax and ATAzax templates into the Plone core. This is now prepared and will happen asap.
• Tests, tests, tests. We are entering into a stage where testing becomes even more critical. We have to complete our coverage. We need to have Selenium tests for all the Plone UI functionality, and we are also planning to extend our client side framework to be able to load and test DOM content in an automated way.
• Improve the caching story. We want to be able to differentiate between cacheable and non-cacheable requests, and allow CacheFu to have fine-grained control just as with normal requests.
  
• Improve the client-side request queue manager to handle priority queues and the cancellation of requests. This will allow, for example, to have individual "loading" spinners and cancel buttons on each of the page elements whose refreshment is in progress.
• And most importantly: go on with the use cases for Plone, make a drag-and-drop component and extend the LiveSearch component to be used in a more generic way then before, for the filtering of very large result sets.

We wish to thank to everyone who joined us in our efforts. We believe that if we go on working like this (and of course we will), we are looking forward to a real exciting Plone 3.0 release. Thank you for making this happen.

And of course, as always, there is also a personal side of the story. It involves us Europeans, the trip to America was really amazing. Our private passtime activities like birdwatching, sealspotting in either Seattle or San Francisco, attending some cool Halloween parties (yes, nine were shot just a few blocks away from us) or chasing the Hollywood sign in LA (one of my favs) were truly fun.

Finally, although many have already told it on several occasions, we want to repeat it : big kudos to the conference organizers and to our more then friendly personal hosts.

Today I took a short visit at the Drupal conference, held in Budapest, Hungary. (Drupal Konferencia 2006, Hungarian link only.) I had the chance to talk with Dries Buytaert, Károly Négyesi and other lead developers of Drupal.

I do not attempt to give a summary or comparison between the two CMFs, because I hardly know Drupal. It was an interesting experience to recognize the same patterns we apply in Plone but in a quite different context. I had an overall good impression and was very welcome by our "rivals". (No, I did not wear my Plone Conference t-shirt. :-) )

I also had a chance to learn about the usage experiences of AJAX technologies in Drupal. Drupal has already adopted jQuery as its  javascript framework and plans to build its AJAX services on top of that. jQuery indeed looks very promising and many developers will agree on this.

This makes me stronger in my position: the core of KSS is currently independent of all javascript frameworks, and it should stay so. The layer that enables access from KSS to any particular framework should not go into the KSS core, but should be implemented as a KSS plugin component (distributable together with the core or separated) instead. This has been our recent practice, and I'm convinced we should continue with that. This ensures not only that we will always be able to deploy simultaneously multiple javascript frameworks if needed, but also that we can always reuse the most stable and best maintained javascript codebase that is available.

I mention this because during the BubbleNet sprint I had an argument with Daniel Nouri who was in favour of depending on Mochikit, and I also understand that others promote the usage of Prototype and Scriptaculous. I believe that the above outlined solution allows us to take the best of all worlds.

So the KSS sprint in BubbleNet is finished. I am pleased to say it is a real success.

The following objectives had been set, sorted by order of priority :

• introduce new plonistas to the tool and have them make some development,
• move on with the development of the PLIPs 121 and 122,
• improve tests infrastructure and begin to add some where they were missing,
• refactor the adapter story of Azax, to make it more compliant to the right way.

More Plonistas

• all standard AT widgets are now validated at blur time in edit view,
• change of views with display menu do not reload the full page anymore,
• same for copy and cut of actions menu,
• and for workflow transitions of status menu,
• instant edit of text and description fields of the 'page' content type is now implemented, based on a generic archetypes implementation (iow, which will be expandable to all views/fields pretty easily).

Plips

Thanks to their work, second objective has been mostly attained as well. Further, the main usability issue until now (the lack of spinner) has been fixed : you know now when you are waiting for a refresh of some parts of the page.

Tests and refactoring

We did quite some work on the third objective : tests coverage has improved a lot. Even though code is still not 100% covered, I could use the current tests as safety belt for my work on the adaptors refactoring. On the last day of the sprint, I merged the work as all tests were passing. I must say I was really satisfied to find out that none of the use cases that had been worked on before were broken, iow that the tests were doing their job.

Now, let's not forget the less positive things.
First, on client side, we found out once again how cross-browser JS/UI is difficult. Lemme explain.
For instance, as we already know, the use of the Enter key in forms is sort of broken in IE (cfr FormController warnings). Well, it is also fragile in Safari.  We will have to explore more in order to enable (cross-browser) to just press Enter to save the Title.
The good news is that we have shown with the other use cases that, when the JS code is already covering the cross-browser issues, the layer that KSS provides really ensure that the developer stays away of those troubles. Iow, if and when we get a solution for the problem just cited above, it will be fixed once. There will be other cases like this and this is the main reason for KSS imo : lets fix things in a central place.

Second, on server side, the ZPT, Python scripts, FormController stack combined with Five views is often in our way when we insist on reusing existing code. In some cases, a lot of time is needed as we all already know. Nevertheless, we can do it, for instance, Archetypes validation is fully supported in the edit actions.

Third, no work was done to refine the effects support... which is not so serious as it is a little task anyway.

So all in all, four very good days. If you want to see it by yourself, checkout the code from svn (do not forget to use Five 1.4 head). If you can wait, you'll get a release asap.

I want to thank all the people that have worked with me on this since already more than one year : to see my dream becoming reality is a great feeling.

• bound to events by a KSS resource :

#regionToFade:click {
    action-client: effect;
    effect-type: fade;
}

• or executed from a command added to the response on the server :

from Products.PloneAzax import AzaxBaseView
view = AzaxBaseView(context, context.REQUEST)

commands = view.getCommands()
commands.effect('#regionToShow', 'appear')

return view.render()

The support is still very basic : some effects are missing, parameters are not supported... This will be refined during the sprint that will happen next week in Belgium by BubbleNet's offices. If you can't wait, take a look at the online-demo.

• ResourceRegistries 1.2.3 now includes the fixes needed by PloneAzax. (Florian)
• PloneAzax has now a branch that is compatible with Plone 2.1.3. It works with the Zope 2.8 branch of azax. Bundle will follow. (Balazs)
• There is now a Vim syntax file for KSS. (Godefroid)

Christian Klinger, alias goschtl, has given us help in our effort to provide KSS use cases for Archetypes. Besides helping with the in-place navigation of AT edit forms and validation, he also wrote KSSMasterSelectWidget that we included in the review bundle for PLIP171. He has chosen a slightly different approach from our base track and instead of refreshing the entire widget at once, he modifies individual attributes in the HTML DOM. We will further enhance the widget and possibly integrate it with ATAzax during the upcoming KSS sprint.

He has written a mail that I would like to include here with his kind permission. Thank you Christian, for your ongoing help in our efforts.

My Experience with KSS

First, I work with Archetypes since two years I think. I have deep knowledge about Archetypes. For intra and extranet projects, I developed several AT-based objects. I have less experience about Javascript and basic knowledge about CSS.

I came to KSS, because we needed dynamic widgets for a project. Unfortunately, the MasterSelectWidget in the Collective does not exactly match my usecase. I tried to add my extra functionality to MasterSelectWidget but did not get it to work (lack of experience in JavaScript).

Then I looked around for other Ajax-frameworks for Plone. The results of search --> KSS. I read the site http://azax.ree.hu/documentation and worked through the tutorials.

I like the concept of an additional kss which is responsible for binding on elements. The binding stuff goes into seperate KSS files, which are managed by ResourceRegistries in Plone. For the server-actions, it´s possible to use the new Z3-view classes with all their advantages. The syntax of KSS is, with my knowledge of CSS and Firebug (Extension for FireFox), relatively easy to use. With the help of the tutorials and cheat-sheat, I learned to work with the KSS-Server actions (replaceInnerHTML, ...). Additionally, there are some very cool debugging and logging functions which makes it easy to understand what's going on.

For my first test of KSS in RealWorld, I tried to realize the Content view/Edit tab. I had to hack some code to only render the <div fill:slot="main"> part of main_template. But with some help from ree on IRC, it was pretty easy to do the KSS part of this task.

After collecting those first experiences, I developed my DynamicWidget. My aim was to add the functionality of MasterSelectWidget to a new KSSMasterSelectWidget. All in all, it was not difficult to adapt the fuctionallity from the old MasterSelectWidget to the new KSSMasterSelectWidget.

Christian