This issue sounds similar to ZScheduler's Schedule catalog.

In that case we decided to put the Schedule in the root folder. There is no
more global data than the catalog itself, but if there were it could be
stored in the catalog folder, since catalogs are folderish.

There used to be some code in ZScheduler to make the Schedule undeletable,
but I took it out during development because I got locked out too often. I
may put it back in later. I can make it public if you'd like.

ZScheduler's method creates this global data structure if and
only if it doesn't already exist. Because ZScheduler creates it, it can
assign the appropriate permissions and methods to manage the global
structure any way it wants.

-- Loren

> -----Original Message-----
> Of Andy Dawkins
> Sent: Friday, June 30, 2000 07:02
> To: Josh Zeidner; [EMAIL PROTECTED]
> Subject: RE: [Zope-dev] Product Data Storage
> >You should look into using ZCatalog for this purpose.
> OK - that is a solution that could solve my particular issue, but where
> would you put it?  Would you put it in the Product folder, or in
> some common
> place in the ZODB.
> How would you create it originally? In the products or by some
> kind of DTML method.
> Also would the ZCatalog be appropriate for storing general
> information to be
> shared between instances, Maybe some global configuration options.
> I am looking for a generalised method of storing Class Level Variables.
> Maybe properties within the Product folder.
> But above all I am looking for a method of doing this that the Zope
> community agrees as being efficient and recognises as being _the_ solution
> to the problem.  I want to avoid a 'hack' solution if possible.
> -Andy Dawkins
> (New Information Paradigms Ltd)
> _______________________________________________
> Zope-Dev maillist  -  [EMAIL PROTECTED]
> **  No cross posts or HTML encoding!  **
> (Related lists -
> )

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to