Archetypes storage and versionning


CMFEditions is a Plone generic versionning product and a framework for more dedicataed versioning task like staging (Iterate). It was included in Plone bundle and is activated by default on new sites. It is very simple to use and well documented. A really nice poduct in a developer point of view and a very useful tool from a customer point of view. Diggig deeper you can find something dangerous from a storage point of view.

About storage

Then, what are we calling storage?

There’s the storage from Archetypes (AttributeStorage now replaced by AnnotationStorage, FileSystemStorage, SQLStorage, etc). They are the way we want to store a field value. Here we just want to know if it is inside or outside Zope… dig deeper…

There’s the storage from ZODB. They manage how each object is stored and what structure has the ZODB:

  • FileStorage: the ZODB is a single and potentialy big file called Data.fs
  • DirectoryStorage: each object in the ZODB is a folder in the filesystem and every object attribute is a file
  • RelStorage: object are stored in an external database (PostGresSQL)

These storages have now blob support for file object: it means that your file is stored outside the ZODB and this one just store the reference on it.

There’s also a CMFEditions storage to store versionning informations and data. It’s currently based on ZVC that store everything in the Data.fs.

How is created a document’s revision ?

CMFEditions doesn’t know anything about Archetypes. It’s a transversal tool that can be apadted quickly if we move from Archetypes to something else. And we want it to keep this independance.

When a new revision is created, the docuement is parse like a simple python object and each attribute is stored following different strategies define by some modifiers. An attribute doesn’t show which Archetypes storage is used for it. until know it supposes that AnnotationStorage or AttributeStorage is used the it just copie each attribute elsewhere in the ZODB. In the FileSystemStorage case the whole file is copied from the filesystem into the ZODB for each revision… here size does matter and smaller is better.

Do get storage information we need to use Archetypes API. Then we need an extra modifier for each Archetypes storage. But now, what to do with this information? You have to modify you specific Archetypes storage to be able to store revision informations and to restore them if needed. CMFEditions communicate a very few informations during these operations.

Novell Plone team submit a patch on FileSystemStorage to do such work and next releases would include it.

What to do to simplify storage inclosing

This approach doesn’t allow to define advanced strategies in Archetypes storages above versionning. But why do we need to defin advanced strategies in Archetypes storages?

The only real storages should be the ZODB storages. But they doesn’t allow advanced strategy creation to manage objects on different ways following some rules.

What is the advantage to have strategy implemented directly in the ZODB?

CMFEditions would not need to know anything about field storage: everything is managed by the ZODB. You don’t need to configure storage strategy in several configuration files and the developper doesn’t need to know about this. blob is one of this strategy. An Archetypes field would just indicate if it use standard or blob.

Feedback on Enfold Desktop 4 integration in customer project


Enfold Desktop is a very cool product for Windows users. Linux and Mac users already have builtin WebDav tools that do the trick. Enfold provides both server side products and client side user interface.

All this come from my only experience on Enfold Desktop 4 and may be there’s some errors. There no documentation for all this on Enfold Site

Client side

The client user interface needs to be installed on every computer that you want they use webdav access. It’s a plugin for the standard windows file explorer. Once you configured your access with the public url of your plone site you browse it like a local folder with a little time penalty but faster than in your web browser.

cooler than cool

hum, it’s not a water cooler advertising, but this product is really cool: in a Plone 3 site you can through your file explorer create new content types, modify and delete existing ones. You can doing a workflow transition. And for my customer site… we will see that point later.

Server side component

Enfold provide also an archive with several product that integrates your customer plone site for Enfold Desktop. It comes especially with the ShelExServer product that you have to install within the plone control panel. This product extend several tools to be more WebDav aware: content_type_registry and portal_workflow for example. It also modify permission for roles in the zope instance root.

Where things get more complicated

The last point is very useful in a plone site without any customization but can be very painful with a site managed with a policy registered in GenericSetup. Couple this with some bug in the last release candidate of Enfold Desktop 4 and you have a big mess.

What do I need to check after installing server side product

First: Don’t apply your customer profile before having update it at the end of this process. You will loose all Enfold Desktop settings.

Roles:

webdav access are correctly set in the zope instance root, but not in the plone instance root with Plone 3. Go in the Security tabs and fix webdav permissions for the three new roles: Editor, Contributor and Reader. Webdeav permissions have to be the same than on ‘View’ and ‘Access portal content’ permisions.

Workflows:

For each state webdav permissions are clone from ‘View’ and ‘Access portal content’… but the ‘acquire’ setting isn’t cloned during the operation. You have to fix that manually on each state of each workflow.

Content type registry:

Enfold Desktop create new predicates on base ATCT types, and only on them. If you need to manipulate your own types you have to confifure them manually.

Now you can export your profile and merge the modification in your customer profile.

More and more

It is impossible to modify which content type are created during a copy/paste: In one folder I want to create a document from a text file, in another I want to create a newsletter.

For HTML files created via webdav, the code is displayed as it until the document is edited and submit once.

It may be cool if Enfold Desktop can access to other web framework through webdav… May Sidney and Alan can answer on this.

portal_factory et acquisition


L’acquisition dans Zope et dans Plone est souvent utilisée pour attraper des attributs, ou des méthodes (CQFD), qui sont dans le chemin de l’objet.

Par exemple vous avez un chemin site / dossier1 / dossier2 / document.
Vous êtes dans document. Si la méthode getProduit n’existe pas dans cet objet, alors Zope va chercher dans dossier2 puis dans dossier1 si elle existe.
document.getProduit() renverra en fait dossier1.getProduit() de manière complètement transparente pour le programmeur. Mais…

portal_factory est un utilitaire qui permet de ne pas créer un document dans votre site Plone tant que tous les champs obligatoires ne sont pas remplis. Le document est créé en RAM dans portal_factory avant d’être déplacé dans le dossier parent d’origine.
Lors de la création d’un objet le chemin prend cette forme:
site / dossier1 / dossier2 / portal_factory / TypeName / id-temporaire

portal_factory qui est à la racine de votre instance Plone est virtuellement déplacé dans dossier2 pour bénéficier de l’acquisition de celui-ci.

Le problème est qu’il doit en même temps garder son contexte et le contexte du dossier d’origine. L’acquisition fonctionne de manière prévisible mais beaucoup moins transparente.
Du coup il est très difficile d’utiliser l’acquisition pour initialiser dans champs lors de la création des objets.
Pour être sur d’avoir une acquisition qui fonctionne il faut se placer dans le dossier d’origine en utilisant la méthode getFolderWhenPortalFactory.

Le code :

self.getProduit()

devient:

parent = self.getFolderWhenPortalFactory()

parent.getProduit()

N’oubliez pas que l’acquisition est un outil pratique et essentiel pour comprendre comment fonctionne Zope, mais qu’il ne faut pas l’utiliser à toute les sauces: les bogues d’acquisition font partis des bogues les plus pénibles à trouver et les plus simples à corriger à la source.

Ajouter un lecteur de mp3 à votre site Plone


Voici un lecteur simple à installer et à utiliser:
Dewplayer, lecteur mp3 pour page web
Dans les points importants à remarquer, le première est qu’il est vert, ce qui ne va pas avec toutes les chartes graphiques, et surtout qu’il ne lit pas les tags mp3. Pas moyen de savoir quel morceau est en court de lecture dans la version « multiple ».
Voici un exemple de macro metal pour l’intégrer dans votre site: mp3player.pt

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"
      i18n:domain=”plone”>
<body>
<div id=”portal-mp3-player”
     metal:define-macro=”player”
     i18n:domain=”plone”>
<object width=”240″ height=”20″ type=”application/x-shockwave-flash”
        data=”dewplayer-multi.swf?mp3=sound-theme/track1.mp3|sound-theme/track2.mp3″>
  <param name=”movie” value=”dewplayer-multi.swf?mp3=sound-theme/track1.mp3|sound-theme/track2.mp3″ />
</object>
</div>
</body>
</html>

À noter:

  • il faut au préalable télécharger le fichier swf à la racine de votre instance dans un ATFile ou un PloneExFile
  • les morceaux sont séparés par le caractère « | »
  • le chemin des morceaux est relatif par rapport à la racine de l’instance Plone: pas de « / » pour commencer le chemin

Voici le petit morceau de code à rajouter dans votre main_tempate.pt:

<metal:mp3player use-macro="here/mp3player/macros/player">
  MP3 Player in Flash
</metal:mp3player >