I have to say that I agree with you Dieter. It would be very useful to have the ZClasses that relate to a project in a single branch with the rest of the project code for a number of reasons
* Security (As you said). Users could have full write permissions to one branch only.
* Backups or exporting from development to production servers. With the code all in one place, it would be possible to export the entire project from a development server and import it to the production server in one action (Ok, one action each end) eliminating the possibility of getting code and ZClasses out of sync.
* Reducing the size of the "Add List" - This has to be a pain for everyone!
However I also understand the appeal of having a central, restricted, ZClass repository as well, it just serves a different (Not incompatible) purpose. I think that both situations would be useful ... Now we just need to find out if they are possible. :)
--
Adrian Hungate
Manager, European I.S.
Acucorp UK Limited
"To a database person, every nail looks like a thumb. Or something like that."
- Jamie W. Zawinski
http://www.zopezen.org/Zope/Quotes
-----Original Message-----
From: Dieter Maurer [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 26 June 2001 05:07
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [Zope-dev] ZClass not in a Product
Joachim Werner writes:
> I know about the "duality" of Python classes. I just don't see what I could
> really do with a ZClass in the "instance space" (reading this twice, see
> below for some possible examples). A totally different aspect is whether
> Zope should have something like an in-built support for "virtual instances",
> i.e. sub-folders could be like full Zope instances, providing a local
> Products directory etc.
To clarify, you use "instance" here in the spirit of "Zope instance"
a-la "INSTANCE_HOME" and not in the sense of "instance" of a class...
That would probably be a good thing.
> I am more in favor of getting things OUT of the instance folders than
> getting more stuff in.
That is completely different from what I would like to do.
> It makes absolutely no sense to me why the Zope management interface
> displays database adaptors, user folders, and actual content objects all in
> the same folder.
It makes lots of sense for me!
Consider a large site hosting many applications, partly
developed and maintained by different people/departments.
It is very nice to be able to structure the site hierarchy
into folders corresponding to appliciations and allow each
team responsible for an application to put in
everything they need for the implementation:
database adapters, additional user definitions,
special roles, ZClasses, ....
Zope already allows this partially. Unfortunately, the
product registry is global and not managed similar
to user folders.
Your proposed "virtual instances" would be an alternative
solution. I could live with it, though I would not
think it is better.
> ....
> To come back to the ZClass question: I see and use them mainly as templates.
> That's what they are good for. So they should reside in a template folder.
> Right now, this folder is the Products folder. Maybe we need local
> Products/Templates folders, so that it is possible to have ZClasses that
> just work locally or that overload a base ZClass defined up in the tree. But
> what we definitely don't need is freely floating ZClasses.
I am much in favor to structure objects *NOT* according to type
(e.g. all images in a folder, all SQL methods in a folder,
all Scripts in a folder, ...) but according to
applications/services:
One folder for each service which contains everything needed
only for this service: images, scripts, SQL methods, content,
ZClasses, ....
There are things that are used more globally. They may
go into type specific folders.
> ...
Dieter
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
