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!