Author: jmorliaguet
Date: Thu Nov  3 22:09:16 2005
New Revision: 28942


- added some design ideas about hybrid storages

Modified: z3lab/cpsskins/branches/jmo-perspectives/storage/README.txt
--- z3lab/cpsskins/branches/jmo-perspectives/storage/README.txt (original)
+++ z3lab/cpsskins/branches/jmo-perspectives/storage/README.txt Thu Nov  3 
22:09:16 2005
@@ -1,22 +1,202 @@
-This package defines storage containers.
-Each storage is associated with a certain type of content.
-Available storages are:
+This package defines storages.
-- display storage
-- format storage
+A storage contains objects (resources, images, portlets, ...) that are used by
+the application. Objects can be stored in the ZODB or be filesystem resources.
-- perspective storage
+Design goals
-- portlet storage
+The main design goal of this type of storage is to allow transparent access to
+objects located in the storage independently of the way in which they have been
+created (i.e. TTW or via the filesystem).
-- resource storage
+Filesystem-based vs. persistent objects
-- relation storage
+Filesystem-based configurations (e.g. zope configuration system) store
+information about objects on the filesystem: when the application server is
+started the server stores objects in memory based on the configuration.
+The objects can be modified by the application, but the modifications are lost
+as soon the server is restarted.
+Unless users have access to the filesystem, the objects created in this way
+can be considered as read-only resources. This poses a problem in case the
+objects need to be modified by users who only work through the web.
+A solution is to create such objects as persistent content classes from the
+beginning, but this make filesystem-based development difficult.
+Different patterns
+The main issue is that the patterns used when working with filesystem-based
+objects and with persistent objects are quite different:
+- objects configured on the filesystem are considered by the application as
+  simple resources stored in a registry. They are not supposed to be
+  manipulated by users.
+- objects stored in the ZODB are meant to be manipulated by users but
+  they are difficult to access via a registry unless they are cataloged.
+The results is that different APIs get implemented based on the type of
+object, and sometimes it is the entire application that supports one way of
+working with objects or the other.
+Use case 1: application developer
+Developing an application through-the-web is not very efficient.
+Application developers will most likely take the filesystem-based configuration
+approach for creating application resources (actions, skins, templates,
+workflows, ...). This makes it easier to collaborate on software repositories.
+Use case 2: site designers
+Site designers will most likely want to work directly through-the-web and
+export site configurations to the filesystem when they are satisfied with the
+Conflicting interests
+This situation causes conflicts of interests since the developers will claim
+that resources ought be stored on the filesystem and site designers will claim
+that working through-the-web is a better approach.
+The result is that some of the resources in the application shared by both
+developers and by site designers cannot be considered as "filesystem-only"
+or as "TTW-only" resources, they have to be considered as both.
+The current pattern in Zope3 is to not support TTW development. This partly
+solves the issue, but only if by "development" one really means development.
+It can be argued that site creation is not done by developers but by site
+designers. If this former category of users is to be empowered, a model that
+mixes filesystem-based and through-the-web "development" is needed.
+The storage described here treats filesystem-based objects as if they were
+read-only objects stored in the ZODB.
 Each storage implements the base IStorage interface and may also implement more
-specific interfaces depending on the type of object stored.
+specific interfaces depending on the type of object stored::
+class IStorage(Interface):
+    def add(object, name):
+        """Add an object to the storage. Return the added object.
+        The object's name can be specified.
+        """
+    def remove(objects):
+        """Remove a list of objects from the storage."""
+    def duplicate(object):
+        """Duplicate an object in the storage. Return the duplicated object."""
+    def __setitem__(object):
+        """Set an object into the storage."""
+    def __getitem__(item):
+        """Get an item from the storage."""
+    def customize(object):
+        """Turn a filesystem object into a persistent object."""
+    def decustomize(object):
+        """Convert a customized object back into a filesystem object."""
+The storage interface is also used to identify the storage.::
+class IMyStorage(IStorage):
+    contains(ISomeTypeOfObject)
+    def doSomethingSpecial():
+        """Do something special with the stored objects"""
+Storages are registered in ZCML::
+    xmlns:cpsskins="";>
+  <cpsskins:storage
+      id="mystorage"
+      title="My storage"
+      description="A description of my storage"
+      factory=".mystorage.MyStorage"
+      interface=".mystorage.IMyStorage"
+  />
+Adding filessystem objects to the storage
+When an object is registered in ZCML it is possible to specify the
+storage to which it will be add. This can be done in
+instead of writing::
+   some_registry = getUtility(ISomeRegistry)
+   some_registry.register(name, some_object)
+one would write:
+   some_storage = queryUtility(IMyStorage)
+   some_storage.add(some_object)
+The object is physically stored in memory but for the application it appears as
+though the object is located in the storage with other ZODB objects.
+It is the responsibility of the ZCML configuration handler to add objects
+to the registry. Hence the storage is unaware of the configuration method.
+Customizing objects
+Sometimes an object configured on the filesystem needs to become persistent
+This is the equivalent of the "Customize" function in Zope2's portal skins.
+A copy of the original object is created and replaces the customized object.
+Decustomizing objects
+Customized objects are not destroyed, hence it is easy to reverse the
+Filesystem-based objects are to be considered as read-only, hence they should
+appear as being locked or not being writable by the application.

Reply via email to