Comments on: Content licensing in Plone http://nateaune.com/2006/07/13/content-licensing-in-plone/ Music, technology, travel and musings... Fri, 05 Dec 2008 01:58:07 +0000 http://wordpress.org/?v=2.5.1 By: Jon Stahl’s Journal » Blog Archive » A Peek Under the Hood of Open Source http://nateaune.com/2006/07/13/content-licensing-in-plone/#comment-74 Jon Stahl’s Journal » Blog Archive » A Peek Under the Hood of Open Source Fri, 14 Jul 2006 21:10:48 +0000 http://nateaune.com/2006/07/13/content-licensing-in-plone/#comment-74 [...] Content Licensing - see Nate’s post on conetent licensing in plone. This work was conducted primiarly by the group working in Utah, out of C()SL. [...] [...] Content Licensing - see Nate’s post on conetent licensing in plone. This work was conducted primiarly by the group working in Utah, out of C()SL. [...]

]]> By: Jonah http://nateaune.com/2006/07/13/content-licensing-in-plone/#comment-72 Jonah Fri, 14 Jul 2006 02:51:52 +0000 http://nateaune.com/2006/07/13/content-licensing-in-plone/#comment-72 It is worth detailing somewhere (here maybe ;-)) the effort that went in to integrating a z3 annotation and z3-style field with an Archetypes derived object and form. As far as I can tell, that is basically what http://plone.org/products/plone/roadmap/150 is all about. If PLIP #150 had already been implemented, this project would have been much easier. As it was, we needed to figure out how to make z3 annotations appear on the properties tab, and be processed by the Archetypes processForm machinery. Considering how everyone on irc and the mailing lists has been extolling the virtues of z3-annotations, you would think this would be a snap, but in this transitional period it actually got quite tricky (to us mortals, at least). Luckily, Rob had encountered a similar situation while working on the openplans software itself (https://svn.openplans.org/svn/OpenPlans/trunk/), and recommending a starting point for thinking about the solution. In their case, they first took advantage of the extra_bottom slot on the base_view template, and filled it with the z3 view of the field . Then, they subscribed their annotation object to modification events (https://svn.openplans.org/svn/OpenPlans/trunk/metadata.zcml/). Trouble is, that event is not fired currently by zope, and AT doesn't fire it. Their current transitional solution is to decorate _processForm in a monkey patch (https://svn.openplans.org/svn/OpenPlans/trunk/monkey.py), "manually" firing the z3 event so that the annotation field is notified. Even with this much contortion its still not a seamless integration since the z3 field is not going to be validated along with the other AT fields (we did confirm that the notified event will not get fired until the FormController finishes processing the rest of the fields). In practice, we discovered that while base_edit has an extra slot, base_metadata does not. It also would have been wonderful had AT fired this event for us, if possible (Rob and Whit discussed the possibility of subscribing to a special event, not the normal one to avoid duplicate messages once events begin happening automatically). In summary, despite the enthusiasm to use z3 annotations, our experience actually integrating z3 annotations with an AT schema was tricky. Perhaps an AT storage layer which persists the data using a z3 annotation would be easiest way to integrate with AT schemas, but it does sound a bit silly - once you have a footprint of the persistence on the schema, might as well actually store the data there - maybe? Perhaps the content licensing effort can grow into a useful example for how and why to use z3 annotations in combination with AT derived objects. But don't underestimate the amount of work that still needs to happen for PLIP #150 to be completed. The upshot is we all learned a ton about the z3 lifecycle working this problem. It is worth detailing somewhere (here maybe ;-)) the effort that went in to integrating a z3 annotation and z3-style field with an Archetypes derived object and form.

As far as I can tell, that is basically what http://plone.org/products/plone/roadmap/150 is all about. If PLIP #150 had already been implemented, this project would have been much easier. As it was, we needed to figure out how to make z3 annotations appear on the properties tab, and be processed by the Archetypes processForm machinery.

Considering how everyone on irc and the mailing lists has been extolling the virtues of z3-annotations, you would think this would be a snap, but in this transitional period it actually got quite tricky (to us mortals, at least).

Luckily, Rob had encountered a similar situation while working on the openplans software itself (https://svn.openplans.org/svn/OpenPlans/trunk/), and recommending a starting point for thinking about the solution.

In their case, they first took advantage of the extra_bottom slot on the base_view template, and filled it with the z3 view of the field . Then, they subscribed their annotation object to modification events (https://svn.openplans.org/svn/OpenPlans/trunk/metadata.zcml/). Trouble is, that event is not fired currently by zope, and AT doesn’t fire it. Their current transitional solution is to decorate _processForm in a monkey patch (https://svn.openplans.org/svn/OpenPlans/trunk/monkey.py), “manually” firing the z3 event so that the annotation field is notified.

Even with this much contortion its still not a seamless integration since the z3 field is not going to be validated along with the other AT fields (we did confirm that the notified event will not get fired until the FormController finishes processing the rest of the fields).

In practice, we discovered that while base_edit has an extra slot, base_metadata does not. It also would have been wonderful had AT fired this event for us, if possible (Rob and Whit discussed the possibility of subscribing to a special event, not the normal one to avoid duplicate messages once events begin happening automatically).

In summary, despite the enthusiasm to use z3 annotations, our experience actually integrating z3 annotations with an AT schema was tricky. Perhaps an AT storage layer which persists the data using a z3 annotation would be easiest way to integrate with AT schemas, but it does sound a bit silly - once you have a footprint of the persistence on the schema, might as well actually store the data there - maybe?

Perhaps the content licensing effort can grow into a useful example for how and why to use z3 annotations in combination with AT derived objects. But don’t underestimate the amount of work that still needs to happen for PLIP #150 to be completed. The upshot is we all learned a ton about the z3 lifecycle working this problem.

]]>