Bling!

Dynamic this and that... Everyone wants it, why doesn't Plone have it? There are alot of people and groups working on the AJAXification of Zope technologies with varying degrees of success. Here are the main trends I see people pointing at:

• Don't invent a new Javascript library
• Don't force the developer to learn Javascript

I am sure there are others. Right now the flavors of the day are MochiKit and the Prototype family of products. I would say that both of them are great, they both provide OO abstractions around writing JS, making it more fun. MochiKit borrows ideas from Python and Twisted and is quite nice to program with. Prototype, Scripaculous and OpenRico excel in the library of existing visual effects and widgets. They also have great mindshare around them in the form that they are included with and used in Rails.

Don't invent something new, don't code Javascript
I've been experimenting with both in the context of Plone. Here is how it breaks down. Mochikit might be better if you are writing alot of Javascript. This is not however the goal of my experimentation. I like auto generated forms and widgets and I'd rather just make those come alive than. Prototype and family are already used in this capacity in Rails so there is experience in what makes a logical binding between the server side and the client.

If we are not writing Javascript then what do we write? Well, Plone UI people know TAL and a bit of Python so I thought I'd aim for that. Introduce Bling, some helper code than can be used in TAL to spit out the Javascript you need.
I only wrote this yesterday so its a little halfed backed but here is how it might work. This will create a "checkedField", something that validates server-side on change using AJAX and then writes to or clears an error div on the client.

<label for="foo">FOO</label> <input type="text" id="foo"
 name="foo"\/>
<div tal:replace="structure python:ajax.checkedField(
      here.portal_url() + '/dval', 'foo', error='error')"/>

which might generate something like

<label for="foo">FOO</label> <input id="foo" name="foo" type="text">
<script type="text/javascript">
  new Form.Element.EventObserver($('foo'),
function(element, value) { new Ajax.Updater({success:
                                          $('error'),failure:
                                          $('error')},
                                          'http://site/bling/dval', {
onFailure:function(request){
      new Effect.Appear($('error'),{}); Fie\ld.activate('foo');},
parameters:Form.Element.serialize($('foo')),
onSuccess:function(request){new Effect.DropOut($('error'),{})},
asynchronous:true,insertion:null,method:'post\'} )  })

Fun Prototype callouts you didn't have to write or think about. Most of the kinds of tags you'd expect in rails are here already and I've added a few more to show how something like Plone could carry a standard array of reuable behaviors and visual effects.

Next we change something like Archetypes that already has per-field validation logic and vocabulary support and allow for things like auto-completion and validition from the widget layer with out change.

To show how simple this is I've written it into a product already. This will install the proper scripts into the resource registries in Plone. Just create a new site, install this product and play with the test.pt template in its skin path. The methods of interest are in Bling/ajax.py

To get the bundle you need darcs:

darcs get http://darcs.objectrealms.net/repos/Bling

or you can just look at the repo at
http://darcs.objectrealms.net/darcsweb.cgi/bling

Events, Frameworks and FUD

First, a little history. Lets start with the question, "Why doesn't Plone have an event system?" For an event system to really work I would suppose that it needs to be used in all or at least many of the major system in play in a given system. In Plone this would mean that CMFish things would need to fire and consume the same events as the rest of Plone, as the rest of Archetypes, as the events as third party products. In other words an events solution needs to be arrived at from the lowest layers or boil the ocean. Well years into this project none of the lower stack levels have put forward anything usable and nothing has been promoted from application land. Does this mean that no one has tried? Of course not, many have, too many have. In fact in Plone land alone we had 3 different 'event systems' of various size and scope in play for the last few years.

Because no previous effort has won enough development mindshare or devotion to become 'the' event system used in the Plone stack people have by and large been reluctant to use any of them till a winner emerges. We've had a stalemate. To make matters worse the promise of Zope 3 and its clean refinement of the Zope architecture and stack has in many ways halted significant progress in Plone land. We are left making incremental improvements to exiting feature without breaking any new ground. And guess what... That's OK, Zope 3 is better and we have quite a few people waiting for it, experimenting with it, and even a few deploying on it.

Back in Plone land though, no events... oh we can abuse the catalog hooks all we want, those are almost in the right place that we can keep adding things to them to keep extending the system but this is no answer. As a result, it was my impression that the term Event has a certain negative stigma around it, a kind of false promise. For marketing reasons I looked for another term. From a technical perspective events as they are dealt with via the catalog hooks have a particular semantic and a real lack of flexibility and yet still some people see these as events. For technical reasons I sought another term.

If I used the term framework I apologize. That's the flavor of the day word for, "I'd like to be victimized (by the community I am trying to help)" and I should know better than to toss it about, but I don't think I ever said that. The code in question is a pluggable routing class for event payloads and a tool that can manage subscriptions persistently. We recently tried to update it to use Five events for payloads and install a bridge between Z3's 'notify' API and the 'fireEvent' call that makes sense in a Z2 Acquisition hierarchy. That's it.

Its small, its using Z3 concepts and code where we can and we asked for feedback. That offer is still open.