Le 14 mai 08 à 19:03, Andreas Jung a écrit :
--On 14. Mai 2008 18:28:37 +0200 Gilles Lenfant <[EMAIL PROTECTED]
> 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
</sites>
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
installed.
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.
Cheers
--
Gilles Lenfant
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 »
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
