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

A long time has passed since our last blog entry and a lot of progress has been made with KSS / Azax.

Previously we mainly concentrated on completing the core framework and working out use cases for Zope. As a result the core KSS framework and its base demos run on a variety of Zope versions including Zope 2.8, 2.9, 2.10 and Zope 3.2. The documentation has also been started; there is a tutorial for startup, and some other documentation. We also had some discussion on the mailing list that gave us a lot of input on what use cases would be important to do first - thank you Martin 'optilude' Aspeli for the lot of work devoted into this!

Next we could start to focus on use cases for Plone and Archetypes. As a result, we already have some use cases working in our review bundle, and our PLIP contains more information about the general picture and how we plan to move on.

In the bundle we decided not to branch off Plone or Archetypes but to offer add-on products instead, thus showing how KSS can add dynamicity to existing applications. We have working demonstration of

• content tab switching:  if possible we change the content region without reloading the page in an economic way, and if not, we fall back to traditional navigation. This works with all "green" tabs including those in the setup area. There is a problem on loading the kupu editor, which currently either works or not, we hope to solve that soon.
  
• autorefresh of portlets: We have a simple portlet autorefresher that in the default setup refreshes the "recent" porltet, any portlet can be refreshed by just adding a corresponding rule to the KSS resource. This could be easily integrated with the portlet engine later.
  
• In-place navigation in the calendar portlet
  
• validation of AT fields on onblur event (in ATAzax product): On leaving a field the validation of the field is done and the field error message is displayed, this is only implemented for the String widget and will soon be extended for all built-in widget types.
  
• 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: in other words, we show how external components can coexist with KSS and existing code can be wrapped with lightweight modifications (in livesearch product). Soon we will also show how the same component is easily reusable for other tasks like autocomplete and other intelligent search fields.

In addition, there is also a live demo site set up which however shows just the Zope-only demos of the azaxdemo product at the moment - which means none of the above stuff yet :-(, nevertheless it gives a quick view into how KSS works.

In September, we will have a 4 days developer sprint in Belgium to enhance further the Plone UI with KSS. We plan to complete existing use cases and introduce additional ones. We also plan to enhance our testing system and provide more effect libraries by wrapping existing javascript libraries for use in the KSS framework.

Although the main system is usable with all Zope and Plone versions, the Archetypes specific parts of the review bundle are prepared for Plone 3.0 and run only on Zope 2.10. You also need to manually replace Five with the svn version of Five 1.5,  (iow, even the svn version of Zope 2.10 is insufficient since that links to a static tag of Five that contain critical bugs). Many thanks to all those people who made this possible and especially Alec Mitchell, Hanno Schlichting  and Philipp von Weitershausen who helped us invaluably to track down a few showstopper issues.

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/archive/2006/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!