RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
Oooooh, a very good idea indeed! We'll have to look at that eventually. The mechanism you describe is preferable, but it should be noted that subversion properties are easily accessible using the clients. So long as said properties are human readable/writable, that's also an option. The main issue for me (And many others I suppose), is the fact that every single object type I use is either completely custom, or a monkey patched version of a built-in type (Notably OFS.Image for instance). So there would have to be a reliable serializer for "other" objects, which I beleive you already have, so that's OK :) What happens is you write a new serializer, notably write a custom serializer for an object type you've already been using for a while, using the "default" one ? (Presumably because you WANT to be able to access the contents from other tools) I think I noticed that somewhere in the .properties file there was a note of the class used for serializing ... Is there a way for a serialized instance to remember which serializer was used ? Or does everything break when I change the definition of a serializer (Old instances can no longer be read) ? J.F. -----Original Message----- From: zope-dev-bounces@zope.org To: Jean-Francois.Doyon@ccrs.nrcan.gc.ca Cc: hazmat@objectrealms.net; zope-dev@zope.org Sent: 14/04/2004 7:39 PM Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?) On Wed, 14 Apr 2004 Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote:
Fact is if one wanted a client to interact with a svn repository that stores zope objects, it would need to be fairly specifically designed for it ... How would a client (Say dreamweaver with a subversion plug-in) know that when editing an image, the x and y size properties need to be updated ? What if someone monkey patches the image type to add some other property/attribute ?
I would say Ape is quite good at accepting data from non-Zope-aware tools, and I'd like to make it better. The fact that Ape stores the image dimensions separately from the image content is an implementation decision in the serializer. You could instead tell the serializer to detect image dimensions when loading the object. The detection is a relatively inexpensive operation. Shane _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
On Thu, 15 Apr 2004 Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote:
What happens is you write a new serializer, notably write a custom serializer for an object type you've already been using for a while, using the "default" one ? (Presumably because you WANT to be able to access the contents from other tools)
I think I noticed that somewhere in the .properties file there was a note of the class used for serializing ... Is there a way for a serialized instance to remember which serializer was used ? Or does everything break when I change the definition of a serializer (Old instances can no longer be read) ?
Ape has a solution. Every object is stored with a classification. The classification (a dictionary of strings, stored in whatever format is chosen by apeconf.xml) has at least two keys: class_name and mapper_name. The mapper_name tells Ape which mapper was used to store the object, enabling Ape to reliably use the same mapper to load the object later. The class_name is used by mappers that work with multiple classes. When Ape stores a new state for an object previously loaded, it disregards the earlier choice of mapper. So, for example, lets say you've made a class called UltraPageTemplate, which subclasses ZopePageTemplate. If you store that using the default configuration, Ape won't try to guess how you meant to store it and will mostly just pickle it. The mapper_name will be "anyfile". Later, you add to apeconf.xml a mapper that specifically serializes UltraPageTemplate objects, using the mapper_name "Products.UltraPT.UltraPT.UltraPageTemplate". Ape will continue to load UltraPageTemplates stored using the "anyfile" mapper because the mapper_name supercedes the class_name when loading. However, when you store new UltraPageTemplates or update existing ones, Ape will use your new mapper, since the old choice of mapper is not consulted at save time. Therefore, to update all existing instances of UltraPageTemplate to use your new mapper, you only need to get ZODB to load all the existing instances and store them again unchanged. If your new mapper is complete, the old pickles will go away and people will be able to edit UltraPageTemplates outside Zope. Using strategies like this, Ape is trying to achieve a mode of development that doesn't require you to decide how to store objects at the same time you write classes. You start with ZODB, a radically simple, unintrusive storage layer, then you customize gradually with Ape. I think Ape is making good progress toward that goal. Shane
On Thu, 2004-04-15 at 00:16, Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote:
Oooooh, a very good idea indeed! We'll have to look at that eventually.
The mechanism you describe is preferable, but it should be noted that subversion properties are easily accessible using the clients.
So long as said properties are human readable/writable, that's also an option.
The main issue for me (And many others I suppose), is the fact that every single object type I use is either completely custom, or a monkey patched version of a built-in type (Notably OFS.Image for instance).
So there would have to be a reliable serializer for "other" objects, which I beleive you already have, so that's OK :)
i dunno if you use or have tried archetypes, but it has experimental support for generating the needed ape structures from its schema.. see archgenxml and archetypes/apesupport.. its pretty cool actually you cane go from a uml model straight to a content model with support. http://cvs.sourceforge.net/viewcvs.py/archetypes/Archetypes/ApeSupport.py?re... cheers, -kapil
participants (3)
-
Jean-Francois.Doyon@CCRS.NRCan.gc.ca -
Kapil Thangavelu -
Shane Hathaway