gilles.lenfant at ingeniweb.com
Wed May 14 17:29:37 UTC 2008
Le 14 mai 08 à 19:03, Andreas Jung a écrit :
> --On 14. Mai 2008 18:28:37 +0200 Gilles Lenfant <gilles.lenfant at ingeniweb.com
> > wrote:
>> Le 14 mai 08 à 18:05, Andreas Jung a écrit :
>> >> <sites>
>>> storage-strategy site1
>>> storage-path $$INSTANCEHOME/var//%(site_id)s/fss
>>> # storage-path $$INSTANCEHOME/var//%(path_to_site)s/fss
>>> FSS could fill in either the id of a plone site or the flat path
>>> to a site (in case of ambiguity).
>> Yup, this sounds realistic and reasonable, this means :
>> * FSS should create its storage directories for the site in its GS
>> handler (better place ?)
> What do you mean by that?
iw.fss doesn't create the missing storage/backup spaces, but screams
at Zope startup if these are missing. With the change you suggest,
this means that the storage/backup real paths must be created somehow
when a new site with content types using iw.fss is created. IMO, the
best place to do this is the setuphandler of iw.fss.
>> * Users should **never** rename or , move a Plone site with FSS
> Not sure if you can capture such a situation in FSS. An exception
> with a clear hint to rename the storage directory on the filesystem
> manually should be enough?!
Actually this situation is not captured because iw.fss uses the
default (zope instance wide) settings for iw.fss. We just threat users
to loose their job, money, house, wife, children, dog, (...) if they
don't pay attention to the doc that ships with iw.fss.
We might later capture such situation when the site config object has
a storage path that doesn't exist. Perhaps we could mark the various
storage paths withs a .fssmetadata file asserting we're at the right
place, but that's another story.
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline
1 rue Royal
92210 Saint Cloud
web : www.ingeniweb.com - « les Services Web Ingénieux »
More information about the Product-Developers