[Zope-dev] ZClass not in a Product

Mon, 2 Jul 2001 03:52:10 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C102E6.092DE1A0
Content-Type: text/plain;
	charset="iso-8859-1"

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:dieter@handshake.de]
Sent: Tuesday, 26 June 2001 05:07
To: joe@iuveno-net.de
Cc: zope-dev@zope.org
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  -  Zope-Dev@zope.org
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 )

------_=_NextPart_001_01C102E6.092DE1A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: [Zope-dev] ZClass not in a Product</TITLE>
</HEAD>
<BODY>

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.

<P><FONT SIZE=3D2>* Reducing the size of the &quot;Add List&quot; - =
This has to be a pain for everyone!</FONT>
</P>

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. =
:)

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Adrian Hungate</FONT>
<BR><FONT SIZE=3D2>Manager, European I.S.</FONT>
<BR><FONT SIZE=3D2>Acucorp UK Limited</FONT>
</P>

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;To a =
database person, every nail looks like a thumb. Or something like =
that.&quot;
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Jamie W. =
Zawinski 
 <A HREF=3D"http://www.zopezen.org/Zope/Quotes" =
TARGET=3D"_blank">http://www.zopezen.org/Zope/Quotes</A>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Dieter Maurer [<A =
HREF=3D"mailto:dieter@handshake.de">mailto:dieter@handshake.de</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: Tuesday, 26 June 2001 05:07</FONT>
<BR><FONT SIZE=3D2>To: joe@iuveno-net.de</FONT>
<BR><FONT SIZE=3D2>Cc: zope-dev@zope.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Zope-dev] ZClass not in a =
Product</FONT>
</P>
<BR>

Joachim Werner writes:
 &nbsp;&gt; I know about the &quot;duality&quot; of =
Python classes. I just don't see what I could
 &nbsp;&gt; really do with a ZClass in the =
&quot;instance space&quot; (reading this twice, see
 &nbsp;&gt; below for some possible examples). A =
totally different aspect is whether
 &nbsp;&gt; Zope should have something like an =
in-built support for &quot;virtual instances&quot;,
 &nbsp;&gt; i.e. sub-folders could be like full Zope =
instances, providing a local
 &nbsp;&gt; Products directory etc.
 To clarify, you use &quot;instance&quot; here in the =
spirit of &quot;Zope instance&quot;
 a-la &quot;INSTANCE_HOME&quot; and not in the sense =
of &quot;instance&quot; of a class...

<P><FONT SIZE=3D2>That would probably be a good thing.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt; I am more in favor of getting things OUT =
of the instance folders than</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt; getting more stuff in.</FONT>
<BR><FONT SIZE=3D2>That is completely different from what I would like =
to do.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&gt; It makes absolutely no sense to me why the =
Zope management interface</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt; displays database adaptors, user =
folders,&nbsp; and actual content objects all in</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt; the same folder.</FONT>
<BR><FONT SIZE=3D2>It makes lots of sense for me!</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; Consider a large site hosting many =
applications, partly</FONT>
<BR><FONT SIZE=3D2>&nbsp; developed and maintained by different =
people/departments.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; It is very nice to be able to structure the =
site hierarchy</FONT>
<BR><FONT SIZE=3D2>&nbsp; into folders corresponding to appliciations =
and allow each </FONT>
<BR><FONT SIZE=3D2>&nbsp; team responsible for an application to put =
in</FONT>
<BR><FONT SIZE=3D2>&nbsp; everything they need for the =
implementation:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; database adapters, additional user =
definitions,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; special roles, ZClasses, =
....</FONT>
</P>

&nbsp; Zope already allows this partially. =
Unfortunately, the
 &nbsp; product registry is global and not managed =
similar
 &nbsp; to user folders.

&nbsp; Your proposed &quot;virtual instances&quot; =
would be an alternative
 &nbsp; solution. I could live with it, though I =
would not
 &nbsp; think it is better.

&nbsp;&gt; ....
 &nbsp;&gt; To come back to the ZClass question: I =
see and use them mainly as templates.
 &nbsp;&gt; That's what they are good for. So they =
should reside in a template folder.
 &nbsp;&gt; Right now, this folder is the Products =
folder. Maybe we need local
 &nbsp;&gt; Products/Templates folders, so that it is =
possible to have ZClasses that
 &nbsp;&gt; just work locally or that overload a base =
ZClass defined up in the tree. But
 &nbsp;&gt; 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:

<P><FONT SIZE=3D2>&nbsp; One folder for each service which contains =
everything needed</FONT>
<BR><FONT SIZE=3D2>&nbsp; only for this service: images, scripts, SQL =
methods, content,</FONT>
<BR><FONT SIZE=3D2>&nbsp; ZClasses, ....</FONT>
</P>

&nbsp; There are things that are used more globally. =
They may
 &nbsp; go into type specific folders.

<P><FONT SIZE=3D2>&nbsp;&gt; ...</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Dieter</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Zope-Dev maillist&nbsp; -&nbsp; =
Zope-Dev@zope.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://lists.zope.org/mailman/listinfo/zope-dev" =
TARGET=3D"_blank">http://lists.zope.org/mailman/listinfo/zope-dev</A></F=
ONT>
<BR><FONT SIZE=3D2>**&nbsp; No cross posts or HTML encoding!&nbsp; =
**</FONT>
<BR><FONT SIZE=3D2>(Related lists - </FONT>
<BR><FONT SIZE=3D2>&nbsp;<A =
HREF=3D"http://lists.zope.org/mailman/listinfo/zope-announce" =
TARGET=3D"_blank">http://lists.zope.org/mailman/listinfo/zope-announce</=
A></FONT>
<BR><FONT SIZE=3D2>&nbsp;<A =
HREF=3D"http://lists.zope.org/mailman/listinfo/zope" =
TARGET=3D"_blank">http://lists.zope.org/mailman/listinfo/zope</A> =
)</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C102E6.092DE1A0--