Jochen and I started thinking about implementing placeless content for Plone. We need to get something like this implemented as it’s of use for a client of ours.
So here’s the first board shot from our thoughts. I will put this into a more readable format with comments soon and we will add this to the Brainstorming section.
So let me explain a bit what you see on that picture.
First for the context: Our client wants to have two separate sites which are basically the same but differ in some places. So one page might be available in one site but not in the other (marked K and B in the above picture). Moreover some pages might differ in content between sites.
Another requirement is then that the editor can choose whether a change will be done in both sites (like adding an object) or just locally. So both sites need to be connected somehow.
On the bottom you see an area called the Content Repository. This is where the actual content objects (might be AT types) live. They are organized all in one folder. Every content object has got an id which never changes (and can simply be numeric). And to do versioning these objects are not directly in that folder but instead there are version folders. Every version folder stands for an object and contains multiple versions of that object. So when creating a new version, the actual object will just be copied inside that folder. The version folder knows which version is the latest and might store additional versioning information (maybe also which one is the actual version in editing state).
On top of the screen you see the actual sites, two of them, marked as K and B. Every site consists of so called proxy objects (the round ones) which make up the structure. Every proxy object contains a link to one content object in the content repository (actually the id then). Every proxy object also contains references to it’s children. This can either be done by normal containment or by using references. In the latter case the URL must not correspond to the actual path (so everything is a tinyurl). It depends on the client though (and also if they just have numbers as id or text labels as it is now).
Both sites will be either published under different domains (but pointing to the same server) or by some path prefix. This is open to discussion with the client.
One problem now was how to track structural changes made in one site. E.g. one editor might want to add some subobject to object 4 in site K. The system needs to know which object does correspond to that in site B (if any). It needs to add the same proxy object on that site, too (pointing to the same content object). So we thought about some sort of registry which can be seen in the bottom right corner and having red text. This red mapping corresponds to the red arrows in the structural part of the drawing. So every proxy object knows which other proxy objects correspond with it. Is a new object created so the others will be notified to also add it (via some event mechanism) and a new link is created between the newly created subobjects. This will also work then inside a site (e.g. for doing something like symbolic links).
The actual placeless editing might be done by using Pipelines or by simply editing the content object directly and storing the actual location of the proxy object in the session or such. We actually don’t want to deal too much with the inner mechanism of Zope like as hooking into traversal or acquisition. A quick test showed that it worked by using Pipelines (but there we need to rebuild all the widgets as the AT widget engine is not reusable in other projects right now).