From jeff at bottlerocket.net  Tue Feb  3 12:04:36 2004
From: jeff at bottlerocket.net (Jeffrey P Shell)
Date: Tue Feb  3 12:23:41 2004
Subject: [Zope3-dev] products.securitypolicy and ZCML 'grant'/'role'
Message-ID: <0BD186D5-566B-11D8-A7B8-003065415378@bottlerocket.net>

Shouldn't the line importing the security policy come first?

<include package="zope.products.securitypolicy"/>

It took me a while to figure out why some products in my file were 
dying when the 'zcml' tried to use the ZCML zope:role directive.

Since securitypolicy is now a product (and I missed why this occurred, 
but it explains why I was having startup problems earlier on an old 
sandbox that I thought had just gotten woefully out of date), should it 
still be putting ZCML directives into the most common namespace?

--
Jeffrey P Shell
jeff@bottlerocket.net


From jeff at bottlerocket.net  Tue Feb  3 16:46:13 2004
From: jeff at bottlerocket.net (Jeffrey P Shell)
Date: Tue Feb  3 16:46:26 2004
Subject: [Zope3-dev] Calling persistent function
In-Reply-To: <40128191.9020103@z3u.com>
References: <20040122211459.68769.qmail@web20726.mail.yahoo.com>
	<40128191.9020103@z3u.com>
Message-ID: <6350F472-5692-11D8-A7B8-003065415378@bottlerocket.net>

On Jan 24, 2004, at 7:30 AM, Steve Alexander wrote:

>
>> One problem I have with that is that
>> modules['time'].asctime() is forbidden in zpt.  How do
>> I put the time and date in a zpt template?
>
> Make it not forbidden in zpt?
>
> I'd also like to see a <script> tag work for this, so that python code 
> can be embedded in ZPTs in a natural kind of way.
>
> You shouldn't need to play with utilities to get this simple task done.

You shouldn't need a script tag to get this done either with ZPT::

     <h1 tal:content="modules/time/asctime">[current time]</h1>

versus::

     <h1>
       <script type="text/server-python">
         import time
         print time.asctime()
       </script>
     </h1>

Again - if this is the norm, then we are regressing.  JSP and ASP have 
moved beyond this style, and by the time Zope 3 actually does something 
useful, even PHP will have finally separated itself from between its 
core programming language features and use as a templating system.


I know, I know, I know, we've been through this fight before and I'm 
not going to fight it again.  My fears over Zope 3 at the moment are 
sadly greater than my intrigue, because I feel either insanely neutered 
('content-space', where I haven't gotten anything besides a folder to 
do its job), or insanely overwhelmed.  It's taken me until yesterday to 
finally figure out the service registration/activation thing.

:\


From philipp at weitershausen.de  Wed Feb  4 12:12:06 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Wed Feb  4 12:05:30 2004
Subject: [Zope3-dev] Moving more stuff to zope.products
Message-ID: <bvr8od$o8u$1@sea.gmane.org>

Hi there,

in the currently ongoing process of reorganizing Zope3's package 
structure and gutting out zope.app, I think the main packages that have 
yet to be moved are:

- zope.app.workflow
- zope.app.content
- browser skins

While the first is probably easy to agree on, I realize that the latter 
could be a point of discussion.

Anthony Baxter argued that just moving zope.app.content to 
zope.products.content will not flatten the product hierarchy at all. 
That is certainly true since the depth of the package remains the same, 
however the package hierarchy will be straightened out a lot. Remember 
how all interfaces are in zope.app.interfaces.content, all browsers 
views are in zope.app.browser.content...? (see discussion several months 
ago...)
 From a philosophical point of view, content objects are custom to any 
application. I have application where I never need Folder, File or weird 
(forbidden?) stuff like Templated Page. Thus, one could argue that all 
optional stuff belongs in zope.products, not in the core.

The same essential argument applies to the browser skins. Here, it makes 
even more sense, because a browser skin is usually the first thing a 
developer will customize in his/her own application anyway. By marking 
them as optional by moving them zope.products, we encourage people to 
actually do so. Otherwise we'll end up with the Plone dilemma, in which 
every Plone site looks like plone.org, at least very similar.

There's another practical point for the skins. zope.products packages 
are required to have a specified maintainer. IMO, the skins, especially 
ZopeTop, have been not been taken care of enough recently. I think we 
all agree that the UI needs more attention, something that a dedicated 
maintainer of the skins package could be responsible of.

Looking-for-comments-ly,

Philipp



From gintas at pov.lt  Wed Feb  4 12:05:53 2004
From: gintas at pov.lt (Gintautas Miliauskas)
Date: Wed Feb  4 12:15:03 2004
Subject: [Zope3-dev] zsync
Message-ID: <20040204170553.GA4405@gintm>

Hello,

While trying to put Zope3 into practical use, I have come across an
issue: zsync only handles typical page templates and folders, and b0rks
on other, specialized objects. Everything is fine until there is need to
modify the object in ZODB (e.g. after manually editing the dumped XML or
deleting the ZODB object), then the actual object in ZODB is replaced
with the source of dumped XML rather than a true object.

At first I thought that this is simply something that hasn't been
implemented, but Steve said it should work with anything, so I thought
I'd bring it to your attention.

P.S. I tested with the ZODB3 branch too, results are the same.

-- 
 Gintautas

From jeff at bottlerocket.net  Wed Feb  4 13:31:20 2004
From: jeff at bottlerocket.net (Jeffrey P Shell)
Date: Wed Feb  4 13:31:32 2004
Subject: [Zope3-dev] Moving more stuff to zope.products
In-Reply-To: <bvr8od$o8u$1@sea.gmane.org>
References: <bvr8od$o8u$1@sea.gmane.org>
Message-ID: <5426ABC8-5740-11D8-A7B8-003065415378@bottlerocket.net>

On Feb 4, 2004, at 10:12 AM, Philipp von Weitershausen wrote:

> Hi there,
>
> in the currently ongoing process of reorganizing Zope3's package 
> structure and gutting out zope.app, I think the main packages that 
> have yet to be moved are:
>
> - zope.app.workflow
> - zope.app.content
> - browser skins
>
> While the first is probably easy to agree on, I realize that the 
> latter could be a point of discussion.
>
> Anthony Baxter argued that just moving zope.app.content to 
> zope.products.content will not flatten the product hierarchy at all. 
> That is certainly true since the depth of the package remains the 
> same, however the package hierarchy will be straightened out a lot. 
> Remember how all interfaces are in zope.app.interfaces.content, all 
> browsers views are in zope.app.browser.content...? (see discussion 
> several months ago...)
> From a philosophical point of view, content objects are custom to any 
> application. I have application where I never need Folder, File or 
> weird (forbidden?) stuff like Templated Page. Thus, one could argue 
> that all optional stuff belongs in zope.products, not in the core.

Zope 2 separated out core OFS items (analogous to zope.app.content, I 
assume) from 'Products.OFSP' (OFS Product).  OFSP seems to be a bit of 
a graveyard, consisting of 'Version' and 'Draft' objects (the latter 
never being officially completed and exposed to the outside world).  It 
would probably be wise to avoid a situation like that.

I need to find out more about the dependencies on usage of 
zope.products.  I'm a bit stymied at the zope.products.securitypolicy 
implementation as it stands now, because it seems like it's something a 
lot of other elements (at least, products) could depend on (using the 
ZCML 'role' and 'grant' tags, which are added to the main 'zope:' tag 
namespace).  If there are very very very common products that are 
likely to be used by everybody (at least, everybody starting out), 
'products.zcml.in' needs to stay up to date with a good basic setup and 
comments, such as 'lots of products may depend on these, so they should 
be loaded first' and then the 'here's some optional products'.  When I 
was playing with Zope 3 a couple of days ago (for the first time in 
quite a while), my instincts on where to place product loads didn't 
quite work out.

Is there any document about how zope.products is meant to be used?  The 
Wiki didn't yield anything helpful - is it all in the archives of the 
zope3-dev list?

--
Jeffrey P Shell
jeff@bottlerocket.net


From casey at zope.com  Wed Feb  4 13:43:18 2004
From: casey at zope.com (Casey Duncan)
Date: Wed Feb  4 13:46:04 2004
Subject: [Zope3-dev] Moving more stuff to zope.products
In-Reply-To: <bvr8od$o8u$1@sea.gmane.org>
References: <bvr8od$o8u$1@sea.gmane.org>
Message-ID: <20040204134318.65ee7044.casey@zope.com>

On Wed, 04 Feb 2004 18:12:06 +0100
Philipp von Weitershausen <philipp@weitershausen.de> wrote:

> Hi there,
> 
> in the currently ongoing process of reorganizing Zope3's package 
> structure and gutting out zope.app, I think the main packages that
> have yet to be moved are:
> 
> - zope.app.workflow
> - zope.app.content
> - browser skins
> 
> While the first is probably easy to agree on, I realize that the
> latter could be a point of discussion.
> 
> Anthony Baxter argued that just moving zope.app.content to 
> zope.products.content will not flatten the product hierarchy at all. 
> That is certainly true since the depth of the package remains the
> same, however the package hierarchy will be straightened out a lot.
> Remember how all interfaces are in zope.app.interfaces.content, all
> browsers views are in zope.app.browser.content...? (see discussion
> several months ago...)
>  From a philosophical point of view, content objects are custom to any
>  
> application. I have application where I never need Folder, File or
> weird (forbidden?) stuff like Templated Page. Thus, one could argue
> that all optional stuff belongs in zope.products, not in the core.

+++1
 
> The same essential argument applies to the browser skins. Here, it
> makes even more sense, because a browser skin is usually the first
> thing a developer will customize in his/her own application anyway. By
> marking them as optional by moving them zope.products, we encourage
> people to actually do so. Otherwise we'll end up with the Plone
> dilemma, in which every Plone site looks like plone.org, at least very
> similar.

ditto.
 
In general I think anything that describes policy that will be
overridden with any frequency (like 1 or more times ;^) should not be in
the core. Some others I think we might consider moving:

onlinehelp
rdb
schemagen (is this even still used?)
security? (not sure but it seems policyish)
services (not the whole thing, but this seems like a big grab-bag)

Another partially related thought:

Why don't the __init__.py files have a (terse) docstring that explains
the purpose of the package? Some of their names are so general, that
their purpose is not readily apparent. Even something like """The splat
package facilitates the canonical splat protocol from rfc1234""" would
be very helpful.

-Casey


From anthony at interlink.com.au  Wed Feb  4 20:49:00 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Wed Feb  4 20:49:53 2004
Subject: [Zope3-dev] Moving more stuff to zope.products 
In-Reply-To: <bvr8od$o8u$1@sea.gmane.org> 
Message-ID: <20040205014900.D4FA425B4BA@bonanza.off.ekorp.com>


My theory on this was that anything that's needed for Z3 to actually
boot up shouldn't be in zope.products. I'd like to see that anything
in zope.products _could_ be dropped without ill-effect. Philipp 
pointed out that under this scheme, zope.products.securitypolicy
should be in zope.app. 

Anthony
-- 
Anthony Baxter     <anthony@interlink.com.au>   
It's never too late to have a happy childhood.


From jim at zope.com  Wed Feb  4 21:28:23 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Feb  4 21:30:22 2004
Subject: [Zope3-dev] Moving more stuff to zope.products
In-Reply-To: <bvr8od$o8u$1@sea.gmane.org>
References: <bvr8od$o8u$1@sea.gmane.org>
Message-ID: <4021AA47.1000804@zope.com>

Philipp von Weitershausen wrote:
> Hi there,
> 
> in the currently ongoing process of reorganizing Zope3's package 
> structure and gutting out zope.app, I think the main packages that have 
> yet to be moved are:
> 
> - zope.app.workflow
> - zope.app.content
> - browser skins
> 
> While the first is probably easy to agree on, I realize that the latter 
> could be a point of discussion.
> 
> Anthony Baxter argued that just moving zope.app.content to 
> zope.products.content will not flatten the product hierarchy at all. 
> That is certainly true since the depth of the package remains the same, 
> however the package hierarchy will be straightened out a lot. Remember 
> how all interfaces are in zope.app.interfaces.content, all browsers 
> views are in zope.app.browser.content...? (see discussion several months 
> ago...)

Yup

>  From a philosophical point of view, content objects are custom to any 
> application. I have application where I never need Folder, File or weird 
> (forbidden?) stuff like Templated Page. Thus, one could argue that all 
> optional stuff belongs in zope.products, not in the core.

It's a bit hard to imagine a Zope without folder.

> The same essential argument applies to the browser skins.

yes

> Here, it makes 
> even more sense, because a browser skin is usually the first thing a 
> developer will customize in his/her own application anyway. By marking 
> them as optional by moving them zope.products, we encourage people to 
> actually do so. Otherwise we'll end up with the Plone dilemma, in which 
> every Plone site looks like plone.org, at least very similar.
> 
> There's another practical point for the skins. zope.products packages 
> are required to have a specified maintainer. IMO, the skins, especially 
> ZopeTop, have been not been taken care of enough recently. I think we 
> all agree that the UI needs more attention, something that a dedicated 
> maintainer of the skins package could be responsible of.

Agreed.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Wed Feb  4 21:35:23 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Feb  4 21:37:26 2004
Subject: [Zope3-dev] Moving more stuff to zope.products
In-Reply-To: <5426ABC8-5740-11D8-A7B8-003065415378@bottlerocket.net>
References: <bvr8od$o8u$1@sea.gmane.org>
	<5426ABC8-5740-11D8-A7B8-003065415378@bottlerocket.net>
Message-ID: <4021ABEB.9040202@zope.com>

Jeffrey P Shell wrote:
> On Feb 4, 2004, at 10:12 AM, Philipp von Weitershausen wrote:
> 
>> Hi there,
>>
>> in the currently ongoing process of reorganizing Zope3's package 
>> structure and gutting out zope.app, I think the main packages that 
>> have yet to be moved are:
>>
>> - zope.app.workflow
>> - zope.app.content
>> - browser skins
>>
>> While the first is probably easy to agree on, I realize that the 
>> latter could be a point of discussion.
>>
>> Anthony Baxter argued that just moving zope.app.content to 
>> zope.products.content will not flatten the product hierarchy at all. 
>> That is certainly true since the depth of the package remains the 
>> same, however the package hierarchy will be straightened out a lot. 
>> Remember how all interfaces are in zope.app.interfaces.content, all 
>> browsers views are in zope.app.browser.content...? (see discussion 
>> several months ago...)
>> From a philosophical point of view, content objects are custom to any 
>> application. I have application where I never need Folder, File or 
>> weird (forbidden?) stuff like Templated Page. Thus, one could argue 
>> that all optional stuff belongs in zope.products, not in the core.
> 
> 
> Zope 2 separated out core OFS items (analogous to zope.app.content, I 
> assume) from 'Products.OFSP' (OFS Product).  OFSP seems to be a bit of a 
> graveyard, consisting of 'Version' and 'Draft' objects (the latter never 
> being officially completed and exposed to the outside world).  It would 
> probably be wise to avoid a situation like that.

Yup.  As mentioned in a previous thread on this topic, there will be
a process for retiring subpackages of products.  If products don't
retain a maintainer, the will eventually go away.  It's likely that there
will be some pruning prior to the first beta.

> I need to find out more about the dependencies on usage of 
> zope.products.  I'm a bit stymied at the zope.products.securitypolicy 
> implementation as it stands now, because it seems like it's something a 
> lot of other elements (at least, products) could depend on

I don't think so.

 > (using the
> ZCML 'role' and 'grant' tags, which are added to the main 'zope:' tag 
> namespace). 

Products should never use these. Only the site file should use these.

You are correct that these shouldn't be in the zope namespace.


 > If there are very very very common products that are likely
> to be used by everybody (at least, everybody starting out), 
> 'products.zcml.in' needs to stay up to date with a good basic setup and 
> comments, such as 'lots of products may depend on these, so they should 
> be loaded first' and then the 'here's some optional products'.  When I 
> was playing with Zope 3 a couple of days ago (for the first time in 
> quite a while), my instincts on where to place product loads didn't 
> quite work out.

In general, products should not depend on other products.
If there's a product that many other products depend on, then
it should probably be in the core. The security policy is *not*
such a product.

> Is there any document about how zope.products is meant to be used?  The 
> Wiki didn't yield anything helpful - is it all in the archives of the 
> zope3-dev list?

Well, there's src/zope/products/README.txt. :)

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Wed Feb  4 21:38:27 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Feb  4 21:40:31 2004
Subject: [Zope3-dev] Moving more stuff to zope.products
In-Reply-To: <20040204134318.65ee7044.casey@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org>
	<20040204134318.65ee7044.casey@zope.com>
Message-ID: <4021ACA3.7090308@zope.com>

Casey Duncan wrote:
...

> In general I think anything that describes policy that will be
> overridden with any frequency (like 1 or more times ;^) should not be in
> the core.

Well said.

 > Some others I think we might consider moving:
>
> onlinehelp
> rdb
> schemagen (is this even still used?)

Yup

> security? (not sure but it seems policyish)

I don't think so. Parts of it maybe.

> services (not the whole thing, but this seems like a big grab-bag)

Yes, for some of them.

> Another partially related thought:
> 
> Why don't the __init__.py files have a (terse) docstring that explains
> the purpose of the package? Some of their names are so general, that
> their purpose is not readily apparent. Even something like """The splat
> package facilitates the canonical splat protocol from rfc1234""" would
> be very helpful.

Agreed, except that I prefer to use README.txt files.  They are easier
to see and easier to edit and aren't mixed up with code.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Wed Feb  4 21:40:50 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Feb  4 21:42:56 2004
Subject: [Zope3-dev] Moving more stuff to zope.products
In-Reply-To: <20040205014900.D4FA425B4BA@bonanza.off.ekorp.com>
References: <20040205014900.D4FA425B4BA@bonanza.off.ekorp.com>
Message-ID: <4021AD32.3080505@zope.com>

Anthony Baxter wrote:
> My theory on this was that anything that's needed for Z3 to actually
> boot up shouldn't be in zope.products. I'd like to see that anything
> in zope.products _could_ be dropped without ill-effect. Philipp 
> pointed out that under this scheme, zope.products.securitypolicy
> should be in zope.app. 

Just because something is in zope.products doesn't mean it's
not going to be in distributions and available for booting.

We need *some* security policy to boot up, but not necessarily
the current one.

Zope will need certain facilities, but these will often be pluggable.

I think that Casey put this very well in his note.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From philipp at weitershausen.de  Thu Feb  5 05:43:27 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Thu Feb  5 06:01:34 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <4021AA47.1000804@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org> <4021AA47.1000804@zope.com>
Message-ID: <40221E4F.4060906@weitershausen.de>

>> From a philosophical point of view, content objects are custom to any 
>> application. I have application where I never need Folder, File or 
>> weird (forbidden?) stuff like Templated Page. Thus, one could argue 
>> that all optional stuff belongs in zope.products, not in the core.
> 
> It's a bit hard to imagine a Zope without folder.

It's hard to imagine Zope without a *container*... :) But ok, I can see 
why folders should maybe remaing a part of zope.app. The other stuff 
should move to zope.products, though.

Btw, I also feel kind of strongly about making Templated Page and Python 
Page (and possibly Catalog!) separate from the other 'sane' content 
objects, such as File, Image, etc. *and* disable them by default. If 
people do not want to disable them by default, it should at least be a 
matter of one line in products.zcml to disable them.

We could make two packages in zope.products:

- zope.products.basiccontent or defaultcontent
- zope.products.codecontent

or

- zope.products.content
- zope.products.content.code

I prefer the first one, mainly because of the hierarchy depth and the 
hierarchy straight-forwardness (interfaces, browser, etc.)

Philipp


From casey at zope.com  Thu Feb  5 09:45:45 2004
From: casey at zope.com (Casey Duncan)
Date: Thu Feb  5 09:48:28 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <40221E4F.4060906@weitershausen.de>
References: <bvr8od$o8u$1@sea.gmane.org> <4021AA47.1000804@zope.com>
	<40221E4F.4060906@weitershausen.de>
Message-ID: <20040205094545.34bd742b.casey@zope.com>

On Thu, 05 Feb 2004 11:43:27 +0100
Philipp von Weitershausen <philipp@weitershausen.de> wrote:

> >> From a philosophical point of view, content objects are custom to
> >any > application. I have application where I never need Folder, File
> >or > weird (forbidden?) stuff like Templated Page. Thus, one could
> >argue > that all optional stuff belongs in zope.products, not in the
> >core.
> > 
> > It's a bit hard to imagine a Zope without folder.
> 
> It's hard to imagine Zope without a *container*... :) But ok, I can
> see why folders should maybe remaing a part of zope.app. The other
> stuff should move to zope.products, though.

I disagree. My notion of a folder may not be yours. zope.app should IMO
define a base container (probably not even suitable for use by itself).
A default folder for content space derived from it can be defined in a
product that is enabled by default.

I'm not just speaking hypothetically here. The fact the OFS.Folder is
part of the Zope2 core bothers the heck out of me. Granted the contract
of ObjectManager does too. Anyhow, I feel relatively assured we won't
wind up with that sort of thing in Zope3 since they are a direct result
of the mixin class model and lack in separation of concerns that pervade
Zope2.

> Btw, I also feel kind of strongly about making Templated Page and
> Python Page (and possibly Catalog!) separate from the other 'sane'
> content objects, such as File, Image, etc. *and* disable them by
> default. If people do not want to disable them by default, it should
> at least be a matter of one line in products.zcml to disable them.

I don't really see why any specific content objects need to come with
the core. 

It seems a bit silly to ship products with Zope3 that are disabled by
default. Things that are disabled probably should be separate from the
main distro.
 
> We could make two packages in zope.products:
> 
> - zope.products.basiccontent or defaultcontent
> - zope.products.codecontent

Maybe, but I don't feel too strongly about it.  I guess it will make the
products.zcml easier to manage since you can just nuke one line to
disable codecontent for example.
 
> or
> 
> - zope.products.content
> - zope.products.content.code
> 
> I prefer the first one, mainly because of the hierarchy depth and the 
> hierarchy straight-forwardness (interfaces, browser, etc.)

The nesting seems unecessary since they would be in different modules
anyway (I hope ;^). Making them different top level products seems
reasonable (and more discoverable too).

-Casey

P.S. I'm really pleased this effort is happening. This is the kind of
vigilance that is necessary to keep the codebase clean and concerns
separated. It will only be possible to keep it that way if it starts out
that way.

From jim at zope.com  Thu Feb  5 13:52:07 2004
From: jim at zope.com (Jim Fulton)
Date: Thu Feb  5 18:52:56 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <40221E4F.4060906@weitershausen.de>
References: <bvr8od$o8u$1@sea.gmane.org> <4021AA47.1000804@zope.com>
	<40221E4F.4060906@weitershausen.de>
Message-ID: <402290D7.4030800@zope.com>

Philipp von Weitershausen wrote:
...

>> It's a bit hard to imagine a Zope without folder.
> 
> 
> It's hard to imagine Zope without a *container*... :) But ok, I can see 
> why folders should maybe remaing a part of zope.app. The other stuff 
> should move to zope.products, though.
> 
> Btw, I also feel kind of strongly about making Templated Page and Python 
> Page (and possibly Catalog!) separate from the other 'sane' content 
> objects, such as File, Image, etc. *and* disable them by default. If 
> people do not want to disable them by default, it should at least be a 
> matter of one line in products.zcml to disable them.

You are taking the position of the developer.  An important customer of Zope
if the "scripter". I want to pay *more* attention to them in the default
configuration, not less.

While there might be fewer content types enabled by default than there
are now, I would absolutely include templated page.

> We could make two packages in zope.products:
> 
> - zope.products.basiccontent or defaultcontent
> - zope.products.codecontent
> 
> or
> 
> - zope.products.content
> - zope.products.content.code

No, that's too complicated.  It makes the hierartchy even deeper.
I'm happy that we've separated demos.  We don't need more organization.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Thu Feb  5 14:00:14 2004
From: jim at zope.com (Jim Fulton)
Date: Thu Feb  5 19:00:41 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <20040205094545.34bd742b.casey@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org>
	<4021AA47.1000804@zope.com>	<40221E4F.4060906@weitershausen.de>
	<20040205094545.34bd742b.casey@zope.com>
Message-ID: <402292BE.8060801@zope.com>

Casey Duncan wrote:
> On Thu, 05 Feb 2004 11:43:27 +0100
> Philipp von Weitershausen <philipp@weitershausen.de> wrote:
> 
> 
>>>>From a philosophical point of view, content objects are custom to
>>>
>>>any > application. I have application where I never need Folder, File
>>>or > weird (forbidden?) stuff like Templated Page. Thus, one could
>>>argue > that all optional stuff belongs in zope.products, not in the
>>>core.
>>>
>>>It's a bit hard to imagine a Zope without folder.
>>
>>It's hard to imagine Zope without a *container*... :) But ok, I can
>>see why folders should maybe remaing a part of zope.app. The other
>>stuff should move to zope.products, though.
> 
> 
> I disagree. My notion of a folder may not be yours. zope.app should IMO
> define a base container (probably not even suitable for use by itself).
> A default folder for content space derived from it can be defined in a
> product that is enabled by default.

Right, the default will be Folder. You will be able to override this
with something else.  90% of Zope users will not care to do so, however,
and certainly won't want to have to.

> I'm not just speaking hypothetically here. The fact the OFS.Folder is
> part of the Zope2 core bothers the heck out of me.

Sorry to hear that. :)

 > Granted the contract
> of ObjectManager does too. Anyhow, I feel relatively assured we won't
> wind up with that sort of thing in Zope3 since they are a direct result
> of the mixin class model and lack in separation of concerns that pervade
> Zope2.

I don't understand what that has to do with it.  Most people aren't
going to totally refedine Zope at every level. They will want some standard
batteries to be included.

> 
>>Btw, I also feel kind of strongly about making Templated Page and
>>Python Page (and possibly Catalog!) separate from the other 'sane'
>>content objects, such as File, Image, etc. *and* disable them by
>>default. If people do not want to disable them by default, it should
>>at least be a matter of one line in products.zcml to disable them.
> 
> 
> I don't really see why any specific content objects need to come with
> the core. 

To make it usable.

> It seems a bit silly to ship products with Zope3 that are disabled by
> default. Things that are disabled probably should be separate from the
> main distro.

What ships with Zope 3 is an open issue that we aren't really thinking
about yet.  Some of the things in zope.products will be shipped in
common distributions, and some won't be.

> 
>>We could make two packages in zope.products:
>>
>>- zope.products.basiccontent or defaultcontent
>>- zope.products.codecontent
> 
> 
> Maybe, but I don't feel too strongly about it.  I guess it will make the
> products.zcml easier to manage since you can just nuke one line to
> disable codecontent for example.

yagni :)

> 
>>or
>>
>>- zope.products.content
>>- zope.products.content.code
>>
>>I prefer the first one, mainly because of the hierarchy depth and the 
>>hierarchy straight-forwardness (interfaces, browser, etc.)
> 
> 
> The nesting seems unecessary since they would be in different modules
> anyway (I hope ;^). Making them different top level products seems
> reasonable (and more discoverable too).

Yup

> -Casey
> 
> P.S. I'm really pleased this effort is happening. This is the kind of
> vigilance that is necessary to keep the codebase clean and concerns
> separated. It will only be possible to keep it that way if it starts out
> that way.

Yes

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Thu Feb  5 22:12:06 2004
From: jim at zope.com (Jim Fulton)
Date: Thu Feb  5 22:12:52 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
Message-ID: <40230606.4090805@zope.com>


I just updated:

   doc/ROADMAP.txt
   http://cvs.zope.org/Zope3/doc/ROADMAP.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup

If I've forgotten anything, please let me know, or update the file.

If I should exclude something, please let me know, but please don't remove
it from the file. Instead, add it to one of the "later" sections.

These notes are pretty rough.  Let me know if you want clarification
on something. Asking for clarification suggest that you might be willing
to work on something.

My goals in this plan are:

- Provide a solid foundation for moving forward.
   Most of the tasks are foundational tasks.  This is to
   reflect architectural changes we want to make beased on
   experience build Zope 3 applications, including Zope 3
   itself.

- Get to Zope X3 1.0 as soon as possible. I expect that there
   will be additional Zope X3 releases before Zope 3.0.

One area that I'd especially like to get input on is
support for scriptors. http://dev.zope.org/Zope3/SiteScripter.

Do we need to do more for scripters in release 1.0? If so,
is anyone willing to provide some leadership?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From dpharris76 at msn.com  Fri Feb  6 00:36:32 2004
From: dpharris76 at msn.com (David Harris)
Date: Fri Feb  6 00:49:50 2004
Subject: [Zope3-dev] WindowsXP Test Results - Zope 3/Python2.3.3
Message-ID: <BAY3-DAV29X5V3GykBb000feedd@hotmail.com>

I checked out the latest Zope3 source at 21:30 CST and ran the unit tests. I'm tracking down the failures, but here are the results if anyone is interested:

======================================================================
FAIL: test_commandline_overrides (zodb.zeo.tests.test_options.TestZEOOptions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\sf\Zope3\src\zodb\zeo\tests\test_options.py", line 90, in test_commandline_overrides
    self.assertEqual(options.address, ("", 6666))
  File "C:\PYTHON23\Lib\unittest.py", line 302, in failUnlessEqual
    raise self.failureException, \
AssertionError: ('localhost', 6666) != ('', 6666)

======================================================================
FAIL: test_defaults_with_schema (zodb.zeo.tests.test_options.TestZEOOptions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\sf\Zope3\src\zodb\zeo\tests\test_options.py", line 64, in test_defaults_with_schema
    self.assertEqual(options.address, ("", 5555))
  File "C:\PYTHON23\Lib\unittest.py", line 302, in failUnlessEqual
    raise self.failureException, \
AssertionError: ('localhost', 5555) != ('', 5555)

======================================================================
FAIL: test_defaults_without_schema (zodb.zeo.tests.test_options.TestZEOOptions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\sf\Zope3\src\zodb\zeo\tests\test_options.py", line 76, in test_defaults_without_schema
    self.assertEqual(options.address, ("", 5555))
  File "C:\PYTHON23\Lib\unittest.py", line 302, in failUnlessEqual
    raise self.failureException, \
AssertionError: ('localhost', 5555) != ('', 5555)

======================================================================
FAIL: Doctest: zope.products.pythonpage.PythonPage
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\sf\Zope3\src\zope\testing\doctestunit.py", line 67, in runTest
    raise self.failureException(
AssertionError: Failed doctest test for zope.products.pythonpage.PythonPage
  File "D:\sf\Zope3\src\zope\products\pythonpage\__init__.py", line 107 (or above), in PythonPage

*****************************************************************
Failure in example:
try:
    pp.setSource(u"prin 'hello'")
except SyntaxError, err:
    print err
from line #38 of zope.products.pythonpage.PythonPage
Expected: invalid syntax (pp, line 1)
Got: invalid syntax (/pp, line 1)


----------------------------------------------------------------------
Ran 5211 tests in 3799.353s

FAILED (failures=4)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/zope3-dev/attachments/20040205/a4806f3d/attachment.html
From philipp at weitershausen.de  Fri Feb  6 03:10:09 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Fri Feb  6 03:03:25 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <402290D7.4030800@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org> <4021AA47.1000804@zope.com>
	<40221E4F.4060906@weitershausen.de> <402290D7.4030800@zope.com>
Message-ID: <40234BE1.4040000@weitershausen.de>

Jim Fulton wrote:
>> It's hard to imagine Zope without a *container*... :) But ok, I can 
>> see why folders should maybe remaing a part of zope.app. The other 
>> stuff should move to zope.products, though.
>>
>> Btw, I also feel kind of strongly about making Templated Page and 
>> Python Page (and possibly Catalog!) separate from the other 'sane' 
>> content objects, such as File, Image, etc. *and* disable them by 
>> default. If people do not want to disable them by default, it should 
>> at least be a matter of one line in products.zcml to disable them.
> 
> You are taking the position of the developer.  An important customer
> of Zope if the "scripter". I want to pay *more* attention to them in
> the default configuration, not less.

Does the scripter care *where* the content type 'Folder' is defined? I'm 
not talking about shipping a crippled Zope3 that a scripter won't be 
able to work with. But I do share Casey's doubts about OFS.Folder's 
central role in Zope2 and his wish not to fall back to this behaviour again.

> While there might be fewer content types enabled by default than there
> are now, I would absolutely include templated page.

We agree to disagree then ;).

Philipp


From philipp at weitershausen.de  Fri Feb  6 03:20:32 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Fri Feb  6 03:14:03 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <402292BE.8060801@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org>
	<4021AA47.1000804@zope.com>	<40221E4F.4060906@weitershausen.de>
	<20040205094545.34bd742b.casey@zope.com>
	<402292BE.8060801@zope.com>
Message-ID: <40234E50.7000901@weitershausen.de>

Jim Fulton wrote:
>> Granted the contract
>> of ObjectManager does too. Anyhow, I feel relatively assured we won't
>> wind up with that sort of thing in Zope3 since they are a direct result
>> of the mixin class model and lack in separation of concerns that pervade
>> Zope2.
> 
> 
> I don't understand what that has to do with it.  Most people aren't
> going to totally refedine Zope at every level. They will want some standard
> batteries to be included.

I don't think we're talking about redefining Zope at every level. 
Content objects are just the most common 'redefinition', meaning 
customization that people will make. Therefore I think it is justified 
to ban example implementation out of the core. IIRC, the CMF has CMFCore 
and CMFDefault, too ;).
I think Casey was referring to SimpleItem, ObjectManager, 
PropertyManager and all those other mixins.

>>> Btw, I also feel kind of strongly about making Templated Page and
>>> Python Page (and possibly Catalog!) separate from the other 'sane'
>>> content objects, such as File, Image, etc. *and* disable them by
>>> default. If people do not want to disable them by default, it should
>>> at least be a matter of one line in products.zcml to disable them.
>>
>>
>> I don't really see why any specific content objects need to come with
>> the core. 
> 
> To make it usable.

I respectfully disagree. Stuff needn't be in the core to make Zope3 
usable. It just needs to be in products.zcml.in.

Philipp


From faassen at infrae.com  Fri Feb  6 05:25:09 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Fri Feb  6 05:26:41 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <20040205094545.34bd742b.casey@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org> <4021AA47.1000804@zope.com>
	<40221E4F.4060906@weitershausen.de>
	<20040205094545.34bd742b.casey@zope.com>
Message-ID: <20040206102509.GA8234@vet.uu.nl>

Casey Duncan wrote:
> It seems a bit silly to ship products with Zope3 that are disabled by
> default. Things that are disabled probably should be separate from the
> main distro.

Agreed! This sounds like a good guideline for zope.products.

This reminds me we should make at least some progress towards a repository
for all those components that shouldn't be part of the core.

Regards,

Martijn


From faassen at infrae.com  Fri Feb  6 05:36:38 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Fri Feb  6 05:38:10 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <402292BE.8060801@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org> <4021AA47.1000804@zope.com>
	<40221E4F.4060906@weitershausen.de>
	<20040205094545.34bd742b.casey@zope.com>
	<402292BE.8060801@zope.com>
Message-ID: <20040206103638.GB8234@vet.uu.nl>

Jim Fulton wrote:
> >It seems a bit silly to ship products with Zope3 that are disabled by
> >default. Things that are disabled probably should be separate from the
> >main distro.
> 
> What ships with Zope 3 is an open issue that we aren't really thinking
> about yet.  Some of the things in zope.products will be shipped in
> common distributions, and some won't be.

Um, in practice you realize that 'common distributions' *will* be shipping
zope.products, *unless we do something about it*, right? It's not like I or
anyone else is going to sit there, take Zope.org's distribution of Zope 3
and redistribute it without some products to the rest of the world. This is
because zope.org's distribution will be the most common distribution by
far.

Even when I distribute to my own clients I'd prefer to point them to the
standard zope.org distribution. 

I'd rather have zope.products contain stuff that's enabled by default, except
when the following occurs:

There are two or more different packages that fulfill the same task, and 
they're both useful and maintained. I could imagine two security policies,
for instance.

zope.examples can contain code that isn't enabled by default as it's obviously
example code. 

Anything else doesn't belong in the zope core distribution at all and should go
live in some extension.

It should of course be possible to disable products and either replace them
with something that fullfills the same task or just leave them out altogether.
Though I wouldn't be surprised to see a lot of Zope 3 extension code that
depends on things in zope.products. This is not a bad thing; it shows that
the zope.products code is actually useful.
 
In my mind, "zope.products", part of the Zope 3 CVS repository, which you'll
get when you do a checkout, certainly affects the most common distribution of
Zope 3 that we'll see, i.e. zope.org's one. In fact this is now the *only*
distribution of Zope 3 in existence.. :) 

Regards,

Martijn


From faassen at infrae.com  Fri Feb  6 05:40:12 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Fri Feb  6 05:41:43 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <40230606.4090805@zope.com>
References: <40230606.4090805@zope.com>
Message-ID: <20040206104012.GC8234@vet.uu.nl>

Jim Fulton wrote:
> One area that I'd especially like to get input on is
> support for scriptors. http://dev.zope.org/Zope3/SiteScripter.
> 
> Do we need to do more for scripters in release 1.0? If so,
> is anyone willing to provide some leadership?

To support scripters better a lot more thinking would need to happen,
and a lot more design. A leader will have to step up in order for this
to happen.

Even if a leader stood up yesterday though it's not realistic for the
consequences of all this design and implementation work to be part of
Zope X3, without delaying the release of Zope X3. I would therefore suggest
we don't worry about scripters too much in release 1.0, and simply put up
a a notice that Zope X3 is oriented towards Python developers and that
a later release will add more functionality for scripters.

Regards,

Martijn


From casey at zope.com  Fri Feb  6 09:33:09 2004
From: casey at zope.com (Casey Duncan)
Date: Fri Feb  6 09:35:53 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <402292BE.8060801@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org> <4021AA47.1000804@zope.com>
	<40221E4F.4060906@weitershausen.de>
	<20040205094545.34bd742b.casey@zope.com>
	<402292BE.8060801@zope.com>
Message-ID: <20040206093309.63b2227e.casey@zope.com>

On Thu, 05 Feb 2004 14:00:14 -0500
Jim Fulton <jim@zope.com> wrote:

> Casey Duncan wrote:
> > On Thu, 05 Feb 2004 11:43:27 +0100
> > Philipp von Weitershausen <philipp@weitershausen.de> wrote:
[..]
> 
> Right, the default will be Folder. You will be able to override this
> with something else.  90% of Zope users will not care to do so,
> however, and certainly won't want to have to.

Yes, count me into the 10% ;^)
 
> > I'm not just speaking hypothetically here. The fact the OFS.Folder
> > is part of the Zope2 core bothers the heck out of me.
> 
> Sorry to hear that. :)
> 
>  > Granted the contract
> > of ObjectManager does too. Anyhow, I feel relatively assured we
> > won't wind up with that sort of thing in Zope3 since they are a
> > direct result of the mixin class model and lack in separation of
> > concerns that pervade Zope2.
> 
> I don't understand what that has to do with it.  Most people aren't
> going to totally refedine Zope at every level. They will want some
> standard batteries to be included.

Absolutely, I'm not arguing whether it should include a folder,
template, document, etc. It absolutely should. I just think these
"content type" definitions should be in a product rather than in the
core.

In my mind content types, no matter how generic, inevitably define
policy. Their presence or absence alone is policy. Of course a default
policy is crucial to the system taking hold especially with "scripters",
I'd just like to see it close to the surface so that I can skim it off
if I want ;^)

> >>Btw, I also feel kind of strongly about making Templated Page and
> >>Python Page (and possibly Catalog!) separate from the other 'sane'
> >>content objects, such as File, Image, etc. *and* disable them by
> >>default. If people do not want to disable them by default, it should
> >>at least be a matter of one line in products.zcml to disable them.
> > 
> > 
> > I don't really see why any specific content objects need to come
> > with the core. 
> 
> To make it usable.

I should have been more clear. They can come with the distro (as
products), just not in the core IMO.

> > It seems a bit silly to ship products with Zope3 that are disabled
> > by default. Things that are disabled probably should be separate
> > from the main distro.
> 
> What ships with Zope 3 is an open issue that we aren't really thinking
> about yet.  Some of the things in zope.products will be shipped in
> common distributions, and some won't be.

Yup. I think of the Zope3 core like a Linux kernel. Every Linux distro
has a shell, fs, utilites, etc., but they aren't part of the kernel.
Every Zope3 distro will have some views and content types and utilities,
but they aren't necessarily part of the core.

If this turns out to be the case, it will be interesting to see how many
distros of Zope3 take form.
 
-Casey

From fred at zope.com  Fri Feb  6 09:40:41 2004
From: fred at zope.com (Fred Drake)
Date: Fri Feb  6 09:41:05 2004
Subject: [Zope3-dev] WindowsXP Test Results - Zope 3/Python2.3.3
In-Reply-To: <BAY3-DAV29X5V3GykBb000feedd@hotmail.com>
References: <BAY3-DAV29X5V3GykBb000feedd@hotmail.com>
Message-ID: <200402060940.41224.fred@zope.com>

On Friday 06 February 2004 12:36 am, David Harris wrote:
> ======================================================================
> FAIL: test_commandline_overrides 
(zodb.zeo.tests.test_options.TestZEOOptions)
...
> FAIL: test_defaults_with_schema 
(zodb.zeo.tests.test_options.TestZEOOptions)
...
> FAIL: test_defaults_without_schema 
(zodb.zeo.tests.test_options.TestZEOOptions)

These three will fail on all Windows flavors; I'll fix the tests in a few 
minutes.  The problem here is that until yesterday, ZConfig reported a poor 
default hostname on Windows when an address was specified with only a port 
number; these tests need to consult ZConfig for the "default" host reported 
when the host isn't specified.

Thanks for running the tests on XP!


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation


From tseaver at zope.com  Fri Feb  6 10:00:53 2004
From: tseaver at zope.com (Tres Seaver)
Date: Fri Feb  6 10:01:00 2004
Subject: [Zope3-dev] Re: Need help planning Zope X3 1.0
In-Reply-To: <20040206104012.GC8234@vet.uu.nl>
References: <40230606.4090805@zope.com> <20040206104012.GC8234@vet.uu.nl>
Message-ID: <c00a77$u49$1@sea.gmane.org>

Martijn Faassen wrote:
> Jim Fulton wrote:
> 
>>One area that I'd especially like to get input on is
>>support for scriptors. http://dev.zope.org/Zope3/SiteScripter.
>>
>>Do we need to do more for scripters in release 1.0? If so,
>>is anyone willing to provide some leadership?
> 
> 
> To support scripters better a lot more thinking would need to happen,
> and a lot more design. A leader will have to step up in order for this
> to happen.
> 
> Even if a leader stood up yesterday though it's not realistic for the
> consequences of all this design and implementation work to be part of
> Zope X3, without delaying the release of Zope X3. I would therefore suggest
> we don't worry about scripters too much in release 1.0, and simply put up
> a a notice that Zope X3 is oriented towards Python developers and that
> a later release will add more functionality for scripters.

+1.  I don't think users who don't need not-yet-ready-for-prime-time 
features (e.g., TTW scripting) should necessarily pay the costs 
(complexity, delayed releases) associated with them.

Actually, I would prefer to offer a "stripped-down" version of X3, which 
contained the minimum set of products required to bootstrap a site at 
all, and then focus on easing the construction of configurations which 
include one or more optional products.

For instance, suppose that we offered a web-form with a list of the 
available "zope.products" offerings, and then synthesized a package 
(perhaps a Windows installer, or a tarball).  We could make several 
"presets" available.  For instance:

   - "Barebones"

   - "CMF 2.0" would have versions of the "stock" CMFDefault content
     types, perhaps with some tools to ease migration of Plone / CMF
     sites.

   - "Wiki site"

   - "TTW Development"

I have spent a *lot* of time recently on packaging Zope2-based systems; 
  making 3X's product set more modular would go a *long* way toward 
easing the same task for Zope3.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com


From jim at zope.com  Fri Feb  6 15:19:54 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb  6 15:20:42 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <20040206093309.63b2227e.casey@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org>	<4021AA47.1000804@zope.com>	<40221E4F.4060906@weitershausen.de>	<20040205094545.34bd742b.casey@zope.com>	<402292BE.8060801@zope.com>
	<20040206093309.63b2227e.casey@zope.com>
Message-ID: <4023F6EA.3080605@zope.com>

Casey Duncan wrote:
> On Thu, 05 Feb 2004 14:00:14 -0500
> Jim Fulton <jim@zope.com> wrote:
> 
> 
>>Casey Duncan wrote:
>>
>>>On Thu, 05 Feb 2004 11:43:27 +0100
>>>Philipp von Weitershausen <philipp@weitershausen.de> wrote:
> 
> [..]
> 
>>Right, the default will be Folder. You will be able to override this
>>with something else.  90% of Zope users will not care to do so,
>>however, and certainly won't want to have to.
> 
> 
> Yes, count me into the 10% ;^)

Of course. :)

> 
>>>I'm not just speaking hypothetically here. The fact the OFS.Folder
>>>is part of the Zope2 core bothers the heck out of me.
>>
>>Sorry to hear that. :)
>>
>> > Granted the contract
>>
>>>of ObjectManager does too. Anyhow, I feel relatively assured we
>>>won't wind up with that sort of thing in Zope3 since they are a
>>>direct result of the mixin class model and lack in separation of
>>>concerns that pervade Zope2.
>>
>>I don't understand what that has to do with it.  Most people aren't
>>going to totally refedine Zope at every level. They will want some
>>standard batteries to be included.
> 
> 
> Absolutely, I'm not arguing whether it should include a folder,
> template, document, etc. It absolutely should. I just think these
> "content type" definitions should be in a product rather than in the
> core.

OK.

...

> I should have been more clear. They can come with the distro (as
> products), just not in the core IMO.

Cool


>>What ships with Zope 3 is an open issue that we aren't really thinking
>>about yet.  Some of the things in zope.products will be shipped in
>>common distributions, and some won't be.
> 
> 
> Yup. I think of the Zope3 core like a Linux kernel. Every Linux distro
> has a shell, fs, utilites, etc., but they aren't part of the kernel.
> Every Zope3 distro will have some views and content types and utilities,
> but they aren't necessarily part of the core.

We agree.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From dev at projekt01.ch  Fri Feb  6 17:06:55 2004
From: dev at projekt01.ch (Roger ineichen)
Date: Fri Feb  6 17:08:05 2004
Subject: AW: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <20040206093309.63b2227e.casey@zope.com>
Message-ID: <001c01c3ecfd$896c6810$1e63a8c0@projekt01.local>

We deveolpe a framework based on zope3

> > Right, the default will be Folder. You will be able to 
> override this 
> > with something else.  90% of Zope users will not care to do so, 
> > however, and certainly won't want to have to.
> 
> Yes, count me into the 10% ;^)

Count us also to the 10%

We are happy if there is a way to override all the basic content 
configuration and load a own configuration with own types.

I think it whould be nice to exclude a single line in a 
configure.zcml to disable a base distribution.

Regards 
Roger Ineichen





From gary at modernsongs.com  Fri Feb  6 22:21:00 2004
From: gary at modernsongs.com (Gary Poster)
Date: Fri Feb  6 22:21:35 2004
Subject: [Zope3-dev] little-picture thoughts on roadmap
Message-ID: <4024599C.3060100@modernsongs.com>

In terms of the big picture, the roadmap looks like the right direction 
to me.  I have a few small thoughts to add that sort of roam across the map.

- scripter support:

   * I think most of the absolutely necessary items are there.  Maybe 
just a "Zope X3 scripting for the Zope 2 user" tutorial, like what 
Philipp did for Jim's CA tutorial, describing a few typical skinning 
tasks in the CMF and how you would accomplish them in Zope 3.  The best 
CMF example I can think of would be to create a catalog search and 
result page from scratch: this should involve adding some images for the 
search results, adding some CSS, writing a couple of page templates, 
hopefully writing some helper Python somewhere, and hooking it all up. 
The "hooking it all up" part is where I'd fall over, working TTW, I 
think. :-)  I'm sure the information is available in Stephan's text, but 
  it didn't jump out at me.

   * As an aside, it seems to me that blocking off the CA model from the 
site scripter role (as described in 
http://dev.zope.org/Zope3/SiteScripter) is a bit extreme, and that basic 
adapters (for instance) are not too hard of a concept for scripters and 
would be a reasonable tool to put in their hands.

- Re local utilities and adapters, persistent modules, and file-system 
synchronization: in our work, we are going to come up sometime soonish 
against a desire to have zcml-like configuration for individual, local 
sites within a single Zope 3 instance.  That is, it's going to be 
important to be able to manage registrations for local adapters and 
skins and utilities via a cvs-friendly, human-readable 
mechanism--something that can configure a Zope 3 ZODB from scratch, 
something that TTW changes can modify again on the file-system, and 
something that can sanely slurp file-system changes back into the ZODB. 
  Sounds like file-system synchronization, but I don't think that it's 
been conceived of for registration as yet...am I wrong?

- http://dev.zope.org/Zope3/LocationRelatedEvents is hard.  I agree that 
this should be a requirement for X3 1.0, but it is the only thing that 
looked noticably uncooked in the roadmap, so it made me a bit 
worried...both for the feature and for the X3 release.  It seems 
essential to invite people to write new catalog, index, and relationship 
components, though...

- You said you needed to warn me about vocab changes--I assume that this 
  is just converting the service to a utility, which probably won't 
affect us too much.  So, cool.  Let us know when. ;-)

Gary

From anthony at interlink.com.au  Sat Feb  7 04:48:05 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Sat Feb  7 04:48:21 2004
Subject: [Zope3-dev] little-picture thoughts on roadmap 
In-Reply-To: <4024599C.3060100@modernsongs.com> 
Message-ID: <20040207094805.1611F25ADA0@bonanza.off.ekorp.com>


>>> Gary Poster wrote
> - Re local utilities and adapters, persistent modules, and file-system 
> synchronization: in our work, we are going to come up sometime soonish 
> against a desire to have zcml-like configuration for individual, local 
> sites within a single Zope 3 instance.  That is, it's going to be 
> important to be able to manage registrations for local adapters and 
> skins and utilities via a cvs-friendly, human-readable 
> mechanism--something that can configure a Zope 3 ZODB from scratch, 
> something that TTW changes can modify again on the file-system, and 
> something that can sanely slurp file-system changes back into the ZODB. 
>   Sounds like file-system synchronization, but I don't think that it's 
> been conceived of for registration as yet...am I wrong?

Hm. Interesting. A few of us are working in this area at this sprint,
trying to make the site mgmt UI a little easier and more obvious to
use. We might see what could be done in this area. I agree that it's
a useful thing to have - when someone wants to bundle up a product,
if they have to sit down and laboriously hand-craft python to do
all the necessary magic, it's going to cause them pain...


-- 
Anthony Baxter     <anthony@interlink.com.au>   
It's never too late to have a happy childhood.


From srichter at cosmos.phy.tufts.edu  Sat Feb  7 08:11:35 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Sat Feb  7 08:11:55 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <40230606.4090805@zope.com>
References: <40230606.4090805@zope.com>
Message-ID: <200402070811.35507.srichter@cosmos.phy.tufts.edu>

On Thursday 05 February 2004 22:12, Jim Fulton wrote:
> Do we need to do more for scripters in release 1.0? If so,
> is anyone willing to provide some leadership?

I think we are in pretty good shape concerning scripter support. We have 
pretty much all the technologies we need in place; they just need some 
polishing and fill-in.

But the point is that we do not want just plain scripter support and that's 
it. We need a migration path for them and I believe I worked on this as well.

Thanks to Alan and other people, I think I have a good idea of what is 
required for the scripter. Here are the levels as I see them and what we need 
to provide:

Level 1: The Scripter
---------------------

Here everything is quick and dirty. Usually people at this level use RDBs to 
store data and will not have the patience to learn the ZODB (or any OODB) way 
of doing things. Therefore it is important to provide them with tools to 
manipulate RDBs (by giving simple access to SQL statements) and to display 
the data nicely. I believe we have most of the required tools in place.

- The SQLExpr product provides the ease required for the scripter to deal with 
SQL, since it allows to embed it directly into templates. There is no need to 
educate the scripter about the software space and how to create connections. 
All that is required is the installation of a database adapter. Here is some 
example code:

<html tal:define="rdb string:PsycopgDA; dsn string:dbi://test">
  <body>
    <ul tal:define="table string:contact">
      <li tal:repeat="contact sql: SELECT * FROM ${table}">
        <b tal:content="contact/name" />
      </li>
    </ul>
  </body>
</html>

In this case we only have to tell the scripter about the various DA names and 
the meaning of DSNs, which is simple in my opinion.

- Inline Python support. As you probably know, we are already able to execute 
Python code from page templates, if a flag is activated. Then the following 
code is possible:

<html>
  <body>
    <script type="text/server-python">
           import time
           global t
           t = time.asctime()
    </script>
    <b tal:content="t" />
  </body>
</html>

Of course, for this example the following should also work (and it does; I 
just tried):

<html>
  <body>
    <b tal:content="modules/time/asctime" />
  </body>
</html>

Additionally to all this, I think Casey's sarcasm brought us another good tool 
for the scripter, namely the Python Page. Python Pages are almost like Python 
scripts, except that they do not take arguments or return something definite. 
They can only output text by printing it. However, you are not required to 
use print statements on triple quotes, so that the following is possible:

"""
<html>
  <body>
"""
import time
"""<b>%s</b>""" %time.asctime()
"""
  </body>
</html>
"""

This is pretty much everything the scripter needs. One other content type that 
would be nice is a "XML Content" object that is accessible via DOM. A lot of 
scripters are familiar with DOM from their browser experiences (i.e. 
JavaScript), so that it would be natural for them. Also, it would be really 
easy to use with TALES and Python code.


Level 2: The TTW Developer
--------------------------

This is the group that will be least addressed in the 1.0 release; however, we 
have some powerful tools pretty much ready to use for them. The most 
important one, in my opinion, is the ability to create TTW schemas and create 
a content type definition that can be used in content space. On top of this 
you can create views and, once the local adapter service lands, adapters. 
This in combination with the scripters tools and the other software space 
functionality provides a nice base for the TTW developer and offers a great 
migration path for the scripter. 

The scripter can start out learning only a few concepts at a time, like 
schemas, and be able to create custom content components. Later he can dive 
deeper into it and discover the concept of views, which are pretty much just 
Page Templates for content components. However, he can also discover views 
first, in the form of views on existing content components. The power of 
adapters s/he will probably discover last, since it depends on an 
understanding of views.


Level 3: Python Developer
-------------------------

We all know what's in the bag for this group. Most of our current 
documentation is aimed at them.


BTW, most of the above is documented in detail in my recipe on the Zope 3 GUI:
http://dev.zope.org/Zope3/DevelCookbook/Zope3GUI



Left To-Dos for 1.0:
--------------------

- TALES Namespaces: While TALES NS are done, there are almost no namespaces 
created. In fact, I think the only one available is the "zope" namespace, and 
even it is not complete. There should be additional namespaces:

+ locale: Here we should allow fast and simple formatting of dates/times and 
numbers. 

+ dc: Here all dublin core meta data should be made available.

+ adapt: I described how "adapt" should work in the referenced recipe.

+ string: This NS should provide simple string manipulation

As people start putting on the scripter hat for testing, I am sure we will 
come up with a whole lot more ideas. This is a part that needs serious work!

- datetime: Currently it is not possible to create new datetime object TTW, 
since we have no way to create security declarations on the method of a class 
(in contrast to instances). Jim knows about the issue and I hope it will be 
fixed in time.

- XML Content: I do not know how far Martijn is here, but it would surely be 
an item nice to have. Not a requirement though.

- Local Adapter Service: It is already part of the To-Do list.

- Schema-based Content Type: This used to work very well and reliably until 
the changes in the CA arrived. Jim, you punted on TTW content types, in your 
outline, but *please* let's not punt on the schema-based version. It is a 
very important part! Once you get the persistence issue fixed with TTW 
Schemas, I will make sure this works for the release.


Issues punted on for 1.0:
-------------------------

- Internationalization for TTW development in general is not an issue we have 
addressed yet at all. Besides that DTML needs a tag for internationalization, 
we also have to develop extraction tools for the local translation service. 
This task should not be too hard, but will require some time.

Okay, that's enough for now.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From jim at zope.com  Sat Feb  7 18:23:04 2004
From: jim at zope.com (Jim Fulton)
Date: Sat Feb  7 18:23:59 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <200402070811.35507.srichter@cosmos.phy.tufts.edu>
References: <40230606.4090805@zope.com>
	<200402070811.35507.srichter@cosmos.phy.tufts.edu>
Message-ID: <40257358.5040607@zope.com>

Stephan Richter wrote:
> On Thursday 05 February 2004 22:12, Jim Fulton wrote:
> 
>>Do we need to do more for scripters in release 1.0? If so,
>>is anyone willing to provide some leadership?
> 
> 
> I think we are in pretty good shape concerning scripter support. We have 
> pretty much all the technologies we need in place; they just need some 
> polishing and fill-in.

I don't agree.  I don't think this has been well thought out
and what has been done is controversial.

> But the point is that we do not want just plain scripter support and that's 
> it. We need a migration path for them and I believe I worked on this as well.

A migration path?  What sort of migration path? From Z2->Z3? From scripter to
developer? From other systems to this one?

> Thanks to Alan and other people, I think I have a good idea of what is 
> required for the scripter. Here are the levels as I see them and what we need 
> to provide:
> 
> Level 1: The Scripter
> ---------------------
> 
> Here everything is quick and dirty. Usually people at this level use RDBs to 
> store data and will not have the patience to learn the ZODB (or any OODB) way 
> of doing things.

I don't agree with this assessment, but that doesn't matter. I certainly agree
that what you want is worthwhile.

 > Therefore it is important to provide them with tools to
> manipulate RDBs (by giving simple access to SQL statements) and to display 
> the data nicely. I believe we have most of the required tools in place.
>
> - The SQLExpr product provides the ease required for the scripter to deal with 
> SQL, since it allows to embed it directly into templates. There is no need to 
> educate the scripter about the software space and how to create connections. 
> All that is required is the installation of a database adapter. Here is some 
> example code:
> 
> <html tal:define="rdb string:PsycopgDA; dsn string:dbi://test">
>   <body>
>     <ul tal:define="table string:contact">
>       <li tal:repeat="contact sql: SELECT * FROM ${table}">
>         <b tal:content="contact/name" />
>       </li>
>     </ul>
>   </body>
> </html>
> 
> In this case we only have to tell the scripter about the various DA names and 
> the meaning of DSNs, which is simple in my opinion.

This looks interesting. I don't understand how the adapter is connected to the sql.
You define an rdb variable, but don't use it. Is the rdb variable magically used
by the expr?

I'd rather focus on making it easier to define database adapters, including
a default one.

In any case, while this proposal is interesting, I think it needs more thought.

I also think that the separation of sal and template code has been very successful,
perhaps even for the scripter. We certainly still have sql scripts and I assume
that they work.

> - Inline Python support. As you probably know, we are already able to execute 
> Python code from page templates, if a flag is activated. Then the following 
> code is possible:
> 
> <html>
>   <body>
>     <script type="text/server-python">
>            import time
>            global t
>            t = time.asctime()
>     </script>
>     <b tal:content="t" />
>   </body>
> </html>

While I know this is controversial, I do still think that this is
worthwhile.

> Of course, for this example the following should also work (and it does; I 
> just tried):
> 
> <html>
>   <body>
>     <b tal:content="modules/time/asctime" />
>   </body>
> </html>

Of course, this is better for this example.

I also think we *need* PythonLibraries.

> Additionally to all this, I think Casey's sarcasm brought us another good tool 
> for the scripter, namely the Python Page. Python Pages are almost like Python 
> scripts, except that they do not take arguments or return something definite. 
> They can only output text by printing it. However, you are not required to 
> use print statements on triple quotes, so that the following is possible:
> 
> """
> <html>
>   <body>
> """
> import time
> """<b>%s</b>""" %time.asctime()
> """
>   </body>
> </html>
> """

No. Forget it. This will never be part of the core. :)

If we were going to do something like this, I'd much rather
pick something from another successful Python project. Perhaps
PTL.

> This is pretty much everything the scripter needs.

I don't agree. But I also don't know.

 > One other content type that
> would be nice is a "XML Content" object that is accessible via DOM. A lot of 
> scripters are familiar with DOM from their browser experiences (i.e. 
> JavaScript), so that it would be natural for them. Also, it would be really 
> easy to use with TALES and Python code.

Another good idea.

I'd like to put more thought into scripter support.  More thought
than we might want to take time for before 1.0.


> Level 2: The TTW Developer
> --------------------------
> 
> This is the group that will be least addressed in the 1.0 release; however, we 
> have some powerful tools pretty much ready to use for them. The most 
> important one, in my opinion, is the ability to create TTW schemas and create 
> a content type definition that can be used in content space.


Yeah, but I'm not sure that what we have now is solid enough yet.
I think it is at an experimental state.

 > On top of this
> you can create views and, once the local adapter service lands, adapters.

Yes, and persistent modules, which we should be able to make accessable
in content space.

> This in combination with the scripters tools and the other software space 
> functionality provides a nice base for the TTW developer and offers a great 
> migration path for the scripter. 
> 
> The scripter can start out learning only a few concepts at a time, like 
> schemas, and be able to create custom content components. Later he can dive 
> deeper into it and discover the concept of views, which are pretty much just 
> Page Templates for content components. However, he can also discover views 
> first, in the form of views on existing content components. The power of 
> adapters s/he will probably discover last, since it depends on an 
> understanding of views.

Yes. We'll want to flesh this out a bit.

I think we should scale back out expectations in this area.  Perhaps, for
1.0 we should label oll of the TTW development bits as experimental.

When we get closer to the release, we'll need to figure out what's in,
what's out, what's configured and what's not. It would be helpful to
be able to label features as experimental somehow.


> 
> Level 3: Python Developer
> -------------------------
> 
> We all know what's in the bag for this group. Most of our current 
> documentation is aimed at them.
> 
> 
> BTW, most of the above is documented in detail in my recipe on the Zope 3 GUI:
> http://dev.zope.org/Zope3/DevelCookbook/Zope3GUI

I'll look at that.

> 
> 
> Left To-Dos for 1.0:
> --------------------
> 
> - TALES Namespaces: While TALES NS are done, there are almost no namespaces 
> created. In fact, I think the only one available is the "zope" namespace, and 
> even it is not complete. There should be additional namespaces:
> 
> + locale: Here we should allow fast and simple formatting of dates/times and 
> numbers. 
> 
> + dc: Here all dublin core meta data should be made available.
> 
> + adapt: I described how "adapt" should work in the referenced recipe.
> 
> + string: This NS should provide simple string manipulation
> 
> As people start putting on the scripter hat for testing, I am sure we will 
> come up with a whole lot more ideas. This is a part that needs serious work!

What we *really* need is to get Evan Simpson's ZPT adapter work into
Z3 ZPT.


> - datetime: Currently it is not possible to create new datetime object TTW, 
> since we have no way to create security declarations on the method of a class 
> (in contrast to instances). Jim knows about the issue and I hope it will be 
> fixed in time.

Probably not, but the workaround is trivial.

> - XML Content: I do not know how far Martijn is here, but it would surely be 
> an item nice to have. Not a requirement though.

Not for 1.0.


> - Local Adapter Service: It is already part of the To-Do list.

Yeah, but maybe it shouldn't be.

> - Schema-based Content Type: This used to work very well and reliably until 
> the changes in the CA arrived. Jim, you punted on TTW content types, in your 
> outline, but *please* let's not punt on the schema-based version. It is a 
> very important part! Once you get the persistence issue fixed with TTW 
> Schemas, I will make sure this works for the release.

I will fix what broke it, but I'm still not comfortable with including it in
Z3.  Your idea of working well and mine are different.  I found it rather
rough.

> 
> Issues punted on for 1.0:
> -------------------------
> 
> - Internationalization for TTW development in general is not an issue we have 
> addressed yet at all. Besides that DTML needs a tag for internationalization, 
> we also have to develop extraction tools for the local translation service. 
> This task should not be too hard, but will require some time.

  - Testing for TTW

But there's much more we'll punt on.

I suspect we should largely punt on TTW development.

But, I'd love to get lots of input on this.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Sat Feb  7 18:24:58 2004
From: jim at zope.com (Jim Fulton)
Date: Sat Feb  7 18:25:51 2004
Subject: [Zope3-dev] One possibility for 1.0
Message-ID: <402573CA.9030409@zope.com>


One possibility is to say that 1.0 (perhaps a different designation
would be better) is really for those people who are already delivering
Zope 3 apps.  It emphasizes the things that work pretty well now,
meaning core services and file-system-based development.

<shrug>

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From srichter at cosmos.phy.tufts.edu  Sat Feb  7 18:37:43 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Sat Feb  7 18:38:01 2004
Subject: [Zope3-dev] One possibility for 1.0
In-Reply-To: <402573CA.9030409@zope.com>
References: <402573CA.9030409@zope.com>
Message-ID: <200402071837.44347.srichter@cosmos.phy.tufts.edu>

On Saturday 07 February 2004 18:24, Jim Fulton wrote:
> One possibility is to say that 1.0 (perhaps a different designation
> would be better) is really for those people who are already delivering
> Zope 3 apps. ?It emphasizes the things that work pretty well now,
> meaning core services and file-system-based developmen

Yes, I agree with that based on your previous message. I can always make a 
experimental TTW-enabled release, like "1.0+TTW" for people who want to try 
it and give feedback. Zope 3 1.0 will get a lot of attention, and I would 
love to use some of this momentum to get TTW development feedback. On the 
other hand I do not want to make the main release messy, late and unstable, 
so that people will look at it and say: What the hell is this?

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From pw_lists at slinkp.com  Sat Feb  7 18:48:24 2004
From: pw_lists at slinkp.com (Paul Winkler)
Date: Sat Feb  7 18:48:28 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <40257358.5040607@zope.com>
References: <40230606.4090805@zope.com>
	<200402070811.35507.srichter@cosmos.phy.tufts.edu>
	<40257358.5040607@zope.com>
Message-ID: <20040207234824.GA1987@slinkp.com>

On Sat, Feb 07, 2004 at 06:23:04PM -0500, Jim Fulton wrote:
> I also think we *need* PythonLibraries.

+1.

> >Additionally to all this, I think Casey's sarcasm brought us another good 
> >tool for the scripter, namely the Python Page. Python Pages are almost 
> >like Python scripts, except that they do not take arguments or return 
> >something definite. They can only output text by printing it. However, you 
> >are not required to use print statements on triple quotes, so that the 
> >following is possible:
> >
> >"""
> ><html>
> >  <body>
> >"""
> >import time
> >"""<b>%s</b>""" %time.asctime()
> >"""
> >  </body>
> ></html>
> >"""
> 
> No. Forget it. This will never be part of the core. :)

Whew.  :-)
Sorry Stefan, it smelled bad to me too.
 
-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's DOOPER COG ROBBER!
(random hero from isometric.spaceninja.com)

From srichter at cosmos.phy.tufts.edu  Sat Feb  7 19:04:39 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Sat Feb  7 19:04:57 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <20040207234824.GA1987@slinkp.com>
References: <40230606.4090805@zope.com> <40257358.5040607@zope.com>
	<20040207234824.GA1987@slinkp.com>
Message-ID: <200402071904.39578.srichter@cosmos.phy.tufts.edu>

On Saturday 07 February 2004 18:48, Paul Winkler wrote:
> Whew. ?:-)
> Sorry Stefan, it smelled bad to me too.

Traitor! 

Just kidding... ;-)

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From garrett at mojave-corp.com  Sat Feb  7 19:23:08 2004
From: garrett at mojave-corp.com (Garrett Smith)
Date: Sat Feb  7 19:19:23 2004
Subject: [Zope3-dev] widget question: propertyNames/getValue
Message-ID: <FB37E9B9E9354A4788F1B322E4AAD1D880A4@server1.mojave.local>

I'm trying to make sense of propertyNames in the widget facility. From
what I can see, propertyNames and getValue can be removed from IWidget
(plus appropriate refactoring of existing code) without loosing
functionality.

1 - Nothing in the core uses propertyNames outside the implementation of
getValue.

2 - getattr can be called on a widget directly if you need to get an
attribute by name.

3 - If propertyNames is used for documenting/listing fields supported by
a widget, there are better ways to do this.

 -- Garrett

From srichter at cosmos.phy.tufts.edu  Sat Feb  7 19:29:25 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Sat Feb  7 19:29:41 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <40257358.5040607@zope.com>
References: <40230606.4090805@zope.com>
	<200402070811.35507.srichter@cosmos.phy.tufts.edu>
	<40257358.5040607@zope.com>
Message-ID: <200402071929.25507.srichter@cosmos.phy.tufts.edu>

On Saturday 07 February 2004 18:23, Jim Fulton wrote:
> Stephan Richter wrote:

> I don't agree.  I don't think this has been well thought out
> and what has been done is controversial.

I think it has been controversial because everyone on the mailing list is not 
in the audience. Both, the SQLExpr and inline Python support came from 
feedback from people that deal with scripters all the time. For the purists 
any scripting support will look like a hack.

> > But the point is that we do not want just plain scripter support and
> > that's it. We need a migration path for them and I believe I worked on
> > this as well.
>
> A migration path?  What sort of migration path? From Z2->Z3? From scripter
> to developer? From other systems to this one?

Oh, I talk about the migration from the Scripter --> TTW developer --> Python 
product developer. I realize that not all people will make the second 
transition, which is fine. But I think that everyone should make the first 
transition at some point.

> > Here everything is quick and dirty. Usually people at this level use RDBs
> > to store data and will not have the patience to learn the ZODB (or any
> > OODB) way of doing things.

> I don't agree with this assessment, but that doesn't matter. I certainly
> agree that what you want is worthwhile.

I remember the difficulties I initially had with understanding OO programming 
and the jump from SQL to ZODB was also not that easy. It took me a couple of 
years to completely understand the latter one (otherwise I would have never 
developed SQLObjects).

> > In this case we only have to tell the scripter about the various DA names
> > and the meaning of DSNs, which is simple in my opinion.
>
> This looks interesting. I don't understand how the adapter is connected to
> the sql. You define an rdb variable, but don't use it. Is the rdb variable
> magically used by the expr?

Yes, it is magically used; something that really bugs me about this product. 
But I could just not think of something better. BTW, optionally you can also 
just specify a DA name, but the example was meant to work without any 
additional setup.

> I'd rather focus on making it easier to define database adapters, including
> a default one.

As Alan had put it: This is the second step. The scripter wants the fastest 
success possible.

> I also think that the separation of sal and template code has been very
> successful, perhaps even for the scripter. We certainly still have sql
> scripts and I assume that they work.

I totally agree, but it already requires the scripter to be accustomed with 
some of the framework.

> If we were going to do something like this, I'd much rather
> pick something from another successful Python project. Perhaps
> PTL.

Yes, I think that would be better. I do not know PTL, but I know something 
like Python Page is needed! I just looked quickly at PTL and it looks pretty 
interesting. In fact, it has the same ideas I had with Python Page but is 
much more developed.

> > This is pretty much everything the scripter needs.
>
> I don't agree. But I also don't know.

What else do you think is needed?

> > - Local Adapter Service: It is already part of the To-Do list.
>
> Yeah, but maybe it shouldn't be.

Based on your other comments, it should not.

> > - Schema-based Content Type: This used to work very well and reliably
> > until the changes in the CA arrived. Jim, you punted on TTW content
> > types, in your outline, but *please* let's not punt on the schema-based
> > version. It is a very important part! Once you get the persistence issue
> > fixed with TTW Schemas, I will make sure this works for the release.
>
> I will fix what broke it, but I'm still not comfortable with including it
> in Z3.  Your idea of working well and mine are different.  I found it
> rather rough.

The base code was actually not that rought at all. What was a bit rough was 
the integration into menus. I had not worked on this, since you said you 
would redo the local menu service. We have similar code that is used 
successfully in the workflow package as well.

> > Issues punted on for 1.0:
> > -------------------------
>   - Testing for TTW

Good point.

> But there's much more we'll punt on.

We should maybe start listing it at this point.

> I suspect we should largely punt on TTW development.

Yep, I get this feeling.

> But, I'd love to get lots of input on this.

Me too.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From jim at zope.com  Sat Feb  7 19:38:36 2004
From: jim at zope.com (Jim Fulton)
Date: Sat Feb  7 19:40:40 2004
Subject: [Zope3-dev] widget question: propertyNames/getValue
In-Reply-To: <FB37E9B9E9354A4788F1B322E4AAD1D880A4@server1.mojave.local>
References: <FB37E9B9E9354A4788F1B322E4AAD1D880A4@server1.mojave.local>
Message-ID: <4025850C.5030901@zope.com>

Garrett Smith wrote:
> I'm trying to make sense of propertyNames in the widget facility. From
> what I can see, propertyNames and getValue can be removed from IWidget
> (plus appropriate refactoring of existing code) without loosing
> functionality.
> 
> 1 - Nothing in the core uses propertyNames outside the implementation of
> getValue.
> 
> 2 - getattr can be called on a widget directly if you need to get an
> attribute by name.
> 
> 3 - If propertyNames is used for documenting/listing fields supported by
> a widget, there are better ways to do this.

My opinion is that widgets should implement schemas that describe their
configuration data, which are exposed via attributes.

Jim


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Sat Feb  7 19:46:04 2004
From: jim at zope.com (Jim Fulton)
Date: Sat Feb  7 19:48:11 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <200402071929.25507.srichter@cosmos.phy.tufts.edu>
References: <40230606.4090805@zope.com>	<200402070811.35507.srichter@cosmos.phy.tufts.edu>	<40257358.5040607@zope.com>
	<200402071929.25507.srichter@cosmos.phy.tufts.edu>
Message-ID: <402586CC.8040503@zope.com>

Stephan Richter wrote:
> On Saturday 07 February 2004 18:23, Jim Fulton wrote:
> 
>>Stephan Richter wrote:
> 
> 
>>I don't agree.  I don't think this has been well thought out
>>and what has been done is controversial.
> 
> 
> I think it has been controversial because everyone on the mailing list is not 
> in the audience. Both, the SQLExpr and inline Python support came from 
> feedback from people that deal with scripters all the time. For the purists 
> any scripting support will look like a hack.

Granted, but even so, I think that this is a big important thing that
I want to give more focus before we commit to how it's gonna be.

I think it's too important to rush at before the first release.

> 
>>>But the point is that we do not want just plain scripter support and
>>>that's it. We need a migration path for them and I believe I worked on
>>>this as well.
>>
>>A migration path?  What sort of migration path? From Z2->Z3? From scripter
>>to developer? From other systems to this one?
> 
> 
> Oh, I talk about the migration from the Scripter --> TTW developer --> Python 
> product developer. I realize that not all people will make the second 
> transition, which is fine. But I think that everyone should make the first 
> transition at some point.

ok

...

>>This looks interesting. I don't understand how the adapter is connected to
>>the sql. You define an rdb variable, but don't use it. Is the rdb variable
>>magically used by the expr?
> 
> 
> Yes, it is magically used; something that really bugs me about this product. 
> But I could just not think of something better. BTW, optionally you can also 
> just specify a DA name, but the example was meant to work without any 
> additional setup.

I'm sure we can figure this out, but we may not have bandwidth for it right now.


>>If we were going to do something like this, I'd much rather
>>pick something from another successful Python project. Perhaps
>>PTL.
> 
> 
> Yes, I think that would be better. I do not know PTL, but I know something 
> like Python Page is needed! I just looked quickly at PTL and it looks pretty 
> interesting. In fact, it has the same ideas I had with Python Page but is 
> much more developed.
> 
> 
>>>This is pretty much everything the scripter needs.
>>
>>I don't agree. But I also don't know.
> 
> 
> What else do you think is needed?

I dunno and I don't want to figure out right now. :)

OK, I can't resist.

I think that an important step would be to work out a training
course and use it to work out what makes sense to people.  That is,
work out some ideas and try them on people.

> 
>>>- Local Adapter Service: It is already part of the To-Do list.
>>
>>Yeah, but maybe it shouldn't be.
> 
> 
> Based on your other comments, it should not.
> 
> 
>>>- Schema-based Content Type: This used to work very well and reliably
>>>until the changes in the CA arrived. Jim, you punted on TTW content
>>>types, in your outline, but *please* let's not punt on the schema-based
>>>version. It is a very important part! Once you get the persistence issue
>>>fixed with TTW Schemas, I will make sure this works for the release.
>>
>>I will fix what broke it, but I'm still not comfortable with including it
>>in Z3.  Your idea of working well and mine are different.  I found it
>>rather rough.
> 
> 
> The base code was actually not that rought at all. What was a bit rough was 
> the integration into menus. I had not worked on this, since you said you 
> would redo the local menu service. We have similar code that is used 
> successfully in the workflow package as well.

When I say "rough" I was refering toi the few times I tried to use them,
not to the implementation, :)

> 
>>>Issues punted on for 1.0:
>>>-------------------------
>>
>>  - Testing for TTW
> 
> 
> Good point.
> 
> 
>>But there's much more we'll punt on.
> 
> 
> We should maybe start listing it at this point.

eh

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From gary at modernsongs.com  Sat Feb  7 20:17:07 2004
From: gary at modernsongs.com (Gary Poster)
Date: Sat Feb  7 20:17:47 2004
Subject: [Zope3-dev] widget question: propertyNames/getValue
In-Reply-To: <4025850C.5030901@zope.com>
References: <FB37E9B9E9354A4788F1B322E4AAD1D880A4@server1.mojave.local>
	<4025850C.5030901@zope.com>
Message-ID: <40258E13.6070108@modernsongs.com>



Jim Fulton wrote:
> Garrett Smith wrote:
> 
>> I'm trying to make sense of propertyNames in the widget facility. From
>> what I can see, propertyNames and getValue can be removed from IWidget
>> (plus appropriate refactoring of existing code) without loosing
>> functionality.
...
> My opinion is that widgets should implement schemas that describe their
> configuration data, which are exposed via attributes.

+1.  I was thinking of this too: this would also allow zcml 
customization of widgets (because then we would have the type casting 
for free) without having to do it with a mixin view class.  That was a 
goal of mine.

Gary

From michael at d2m.at  Sun Feb  8 04:28:30 2004
From: michael at d2m.at (Michael Haubenwallner)
Date: Sun Feb  8 04:40:33 2004
Subject: [Zope3-dev] Re: One possibility for 1.0
In-Reply-To: <200402071837.44347.srichter@cosmos.phy.tufts.edu>
References: <402573CA.9030409@zope.com>
	<200402071837.44347.srichter@cosmos.phy.tufts.edu>
Message-ID: <c04vkh$r5p$1@sea.gmane.org>

Stephan Richter wrote:
> On Saturday 07 February 2004 18:24, Jim Fulton wrote:
> 
>>One possibility is to say that 1.0 (perhaps a different designation
>>would be better) is really for those people who are already delivering
>>Zope 3 apps.  It emphasizes the things that work pretty well now,
>>meaning core services and file-system-based developmen
> 
> 
> Yes, I agree with that based on your previous message. I can always make a 
> experimental TTW-enabled release, like "1.0+TTW" for people who want to try 
> it and give feedback. Zope 3 1.0 will get a lot of attention, and I would 
> love to use some of this momentum to get TTW development feedback. On the 
> other hand I do not want to make the main release messy, late and unstable, 
> so that people will look at it and say: What the hell is this?
>

Would it make sense to remove the TTW-management-interface from the 
'core' and into a product ? Could this product be used as an example of 
how to write management products for zope3 ?

-- 
michael



From faassen at infrae.com  Sun Feb  8 08:13:09 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Sun Feb  8 08:14:46 2004
Subject: [Zope3-dev] Re: One possibility for 1.0
In-Reply-To: <c04vkh$r5p$1@sea.gmane.org>
References: <402573CA.9030409@zope.com>
	<200402071837.44347.srichter@cosmos.phy.tufts.edu>
	<c04vkh$r5p$1@sea.gmane.org>
Message-ID: <20040208131309.GA15752@vet.uu.nl>

Michael Haubenwallner wrote:
> Would it make sense to remove the TTW-management-interface from the 
> 'core' and into a product ? Could this product be used as an example of 
> how to write management products for zope3 ?

I think it makes sense to move it out of the core myself, at least initially
during development. It may need some hooks in the core, of course..

Regards,

Martijn


From philipp at weitershausen.de  Sun Feb  8 10:16:17 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Sun Feb  8 10:09:34 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <bvr8od$o8u$1@sea.gmane.org>
References: <bvr8od$o8u$1@sea.gmane.org>
Message-ID: <402652C1.9070200@weitershausen.de>

Philipp von Weitershausen wrote:
> Hi there,
> 
> in the currently ongoing process of reorganizing Zope3's package 
> structure and gutting out zope.app, I think the main packages that have 
> yet to be moved are:
> 
> - zope.app.workflow
> - zope.app.content

I have started moving zope.app.content to zope.products.content and 
zope.products.codecontent, respectively in a branch, 
'philikon-movecontent-branch'. Here's a small status report:

   - zope.app.content is a simple module now containg the ContentType
     machinery

   - Folder could not be moved out of zope.app, mainly because it is
     needed widely by the Zope core for its root folder functionality,
     e.g. in the bootstrap process. It it is now in zope.app.folder,
     since zope.app.content is a simple module now.

   - You currently have to toss your Data.fs, which is bad. I tried
     setting up a modulealias at least for folders (in
     zope.products.content/configure.zcml), but it doesn't seem to work.

   - Packages in zope.products have been fixed up. All unit tests pass.

   - 6 functional/integration tests still fail, mainly because they
     depended on either the File or the Templated Page content types.
     While the first is easy to fix, the latter is a bit more
     complicated.

Comments are appreciated, as well as help chasing down the last test 
failures and fixing the modulealias.

Philipp


From dpharris76 at msn.com  Sun Feb  8 14:57:15 2004
From: dpharris76 at msn.com (Dave Harris)
Date: Sun Feb  8 14:57:22 2004
Subject: [Zope3-dev] Q on conf error reporting
Message-ID: <BAY3-DAV63U393IhJrv00000eb0@hotmail.com>

I added an server entry to zope.conf using a silly type:

<server>
  type LEMMING
  address 8083
</server>

and received (deservedly) a program failure marking my misdeed:

Traceback (most recent call last):
  File "z3.py", line 65, in ?
    run()
  File "z3.py", line 61, in run
    main(argv[1:])
  File "C:\rascal\dev\Z3SB\src\zope\app\process\main.py", line 56, in main
    setup(args)
  File "C:\rascal\dev\Z3SB\src\zope\app\process\main.py", line 99, in setup
    server.create(task_dispatcher, db)
  File "C:\rascal\dev\Z3SB\src\zope\app\process\server.py", line 42, in 
create
    servertype.create(task_dispatcher, database,
AttributeError: 'NoneType' object has no attribute 'create'

This leads to a couple (or four) questions:

1) When getServerType() returns None, should create() still proceed with the 
servertype.create() call?

2) When a bad but well-formed configuration entry is processed, should Zope 
3 report the specifics (e.g. the config file line and the reason for 
failure)?

3) In general, should Zope 3 disguise the fact that Python is the 
implementation language - that is, not generate tracebacks?

4) Would a test for this situation be a unit test of 
zope.app.process.setup()? Or would it be considered a functional test?

Thanks,
Dave Harris 

From jim at zope.com  Sun Feb  8 15:29:30 2004
From: jim at zope.com (Jim Fulton)
Date: Sun Feb  8 15:30:16 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <402652C1.9070200@weitershausen.de>
References: <bvr8od$o8u$1@sea.gmane.org> <402652C1.9070200@weitershausen.de>
Message-ID: <40269C2A.9090306@zope.com>

Philipp von Weitershausen wrote:
> Philipp von Weitershausen wrote:
> 
>> Hi there,
>>
>> in the currently ongoing process of reorganizing Zope3's package 
>> structure and gutting out zope.app, I think the main packages that 
>> have yet to be moved are:
>>
>> - zope.app.workflow
>> - zope.app.content
> 
> 
> I have started moving zope.app.content to zope.products.content and 
> zope.products.codecontent, respectively in a branch, 
> 'philikon-movecontent-branch'. Here's a small status report:
> 
>   - zope.app.content is a simple module now containg the ContentType
>     machinery
> 
>   - Folder could not be moved out of zope.app, mainly because it is
>     needed widely by the Zope core for its root folder functionality,
>     e.g. in the bootstrap process. It it is now in zope.app.folder,
>     since zope.app.content is a simple module now.
> 
>   - You currently have to toss your Data.fs, which is bad. I tried
>     setting up a modulealias at least for folders (in
>     zope.products.content/configure.zcml), but it doesn't seem to work.

Yes, this is bad. We really should write a conversion script.
This might be very hard.

Perhaps we should combine this with the ZODB4->ZODB3 conversion script.

>   - Packages in zope.products have been fixed up. All unit tests pass.
> 
>   - 6 functional/integration tests still fail, mainly because they
>     depended on either the File or the Templated Page content types.
>     While the first is easy to fix, the latter is a bit more
>     complicated.
> 
> Comments are appreciated, as well as help chasing down the last test 
> failures and fixing the modulealias.

At a high level, this sounds good.  I'll try to find some time to
look at the branch.

In any case, we should not plan to merge this until I get back
to the States.

Thanks for the great work!

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From pw_lists at slinkp.com  Sun Feb  8 15:36:43 2004
From: pw_lists at slinkp.com (Paul Winkler)
Date: Sun Feb  8 15:36:46 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <402586CC.8040503@zope.com>
References: <40230606.4090805@zope.com>
	<200402070811.35507.srichter@cosmos.phy.tufts.edu>
	<40257358.5040607@zope.com>
	<200402071929.25507.srichter@cosmos.phy.tufts.edu>
	<402586CC.8040503@zope.com>
Message-ID: <20040208203643.GD1723@slinkp.com>

On Sat, Feb 07, 2004 at 07:46:04PM -0500, Jim Fulton wrote:
> Stephan Richter wrote:
> >>I don't agree.  I don't think this has been well thought out
> >>and what has been done is controversial.
> >
> >
> >I think it has been controversial because everyone on the mailing list is 
> >not in the audience. Both, the SQLExpr and inline Python support came from 
> >feedback from people that deal with scripters all the time. For the 
> >purists any scripting support will look like a hack.
> 
> Granted, but even so, I think that this is a big important thing that
> I want to give more focus before we commit to how it's gonna be.
> 
> I think it's too important to rush at before the first release.

I agree.
FWIW, I like the idea of SQL expressions very much, though I haven't
thought much about the details.

I think the controversy over embedding python in ZPT and
embedding HTML in python should not be taken lightly, and
if we are not ready to focus on it, we should stop arguing about
it for now. I have plenty to say on the subject but I think
this is not the time.

> I think that an important step would be to work out a training
> course and use it to work out what makes sense to people.  That is,
> work out some ideas and try them on people.

yes!

But, I think I see an emerging consensus that we are not
ready to fully tackle the scripting support and that it might
be OK to defer this until after Zope X3 1.0 or whatever the
heck it's called.

As someone who cares about scripter support - both because
I've done a fair bit of it in zope 2, and because I often
wear the "SiteDeveloper" hat and have to maintain and/or
rewrite other peoples' scripting efforts - 
I am perfectly happy with the prospect of having 
zope X3 really solid for filesystem developers first,
then TTW development second, then TTW scripters last of all.
Even if it means scripter support is not solid until 2005 or so.

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's SUPER MAFIOSO 8!
(random hero from isometric.spaceninja.com)

From jim at zope.com  Sun Feb  8 15:45:02 2004
From: jim at zope.com (Jim Fulton)
Date: Sun Feb  8 15:45:45 2004
Subject: [Zope3-dev] Re: One possibility for 1.0
In-Reply-To: <c04vkh$r5p$1@sea.gmane.org>
References: <402573CA.9030409@zope.com>	<200402071837.44347.srichter@cosmos.phy.tufts.edu>
	<c04vkh$r5p$1@sea.gmane.org>
Message-ID: <40269FCE.70203@zope.com>

Michael Haubenwallner wrote:
> Stephan Richter wrote:
> 
>> On Saturday 07 February 2004 18:24, Jim Fulton wrote:
>>
>>> One possibility is to say that 1.0 (perhaps a different designation
>>> would be better) is really for those people who are already delivering
>>> Zope 3 apps.  It emphasizes the things that work pretty well now,
>>> meaning core services and file-system-based developmen
>>
>>
>>
>> Yes, I agree with that based on your previous message. I can always 
>> make a experimental TTW-enabled release, like "1.0+TTW" for people who 
>> want to try it and give feedback. Zope 3 1.0 will get a lot of 
>> attention, and I would love to use some of this momentum to get TTW 
>> development feedback. On the other hand I do not want to make the main 
>> release messy, late and unstable, so that people will look at it and 
>> say: What the hell is this?
>>
> 
> Would it make sense to remove the TTW-management-interface from the 
> 'core' and into a product ? Could this product be used as an example of 
> how to write management products for zope3 ?

This thread was originally about the TTW development facilities, not
TTW management.  We will certainly include the TTW management facilities
in the first release.

At this point, I'm mainly concerned about which features should be
priorities for finishing for the first release.  I also want to
set expectations for the first release, in terms if who it's for and how
we expect people to use it.

A different question is how this is all going to be packaged.
I'm still thinking about that.

It will be possible to replace pretty much anything. It will certainly
be possible to replace the management UI. While I agree with the
benefit of organizing things to make this more obvious, I don't
think I particularly want to take the time to do this now.

Jim


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Sun Feb  8 17:39:29 2004
From: jim at zope.com (Jim Fulton)
Date: Sun Feb  8 17:39:50 2004
Subject: [Zope3-dev] Is anyone using persistent modules at the moment?
Message-ID: <4026BAA1.8080408@zope.com>


I'm thinking of breaking them for a while and not taking the time to fix them,
assuming that no one is actually using them.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Sun Feb  8 17:41:00 2004
From: jim at zope.com (Jim Fulton)
Date: Sun Feb  8 17:41:19 2004
Subject: [Zope3-dev] Re: One possibility for 1.0
In-Reply-To: <40269FCE.70203@zope.com>
References: <402573CA.9030409@zope.com>	<200402071837.44347.srichter@cosmos.phy.tufts.edu>	<c04vkh$r5p$1@sea.gmane.org>
	<40269FCE.70203@zope.com>
Message-ID: <4026BAFC.4090301@zope.com>

So, I'm guessing that no one is using through-the-web adapters or views.
Is that right?

Jim


Jim Fulton wrote:
> Michael Haubenwallner wrote:
> 
>> Stephan Richter wrote:
>>
>>> On Saturday 07 February 2004 18:24, Jim Fulton wrote:
>>>
>>>> One possibility is to say that 1.0 (perhaps a different designation
>>>> would be better) is really for those people who are already delivering
>>>> Zope 3 apps.  It emphasizes the things that work pretty well now,
>>>> meaning core services and file-system-based developmen
>>>
>>>
>>>
>>>
>>> Yes, I agree with that based on your previous message. I can always 
>>> make a experimental TTW-enabled release, like "1.0+TTW" for people 
>>> who want to try it and give feedback. Zope 3 1.0 will get a lot of 
>>> attention, and I would love to use some of this momentum to get TTW 
>>> development feedback. On the other hand I do not want to make the 
>>> main release messy, late and unstable, so that people will look at it 
>>> and say: What the hell is this?
>>>
>>
>> Would it make sense to remove the TTW-management-interface from the 
>> 'core' and into a product ? Could this product be used as an example 
>> of how to write management products for zope3 ?
> 
> 
> This thread was originally about the TTW development facilities, not
> TTW management.  We will certainly include the TTW management facilities
> in the first release.
> 
> At this point, I'm mainly concerned about which features should be
> priorities for finishing for the first release.  I also want to
> set expectations for the first release, in terms if who it's for and how
> we expect people to use it.
> 
> A different question is how this is all going to be packaged.
> I'm still thinking about that.
> 
> It will be possible to replace pretty much anything. It will certainly
> be possible to replace the management UI. While I agree with the
> benefit of organizing things to make this more obvious, I don't
> think I particularly want to take the time to do this now.
> 
> Jim
> 
> 


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Sun Feb  8 17:51:09 2004
From: jim at zope.com (Jim Fulton)
Date: Sun Feb  8 17:51:35 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <402652C1.9070200@weitershausen.de>
References: <bvr8od$o8u$1@sea.gmane.org> <402652C1.9070200@weitershausen.de>
Message-ID: <4026BD5D.9050205@zope.com>

Philipp von Weitershausen wrote:
> Philipp von Weitershausen wrote:
> 
>> Hi there,
>>
>> in the currently ongoing process of reorganizing Zope3's package 
>> structure and gutting out zope.app, I think the main packages that 
>> have yet to be moved are:
>>
>> - zope.app.workflow
>> - zope.app.content
> 
> 
> I have started moving zope.app.content to zope.products.content and 
> zope.products.codecontent, respectively in a branch, 
> 'philikon-movecontent-branch'. Here's a small status report:
> 
>   - zope.app.content is a simple module now containg the ContentType
>     machinery

cool

>   - Folder could not be moved out of zope.app, mainly because it is
>     needed widely by the Zope core for its root folder functionality,
>     e.g. in the bootstrap process. It it is now in zope.app.folder,
>     since zope.app.content is a simple module now.

I like the fact that this is now zope.app.folder.

Hm.

(I'm sorry it couldn't be moved out.  This could be fixed, but I think
  that this isn't important enough now.)

...

> Comments are appreciated, as well as help chasing down the last test 
> failures and fixing the modulealias.

As I mentioend earlier, I don't want zope.products.content and
zope.products.codecontent.  Please split these into top-level packages
in zope.products:

   zope.products.zptpage,
   zope.products.dtmlpage,
   zope.products,sqlscript,
   zope.products,file,
   zope.products.i18nfile
   zope.products,image,
   zope.products.i18nimage

but ,,,,

Before we have you do much more work, I think it would be
a good idea to step back and work out the new treee as we did for
namegeddon.

I suggest doing this on a wiki page.

I suggest we coordinate this with the switch to ZODB 3 so that we can
have a conversion script that adjusts class references in pickles.

Finally, I'd like to consider a simplification of the source layout as follows.
I'd like us to reorganize whatever is left in app so that app is much flatter.
Further, the division of application, view, and interface code should happen
within the subfolders of app, rather than in app. So, for example, we'd get rid of
app.interfaces and app.browser.  The folder package, zope.app.folder would
have interfaces.py, and browser.py.

The problem with this is that it largely undoes the separation of presentation
code we created in namegeddon.  I have to admit, though, that this separation
wasn't very popular, except, possibly with the people it was done for. :)

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org



From jim at zope.com  Sun Feb  8 18:00:11 2004
From: jim at zope.com (Jim Fulton)
Date: Sun Feb  8 18:00:41 2004
Subject: [Zope3-dev] Last chance to mess with the source layout of Zope 3
Message-ID: <4026BF7B.3050407@zope.com>


In preparation for the first release, we are embarking on a
cleanup of the source layout. (See the threads on boving things
out of zope.app.)  It is clear that this is going to be a large effort.
It will probably be impractical to do this again after the first
production release.

Given that, I'd like to put the layout strategy on the table.

The last time we did a major reorganization, we separated the presentation
and interface code from the application code.  This was it make it
easier for user-interface developers to contribute.  I know of one person
whih actually liked the separation of presentation and interfaces from
application code. AFAICT, it's been wildly unpopular for everyone else.
I'm not sure that the people it was done for have even been all that involved.
A few people have been working on UI, but I don't think they consider themselves
UI folk and I bet they don't like the separation.

In a separate note, I suggested a much flatter layout.  I suggested
getting rid of zope.app.browser (and the like) and zope.app.interafces.
I suggested that zope.app have top-level packages in it that are pretty
self-contained with their own interfaces.py and browser.py (and etc.).
A variation on this would be to provide separate UI packages
(e.g, zope.app.folder and zope.app.folderweb).

Thoughts?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From philipp at weitershausen.de  Sun Feb  8 18:26:47 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Sun Feb  8 18:20:05 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <4026BD5D.9050205@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org> <402652C1.9070200@weitershausen.de>
	<4026BD5D.9050205@zope.com>
Message-ID: <4026C5B7.5040500@weitershausen.de>

Hi Jim,

>>   - Folder could not be moved out of zope.app, mainly because it is
>>     needed widely by the Zope core for its root folder functionality,
>>     e.g. in the bootstrap process. It it is now in zope.app.folder,
>>     since zope.app.content is a simple module now.
> 
> 
> I like the fact that this is now zope.app.folder.

Mee too. Btw, all the browser and configuration stuff for it is in 
zope.products.content. It's really only the class and the interface that 
had to stay in there for the imports...

> (I'm sorry it couldn't be moved out.  This could be fixed, but I think
>  that this isn't important enough now.)

Agreed. Seeking the places up gave me a good understanding of how this 
dependency is wired up. It's mostly on the 'rootFolder()' function, not 
on the Folder class itself.

>> Comments are appreciated, as well as help chasing down the last test 
>> failures and fixing the modulealias.
> 
> As I mentioend earlier, I don't want zope.products.content and
> zope.products.codecontent.

Oh, I totally misunderstood you then! I thought that was the one you 
were agreeing with me on... Never mind then.

> Please split these into top-level packages
> in zope.products:
> 
>   zope.products.zptpage,
>   zope.products.dtmlpage,
>   zope.products,sqlscript,
>   zope.products,file,
>   zope.products.i18nfile
>   zope.products,image,
>   zope.products.i18nimage

Ahh. Sounds good to me too.

> Before we have you do much more work, I think it would be
> a good idea to step back and work out the new treee as we did for
> namegeddon.

Good idea.

> I suggest doing this on a wiki page.

Will do that.

> I suggest we coordinate this with the switch to ZODB 3 so that we can
> have a conversion script that adjusts class references in pickles.

Ok. Once we have it figured out on the wiki page, I can adjust the 
branch slowly but surely, so it'll be ready when the ZODB3 merge is to 
be done. I guess you'll do the final merging then. When do you expect 
that to happen, so I know the timeframe?

> Finally, I'd like to consider a simplification of the source layout
> as follows. I'd like us to reorganize whatever is left in app so that
> app is much flatter. Further, the division of application, view, and
> interface code should happen within the subfolders of app, rather
> than in app. So, for example, we'd get rid of app.interfaces and
> app.browser.  The folder package, zope.app.folder would have
> interfaces.py, and browser.py.

One part of me wants to yell "Yay", the other has doubts. We have and 
will be taking out of zope.app many things, so it'll be smaller anyway. 
Maybe we'll be able to look at it just like another 'zope.' package...

> The problem with this is that it largely undoes the separation of 
> presentation code we created in namegeddon.  I have to admit, though,
> that this separation wasn't very popular, except, possibly with the
> people it was done for. :)

I feel inbetween the people it was done for and the ones it is unpopular 
with. At first, I found the package hierarchy quite confusing. I 
understood its theory and why it was that way, but it felt unnatural. 
This is probably most people's reaction to it. Lately, I have been 
hearing a lot that Zope3 is too much based on theory and not 
straight-forward enough. Maybe we should pay attention to our very own 
natural feelings in this case and go against the theory...

Well, I'm not helping, am I... :)

Philipp


From tseaver at zope.com  Sun Feb  8 18:56:55 2004
From: tseaver at zope.com (Tres Seaver)
Date: Sun Feb  8 18:57:02 2004
Subject: [Zope3-dev] Re: CVS: Zope3/src/zope/app/browser/skins/rotterdam -
	editingwidgets.py:1.4.24.2
In-Reply-To: <200402080457.i184vsct002180@cvs.zope.org>
References: <200402080457.i184vsct002180@cvs.zope.org>
Message-ID: <4026CCC7.5000909@zope.com>

Garrett Smith wrote:
> Update of /cvs-repository/Zope3/src/zope/app/browser/skins/rotterdam
> In directory cvs.zope.org:/tmp/cvs-serv2048/src/zope/app/browser/skins/rotterdam
> 
> Modified Files:
>       Tag: ozzope-widgets-branch
> 	editingwidgets.py 
> Log Message:
> 
> Trivial whitespace fix.
> 
> 
> === Zope3/src/zope/app/browser/skins/rotterdam/editingwidgets.py 1.4.24.1 => 1.4.24.2 ===
> --- Zope3/src/zope/app/browser/skins/rotterdam/editingwidgets.py:1.4.24.1	Sat Feb  7 23:36:11 2004
> +++ Zope3/src/zope/app/browser/skins/rotterdam/editingwidgets.py	Sat Feb  7 23:57:53 2004
> @@ -27,7 +27,7 @@
>      width = 60
>      height = 15
>      extra=""
> -    style="width: 98%; font-family: monospace;"
> +    style="width: 98%; font-family: monospace;".
>      rowTemplate = ViewPageTemplateFile("simpleeditingrow.pt")
>      rowFragment = ViewPageTemplateFile("simpleeditingrowfragment.pt")


Two things jump out at me:

   - That line isn't valid Python;  ergo, we must not have any unit
     tests for this module.

   - What in the name of separation-of-concerns are we doing adding
     inline styles, and in Python code?

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com


From jim at zope.com  Sun Feb  8 19:05:47 2004
From: jim at zope.com (Jim Fulton)
Date: Sun Feb  8 19:06:57 2004
Subject: [Zope3-dev] Namegeddon2
In-Reply-To: <4026C5B7.5040500@weitershausen.de>
References: <bvr8od$o8u$1@sea.gmane.org> <402652C1.9070200@weitershausen.de>
	<4026BD5D.9050205@zope.com> <4026C5B7.5040500@weitershausen.de>
Message-ID: <4026CEDB.9090501@zope.com>

Philipp von Weitershausen wrote:
> Hi Jim,
> 
...

>> I suggest we coordinate this with the switch to ZODB 3 so that we can
>> have a conversion script that adjusts class references in pickles.
> 
> 
> Ok. Once we have it figured out on the wiki page, I can adjust the 
> branch slowly but surely, so it'll be ready when the ZODB3 merge is to 
> be done.

Kapil wrote a script for the first namegeddon that automated most of the
moving.  It left enough undone, however, that it might be worth trying to
improve it.  We tried to do the first namegeddon too quickly and
ended up doing more work that we should have.  We should do a few dry runs
and try to improve the script.


 > I guess you'll do the final merging then. When do you expect
> that to happen, so I know the timeframe?

Well, all the Zope 3 tests pass with ZODB 3.3. Steve is testing
the conversion script.  I think that that branch will be ready to
merge next week.

This is going to be a little delicate. :)

I'm not sure what the best way to handle this is.

Some issues:

- The ZODB conversion will require running a database conversion
   script.

- namegeddon2 will require running a database conversion script.

   We may want to combine the two, unless we don't. ;)
   Perhaps it's better to keep them separate.

- Anybody with pending work, including work in branches is
   going to be hurt.

Jim


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Sun Feb  8 19:17:31 2004
From: jim at zope.com (Jim Fulton)
Date: Sun Feb  8 19:18:48 2004
Subject: [Zope3-dev] Heads Up! Namegeddon 2
Message-ID: <4026D19B.5060905@zope.com>


I think we are going to decide to have a second and final
namegeddon before the first release.  My guess is that this
should happen the week of February 23-27. We will probably
ask that people not check things in during that week.
Also, if there is pending work at the end of that week,
merging it will probably be rather difficult.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From philipp at weitershausen.de  Sun Feb  8 20:02:28 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Sun Feb  8 19:55:45 2004
Subject: [Zope3-dev] Re: Namegeddon2
In-Reply-To: <4026CEDB.9090501@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org> <402652C1.9070200@weitershausen.de>
	<4026BD5D.9050205@zope.com> <4026C5B7.5040500@weitershausen.de>
	<4026CEDB.9090501@zope.com>
Message-ID: <4026DC24.4060309@weitershausen.de>

Jim Fulton wrote:
>> Ok. Once we have it figured out on the wiki page, I can adjust the 
>> branch slowly but surely, so it'll be ready when the ZODB3 merge is to 
>> be done.
> 
> Kapil wrote a script for the first namegeddon that automated most of the
> moving.  It left enough undone, however, that it might be worth trying to
> improve it.  We tried to do the first namegeddon too quickly and
> ended up doing more work that we should have.  We should do a few dry runs
> and try to improve the script.

It'd be great to end up with a somewhat generic script we can use 
whenever we "break" things like this... I could imagine that, maybe on a 
smaller scale, that we will still want to do that once Zope3 is out. 
It'll be good to know that we have a good conversion script.

>> I guess you'll do the final merging then. When do you expect
>> that to happen, so I know the timeframe?
> 
> Well, all the Zope 3 tests pass with ZODB 3.3. Steve is testing
> the conversion script.  I think that that branch will be ready to
> merge next week.

Great to hear that.

> I'm not sure what the best way to handle this is.
> 
> Some issues:
> 
> - The ZODB conversion will require running a database conversion
>   script.
> 
> - namegeddon2 will require running a database conversion script.
> 
>   We may want to combine the two, unless we don't. ;)
>   Perhaps it's better to keep them separate.

I think it is. Let's take one step at a time. Also, namegeddon2 (btw, I 
think it's not a *name*geddon, rather a packagegeddon) should probably 
be broken up into steps. Moving out the content is the first one. Others 
could follow.

Philipp


From philipp at weitershausen.de  Sun Feb  8 20:05:20 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Sun Feb  8 19:58:34 2004
Subject: [Zope3-dev] Re: Last chance to mess with the source layout of Zope 3
In-Reply-To: <4026BF7B.3050407@zope.com>
References: <4026BF7B.3050407@zope.com>
Message-ID: <4026DCD0.7050509@weitershausen.de>

> In a separate note, I suggested a much flatter layout.  I suggested
> getting rid of zope.app.browser (and the like) and zope.app.interafces.
> I suggested that zope.app have top-level packages in it that are pretty
> self-contained with their own interfaces.py and browser.py (and etc.).
> A variation on this would be to provide separate UI packages
> (e.g, zope.app.folder and zope.app.folderweb).

+1 for self-contained packages inside zope.app.
-1 to zope.app.folderweb or similar


From stephan.richter at tufts.edu  Sun Feb  8 20:39:28 2004
From: stephan.richter at tufts.edu (Stephan Richter)
Date: Sun Feb  8 20:39:57 2004
Subject: [Zope3-dev] Re: [Zope3-checkins] CVS:
	Zope3/src/zope/app/interfaces/browser - widget.py:1.1.2.4
In-Reply-To: <200402082247.i18Mldk9011431@cvs.zope.org>
References: <200402082247.i18Mldk9011431@cvs.zope.org>
Message-ID: <200402082039.28209.stephan.richter@tufts.edu>

On Sunday 08 February 2004 17:47, Dave Fregon wrote:
> +class ISimpleEditingWidget(IBrowserWidget, IEditWidget):
> + ? ?
> + ? ?width = Attribute("XXX - needs documentation")
> + ? ?height = Attribute("XXX - needs documentation")
> + ? ?extra = Attribute("XXX - needs documentation")
> +

Please do not do this!!! Take the 5 minutes and add a meaningful doc string. 
The API doc tool is useless with doc strings like this.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From garrett at mojave-corp.com  Sun Feb  8 21:03:40 2004
From: garrett at mojave-corp.com (Garrett Smith)
Date: Sun Feb  8 20:59:53 2004
Subject: [Zope3-dev] ozzope-widgets-branch
Message-ID: <FB37E9B9E9354A4788F1B322E4AAD1D880A8@server1.mojave.local>

Readers of the CVS commit list for Zope 3 can save themselves some
stress and worry by disregarding commits to the 'ozzope-widgets-branch'
for the next day. I'm working with Dave Fregon here in Melbourne and
we're using the branch for parallel development.

I'm not adhering to checkin standards for this phase, which is why we're
working on a branch.

I think the community will find the resulting code well documented,
tested, and clear once it's merged into the head.

 -- Garrett

From stephan.richter at tufts.edu  Sun Feb  8 22:19:30 2004
From: stephan.richter at tufts.edu (Stephan Richter)
Date: Sun Feb  8 22:19:55 2004
Subject: [Zope3-dev] Re: [Zope3-checkins] CVS:
	Zope3/src/zope/app/browser/services - error.zcml:1.1
	configure.zcml:1.81 error.py:1.8
In-Reply-To: <200402090209.i192932R016693@cvs.zope.org>
References: <200402090209.i192932R016693@cvs.zope.org>
Message-ID: <200402082219.30717.stephan.richter@tufts.edu>

On Sunday 08 February 2004 21:09, Anthony Baxter wrote:
> zmi_actions menu now has an 'Errors' entry in all places that takes you
> to the error log. Woo hoo!

I consider this not to be a good thing. One of the annoying things about the 
Zope 2 tabs was that there were usually more general tabs that applied to all 
objects than specific ones. Please let's not repeat this for Zope 3. 

BTW, the same is true for the caching tab. Not every object needs caching for 
itself.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From philipp at weitershausen.de  Mon Feb  9 04:09:24 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Mon Feb  9 04:02:54 2004
Subject: [Zope3-dev] Re: CVS: Zope3/src/zope/app/browser/skins/rotterdam -
	zope3.css:1.28
In-Reply-To: <200402090107.i1917e8f004800@cvs.zope.org>
References: <200402090107.i1917e8f004800@cvs.zope.org>
Message-ID: <40274E44.4050504@weitershausen.de>

Anthony Baxter wrote:
> -    scrollbar-3dlight-color: #336699;
> -    scrollbar-shadow-color: #336699;
> +    scrollbar-3dlight-color: #369;
> +    scrollbar-shadow-color: #369;

Maybe I'm not too familiar with the CSS spec, but is this a unique 
description of an RGB colour? Even if it is, I personally would prefer 
the full RRGGBB colour for easier human interpretation...


From richard at commonground.com.au  Mon Feb  9 04:31:01 2004
From: richard at commonground.com.au (Richard Jones)
Date: Mon Feb  9 04:31:04 2004
Subject: [Zope3-dev] Re: CVS: Zope3/src/zope/app/browser/skins/rotterdam -
	zope3.css:1.28
In-Reply-To: <40274E44.4050504@weitershausen.de>
References: <200402090107.i1917e8f004800@cvs.zope.org>
	<40274E44.4050504@weitershausen.de>
Message-ID: <ACA4E6CE-5AE2-11D8-84CE-000A95ABA188@commonground.com.au>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/02/2004, at 8:09 PM, Philipp von Weitershausen wrote:
> Anthony Baxter wrote:
>> -    scrollbar-3dlight-color: #336699;
>> -    scrollbar-shadow-color: #336699;
>> +    scrollbar-3dlight-color: #369;
>> +    scrollbar-shadow-color: #369;
>
> Maybe I'm not too familiar with the CSS spec, but is this a unique 
> description of an RGB colour? Even if it is, I personally would prefer 
> the full RRGGBB colour for easier human interpretation...

This is a valid shorter version of the RGB colour. It's not exactly the 
same, but it's close enough - unless exact colour matching is desired 
(which I doubt) then it'll do.


      Richard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAJ1NdrGisBEHG6TARAr3HAKCBH3pNR07xcXR84HYkhTIS5A53ZgCcDS3j
MOWOdPZHzzGe62n8Ollnw3w=
=05SV
-----END PGP SIGNATURE-----


From anthony at interlink.com.au  Mon Feb  9 05:51:41 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Mon Feb  9 05:52:06 2004
Subject: [Zope3-dev] Re: [Zope3-checkins] CVS:
	Zope3/src/zope/app/browser/services - error.zcml:1.1
	configure.zcml:1.81 error.py:1.8
Message-ID: <20040209105141.E05BD25ADA2@bonanza.off.ekorp.com>


>>> Stephan Richter wrote
> I consider this not to be a good thing. One of the annoying things    
> about the Zope 2 tabs was that there were usually more general tabs   
> that applied to all objects than specific ones. Please let's not      
> repeat this for Zope 3.                                               

Spot polling of everyone here (including Jim) was that this was a good
thing, not a bad thing. The Errors tab is almost always useful.

The Caching tab has been fixed.

Anthony


From srichter at cosmos.phy.tufts.edu  Sun Feb  8 22:26:42 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Mon Feb  9 06:10:36 2004
Subject: [Zope3-dev] ozzope-widgets-branch
In-Reply-To: <FB37E9B9E9354A4788F1B322E4AAD1D880A8@server1.mojave.local>
References: <FB37E9B9E9354A4788F1B322E4AAD1D880A8@server1.mojave.local>
Message-ID: <200402082226.42318.srichter@cosmos.phy.tufts.edu>

On Sunday 08 February 2004 21:03, Garrett Smith wrote:
> I'm not adhering to checkin standards for this phase, which is why we're
> working on a branch.
>
> I think the community will find the resulting code well documented,
> tested, and clear once it's merged into the head.

Sorry, I do not want to come across rude or picky.

I just want to make sure it is not missed when it enters the HEAD.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From nicoe at altern.org  Mon Feb  9 06:35:19 2004
From: nicoe at altern.org (Nicolas =?iso-8859-15?Q?=C9vrard?=)
Date: Mon Feb  9 06:35:26 2004
Subject: [Zope3-dev] Issue 124 in the collector.
Message-ID: <20040209113519.GA28560@smarties.nutellux.ath.cx>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20040209/005edce4/attachment.bin
From tseaver at zope.com  Mon Feb  9 07:22:58 2004
From: tseaver at zope.com (Tres Seaver)
Date: Mon Feb  9 07:23:05 2004
Subject: [Zope3-dev] Re: Issue 124 in the collector.
In-Reply-To: <20040209113519.GA28560@smarties.nutellux.ath.cx>
References: <20040209113519.GA28560@smarties.nutellux.ath.cx>
Message-ID: <40277BA2.4070003@zope.com>

Nicolas ?vrard wrote:

> I've met the issue 124 from the collector again but I found a way around
> this issue.
> 
> The Python you're using when running zope3 should have
> sys.defaultencoding set to 'utf' and not 'ascii'.
> 
> On my debian system, it's impossible to use sys.setdefaultencoding() so
> I could not try the patch but it should work.

Can you edit /path/to/python2.3/site-packges/sitecustomize.py?  That 
file is the only possible place to change the encoding, I think.

   $ more /opt/zc/lib/python2.3/site-packages/sitecustomize.py
   import sys
   sys.setdefaultencoding('latin-1')

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com


From dorneles at x3ng.com.br  Mon Feb  9 07:33:59 2004
From: dorneles at x3ng.com.br (=?ISO-8859-1?Q?Dorneles_Trem=E9a?=)
Date: Mon Feb  9 07:40:26 2004
Subject: [Zope3-dev] Re: CVS: Zope3/src/zope/app/browser/skins/rotterdam -
	zope3.css:1.28
In-Reply-To: <ACA4E6CE-5AE2-11D8-84CE-000A95ABA188@commonground.com.au>
References: <200402090107.i1917e8f004800@cvs.zope.org>	<40274E44.4050504@weitershausen.de>
	<ACA4E6CE-5AE2-11D8-84CE-000A95ABA188@commonground.com.au>
Message-ID: <c07unb$qtm$1@sea.gmane.org>

Hi,

> > Maybe I'm not too familiar with the CSS spec, but is this a unique
> > description of an RGB colour? Even if it is, I personally would prefer
> > the full RRGGBB colour for easier human interpretation...
> 
> This is a valid shorter version of the RGB colour. It's not exactly the
> same, but it's close enough - unless exact colour matching is desired
> (which I doubt) then it'll do.

hum... I'm sure it's EXACTLY the same[1], but I always preffered
#RRGGBB... :-)

[1] http://www.w3.org/TR/CSS21/syndata.html#color-units

Regards,

-- 

Dorneles Trem?a
Caxias do Sul - RS - Brasil
+55 54 9114 9312 - UIN: 2413568
X3ng Web Technology <http://www.x3ng.com.br>

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/IT d- s:->: a24 C+++ UBL++++$ P--- L++ E-- W+++
N++ o? K? w+ O M+ V-- PS+ PE- Y-- PGP++ t+ 5 X++ R+
tv+ b(++) DI+ D++ G+>+++ e++>++++ h---- r+++ y+++**
------END GEEK CODE BLOCK------


From jeremy at zope.com  Mon Feb  9 10:00:14 2004
From: jeremy at zope.com (Jeremy Hylton)
Date: Mon Feb  9 10:00:51 2004
Subject: [Zope3-dev] Re: [ZODB-Dev] Is anyone using persistent modules at
	the moment?
In-Reply-To: <4026BAA1.8080408@zope.com>
References: <4026BAA1.8080408@zope.com>
Message-ID: <1076338814.21762.22.camel@localhost.localdomain>

On Sun, 2004-02-08 at 17:39, Jim Fulton wrote:
> I'm thinking of breaking them for a while and not taking the time to fix them,
> assuming that no one is actually using them.

I'm not using them.  Are you planning to break them in Zope or ZODB?

Jeremy



From tseaver at zope.com  Mon Feb  9 10:19:13 2004
From: tseaver at zope.com (Tres Seaver)
Date: Mon Feb  9 10:19:17 2004
Subject: [Zope3-dev] Re: Issue 124 in the collector.
In-Reply-To: <20040209150522.GC28560@smarties.nutellux.ath.cx>
References: <20040209113519.GA28560@smarties.nutellux.ath.cx>
	<40277BA2.4070003@zope.com>
	<20040209134355.GB28560@smarties.nutellux.ath.cx>
	<40279FD1.5030609@zope.com>
	<20040209150522.GC28560@smarties.nutellux.ath.cx>
Message-ID: <4027A4F1.3070100@zope.com>

Nicolas ?vrard wrote:
> * Tres Seaver  [15:57 09/02/04 CET]:
> 
>>>
>>> Indeed, that's what I've done on my system. But I think this issue
>>> should be adressed in the zope3 starting script.
>>
>>
>> It can't be -- the Python interpreter *won't allow* that value to be 
>> set except in sitecustomize.py.  See this bit (from Lib/site.py in 
>> your Python distribution):

(oops, I forgot to CC the list last time).

> Ok. I though this was a debian specificity.
> Does this mean that zope3 on a default python install will always have
> this issue ? Or will there be some magic involved I cannot see yet ?

Perhaps we should be lobbying to have Python add a command-line 
parameter for specifying the default encoding?  /me checks:

  $ /opt/zc/bin/python -h
  ...
  -S     : don't imply 'import site' on initialization

So, one could run python with -S, and then invoke 
'sys.setdefaultencoding("latin-1")' later during Zope startup.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com

From casey at zope.com  Mon Feb  9 11:18:21 2004
From: casey at zope.com (Casey Duncan)
Date: Mon Feb  9 11:21:04 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <20040208203643.GD1723@slinkp.com>
References: <40230606.4090805@zope.com>
	<200402070811.35507.srichter@cosmos.phy.tufts.edu>
	<40257358.5040607@zope.com>
	<200402071929.25507.srichter@cosmos.phy.tufts.edu>
	<402586CC.8040503@zope.com> <20040208203643.GD1723@slinkp.com>
Message-ID: <20040209111821.3f2c3f7e.casey@zope.com>

On Sun, 8 Feb 2004 15:36:43 -0500
Paul Winkler <pw_lists@slinkp.com> wrote:

> On Sat, Feb 07, 2004 at 07:46:04PM -0500, Jim Fulton wrote:
> > Stephan Richter wrote:
[..]
> I think the controversy over embedding python in ZPT and
> embedding HTML in python should not be taken lightly, and
> if we are not ready to focus on it, we should stop arguing about
> it for now. I have plenty to say on the subject but I think
> this is not the time.

Suppose you see the following email on zope@zope.org after Zope 3 goes
mainstream:

  Subject: Need Help

  Hi All,

  We've got a large Zope (3) site that we've had in production for a few
months
  now. Our main developer just moved to Timbuktu however and took all of
our
  Zope zen with him. I've tried to figure out how this stuff works, but
I'm not
  really a programmer and all this ZPT stuff is too confusing for me. I
sort of
  understand HTML and Javascript but our site has hundreds of these tags
I
  don't fully understand:

  <script type="server/python">
      if grail.spam > ham:
          web.soup = noodle
          ...
  </script>

  I can't find any curly braces in the code, so it's gibberish to me. I
guess
  we really need to hire an expert to sort this thing out. Any
recommendations?

  -Hapless

To me this reads like current messages on zope@zope.org that contain the
terms "ZClass" and "DTML". To me this screams "Run Away!"

Now at least the situation is ignorable. But imagine another senario
where you inherit a site built all using TTW scripting with no
separation of presentation, content and business logic. It's your job to
make it a success. Yikes!

To me this sort of thing is like inline styles in HTML. Do I ever use
inline styles? Yes I do, but very rarely and (hopefully) only when there
is no other effective way to do what I want with the stylesheet (perhaps
too dynamic), or I just plain can't change the stylesheet (or the
document <head></head>). Do I feel a little dirty when I decide to use
them? Yes. Sometimes I use them temporarily just to sketch something,
knowing that I will create a stylesheet and do it the "right way" later.

I think that the inline scripting is aimed at the same problem space.
The quick and dirty thing that you know isn't the "right" way
recommended by 4 out of 5 Zope developers. The thing you don't use to
solve meaningful problems long-term. 

Since it looks like it is inevitable that Zope will have this, I ask for
the following:

  - The limitations, and intended usage of these scripting features be
made abundantly
    clear in the docs and that the alternatives be referenced
conspicuously explaining
    their benefits. The lack of this sort of thing currently for Zope 2
sends many down
    dark dead-end alleys IMO.

  - That these inline scripting features are not part of, nor are they
used by the Zope
    core. That they be in a product or otherwise separated in such a way
that I can 
    turn them off or distribute Zope without them if I choose,

Also, remember the wisdom of "One way to do it". This is something that
Zope IMO has never really followed in the past, which I attribute to the
immaturity of the problem space. If we sponsor many ways to do a single
thing to Zope, this contributes to rather than reduces the complexity
and learning curve overall. This, of course needs to be balanced against
the broad appeal and acceptance that we desire for Zope to have.

If inline scripting helps more people adopt Zope that may be good,
unless they learn to hate it because no one told them that doing things
this way is very difficult to scale and maintain. Lets not make Zope so
much like other solutions as to also inherit their shortcomings as a
result.

-Casey

From pw_lists at slinkp.com  Mon Feb  9 11:50:25 2004
From: pw_lists at slinkp.com (Paul Winkler)
Date: Mon Feb  9 11:50:30 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <20040209111821.3f2c3f7e.casey@zope.com>
References: <40230606.4090805@zope.com>
	<200402070811.35507.srichter@cosmos.phy.tufts.edu>
	<40257358.5040607@zope.com>
	<200402071929.25507.srichter@cosmos.phy.tufts.edu>
	<402586CC.8040503@zope.com> <20040208203643.GD1723@slinkp.com>
	<20040209111821.3f2c3f7e.casey@zope.com>
Message-ID: <20040209165025.GF1716@slinkp.com>

On Mon, Feb 09, 2004 at 11:18:21AM -0500, Casey Duncan wrote:
> On Sun, 8 Feb 2004 15:36:43 -0500
> Paul Winkler <pw_lists@slinkp.com> wrote:
> 
> > On Sat, Feb 07, 2004 at 07:46:04PM -0500, Jim Fulton wrote:
> > > Stephan Richter wrote:
> [..]
> > I think the controversy over embedding python in ZPT and
> > embedding HTML in python should not be taken lightly, and
> > if we are not ready to focus on it, we should stop arguing about
> > it for now. I have plenty to say on the subject but I think
> > this is not the time.
> 
> Suppose you see the following email on zope@zope.org after Zope 3 goes
> mainstream:

(snip)

Well, apparently Casey feels that now IS the time to argue about
it, and psychically extracted my objections as well ;-)

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's THE FATUOUS CHAIN!
(random hero from isometric.spaceninja.com)

From chrism at plope.com  Mon Feb  9 11:59:37 2004
From: chrism at plope.com (Chris McDonough)
Date: Mon Feb  9 11:59:41 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <20040209165025.GF1716@slinkp.com>
References: <40230606.4090805@zope.com>
	<200402070811.35507.srichter@cosmos.phy.tufts.edu>
	<40257358.5040607@zope.com>
	<200402071929.25507.srichter@cosmos.phy.tufts.edu>
	<402586CC.8040503@zope.com> <20040208203643.GD1723@slinkp.com>
	<20040209111821.3f2c3f7e.casey@zope.com>
	<20040209165025.GF1716@slinkp.com>
Message-ID: <1076345977.20894.99.camel@athlon>

+1 to Casey's concerns ;-)



From Mailer-Daemon at python.org  Mon Feb  9 12:08:06 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Mon Feb  9 12:08:21 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1AqEtC-0001EB-NI@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1Apd17-0001K4-Cr; Sat, 07 Feb 2004 19:41:45 -0500
From: zope3-dev@zope.org (anthony)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [Zope3GUI] 
Message-ID: <20040207194145EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Sat, 07 Feb 2004 19:41:45 -0500
X-Spam-Status: OK (default 0.038)

??changed:
-        If you now click on the "View default package" action link, you end up
        If you now click on the "View default folder" action link, you end up

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI

From Mailer-Daemon at python.org  Mon Feb  9 12:08:38 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Mon Feb  9 12:08:40 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1AqEti-0001Pm-DH@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1Apcy7-0006QV-C8; Sat, 07 Feb 2004 19:38:39 -0500
From: zope3-dev@zope.org (anthony)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [Zope3GUI] 
Message-ID: <20040207193839EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Sat, 07 Feb 2004 19:38:39 -0500
X-Spam-Status: OK (default 0.032)

??changed:
-      The '<script>' tag and attribute
      The 'script' tag and attribute

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI

From jpenny at universal-fasteners.com  Mon Feb  9 12:10:01 2004
From: jpenny at universal-fasteners.com (Jim Penny)
Date: Mon Feb  9 12:10:08 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <20040208203643.GD1723@slinkp.com>
References: <40230606.4090805@zope.com>
	<200402070811.35507.srichter@cosmos.phy.tufts.edu>
	<40257358.5040607@zope.com>
	<200402071929.25507.srichter@cosmos.phy.tufts.edu>
	<402586CC.8040503@zope.com> <20040208203643.GD1723@slinkp.com>
Message-ID: <20040209121001.35b1933a.jpenny@universal-fasteners.com>

On Sun, 8 Feb 2004 15:36:43 -0500
Paul Winkler <pw_lists@slinkp.com> wrote:

> On Sat, Feb 07, 2004 at 07:46:04PM -0500, Jim Fulton wrote:
> > Stephan Richter wrote:
> > >>I don't agree.  I don't think this has been well thought out
> > >>and what has been done is controversial.
> > >
> > >
> > >I think it has been controversial because everyone on the mailing
> > >list is not in the audience. Both, the SQLExpr and inline Python
> > >support came from feedback from people that deal with scripters all
> > >the time. For the purists any scripting support will look like a
> > >hack.
> > 

I frankly hate SQL expressions, and am 97% in the realm of pure
scripter, in the sense being used here.

I have many problems with it.  First, it makes it much harder to
maintain or change in event of a mistake or requirements change if your
SQL methods are directly embedded in many places.  Second, many systems
that do this have a history of leaking information inadvertently,
including passwords.  While I am sure that you guys will be very
careful, think of the disaster this kind of thing would have caused in
Zope 2.3 where tracebacks were presented to anyone who triggered an
exception.

I think that these requests come from scripters, sure.  But they come
from ASP or PHP scripters - and have proven to be real problems in both
of those systems.  Don't replicate mistakes!

Jim Penny

From Mailer-Daemon at python.org  Mon Feb  9 12:32:36 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Mon Feb  9 12:32:39 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1AqFGu-00069F-IQ@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1Apd6F-0005qx-0w; Sat, 07 Feb 2004 19:47:03 -0500
From: zope3-dev@zope.org (anthony)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [Zope3GUI] 
Message-ID: <20040207194703EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Sat, 07 Feb 2004 19:47:03 -0500
X-Spam-Status: OK (default 0.010)

??changed:
-       01 <html>
-       02   <body>
-       03    <h3 tal:content="
-       04        context/msg1/adapt:imessage_adapters.IAllText/getText">
-       05       All message text goes here
-       06    </h3>
-       07   </body>
-       08 </html> 
        01 <html>
        02   <body>
        03    <h3 tal:content="
        04        context/msg1/adapt:imessage_adapters.IAllText/getText">
        05       All message text goes here
        06    </h3>
        07   </body>
        08 </html> 

??changed: - to the concepts in Zope 3. to the concepts in Zope 3.
--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI

From Mailer-Daemon at python.org  Mon Feb  9 12:34:06 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Mon Feb  9 12:34:12 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1AqFIM-0006uJ-GB@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1Aq5Sd-0003lM-3a; Mon, 09 Feb 2004 02:04:03 -0500
From: zope3-dev@zope.org (anthony)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [Zope3Proposals] 
Message-ID: <20040209020402EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Proposals/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Proposals/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Proposals>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Mon, 09 Feb 2004 02:04:02 -0500
X-Spam-Status: OK (default 0.011)

++added:
- [The browser:tool directive]

  Provide ZCML machinery to support the creation of screens
  to manage tools.
--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Proposals

From Mailer-Daemon at python.org  Mon Feb  9 12:55:53 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Mon Feb  9 12:55:56 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1AqFdR-0001rx-Te@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1Aq5U8-0004Fb-St; Mon, 09 Feb 2004 02:05:36 -0500
From: zope3-dev@zope.org (anthony)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [AnthonyBaxter] (new) 
Message-ID: <20040209020536EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/AnthonyBaxter/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/AnthonyBaxter/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/AnthonyBaxter>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Mon, 09 Feb 2004 02:05:36 -0500
X-Spam-Status: OK (default 0.034)

Anthony Baxter: anthony at interlink dot com dot au

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/AnthonyBaxter

From Mailer-Daemon at python.org  Mon Feb  9 13:03:03 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Mon Feb  9 13:03:05 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1AqFkN-0005WR-6q@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1ApxoT-0006w8-PP; Sun, 08 Feb 2004 17:54:05 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [DevelCookbook] removed service tests chapter
Message-ID: <20040208175405EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Sun, 08 Feb 2004 17:54:05 -0500
X-Spam-Status: OK (default 0.003)

??changed:
-           detail how various pieces of functionality can be tested. (4 pages)
           detail how various pieces of functionality can be tested. (7 pages)

??changed: - these cases it is shown how example-driven doctests can
be useful. (3 pages) these cases it is shown how example-driven
doctests can be useful. (4 pages)

??changed: - detail. (5 pages) - - 04. Testing Services
(TestingServices) - Since services require a lot - of setup of other
components, this recipe explains how to write - these tests. (4 pages)
detail. (7 pages)

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook

From Mailer-Daemon at python.org  Mon Feb  9 13:06:48 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Mon Feb  9 13:06:51 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1AqFo0-0007am-7M@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1Apl16-0003gn-BT; Sun, 08 Feb 2004 04:14:16 -0500
From: zope3-dev@zope.org (gintautasm)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [Zope3GUI] some rewording
Message-ID: <20040208041415EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Sun, 08 Feb 2004 04:14:15 -0500
X-Spam-Status: OK (default 0.000)

??changed:
-    After Zope 3 started, you can enter the Zope Management Interface (ZMI)
    After Zope 3 is started, you can enter the Zope Management Interface (ZMI)

??changed: - Zope 3 supports a very flexible skinning support, which
allows you to Zope 3 has very flexible skinning support which allows
you to

??changed: - Overall, the entire ZMI is built to follow contain these
elements for - consistency. Overall, the entire ZMI is built to
contain these elements for consistency.

??changed: - the folder being displayed. Of course you can just call
the page from - the browser using:: the folder being displayed. Of
course you can just open the page directly using::

??changed: - from TALES expressions, as it is demonstrated on Line 06.
You can even from TALES expressions, as demonstrated on line 06. You
can even

++added:

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI

From Mailer-Daemon at python.org  Mon Feb  9 13:37:06 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Mon Feb  9 13:37:08 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1AqGHK-0007DA-J5@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1Apkqk-0002Cn-6o; Sun, 08 Feb 2004 04:03:34 -0500
From: zope3-dev@zope.org (gintautasm)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [Zope3GUI] 
Message-ID: <20040208040333EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Sun, 08 Feb 2004 04:03:33 -0500
X-Spam-Status: OK (default 0.028)

??changed:
-      *[ Marked Screenshot of http://localhost:8080/manage pointing out all
-         sections ]*
      *[ Marked Screenshot of http://localhost:8080/manage pointing out all sections ]*

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3GUI

From Mailer-Daemon at python.org  Mon Feb  9 13:56:38 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Mon Feb  9 13:56:40 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1AqGaE-0000Pq-B9@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1AqDE1-0004DW-U0; Mon, 09 Feb 2004 10:21:29 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [DevelCookbook] Removed chapters that have little with Z3 dev; originally added out of fear of not enough content
Message-ID: <20040209102129EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Mon, 09 Feb 2004 10:21:29 -0500
X-Spam-Status: OK (default 0.000)

??changed:
-       07. The Usefulness of Transactions on Networked Systems
-           (UsingTransactions) - Transactions are a powerful concept that are
-           useful even outside of Zope. This recipe will show how to use
-           Transactions apart from Zope. (8 pages)
-
-       08. Storing data in the ZODB (UsingZODB4) - The Persistence framework
-           used in Zope 3 can be utilized outside of Zope as well. This is a
-           quick demonstration on how to write applications that use the
-           Persistence framework to store data. (7 pages)
-
-       09. The life of a Request (LifeOfRequest) - This recipe will show the
       07. The life of a Request (LifeOfRequest) - This recipe will show the

??changed: - 01. Using ZConfig for Configurations (UsingZConfig) -
Zope Corporation - developed a very powerful configuration "language"
that is geared - towards the system administrator (i.e. it looks very
similar to - Apache's configuration files). This recipe describes how
to develop - a ZConfig schema and how to use it for your own software
(does not - have to be Zope at all). (6 pages) - - 02. Using
annotations to store meta data (AnnotationsForMetaData) - 01. Using
annotations to store meta data (AnnotationsForMetaData) -

??changed: - 03. "Displaying User errors":DisplayUserErrors - For Zope
3, Exceptions 02. "Displaying User errors":DisplayUserErrors - For
Zope 3, Exceptions

??changed: - 04. "Writing new ZCML Directives":NewZCMLDirectives -
Discusses how new 03. "Writing new ZCML Directives":NewZCMLDirectives
- Discusses how new

??changed: - 05. Changing Traversal Behavior
(ChangingTraversalBehavior) - Similar 04. Changing Traversal Behavior
(ChangingTraversalBehavior) - Similar

??changed: - 06. Debugging Python and Zope Code
(DebuggingPythonAndZope) - This 05. Debugging Python and Zope Code
(DebuggingPythonAndZope) - This

??changed: - 07. Application Security Audit (SecurityAudit) - Even
though Zope 3 06. Application Security Audit (SecurityAudit) - Even
though Zope 3

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook

From Mailer-Daemon at python.org  Mon Feb  9 13:59:16 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Mon Feb  9 13:59:21 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1AqGcm-0001hL-I0@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1Aq5TL-0003yD-1d; Mon, 09 Feb 2004 02:04:47 -0500
From: zope3-dev@zope.org (anthony)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [The browser:tool directive] (new) 
Message-ID: <20040209020446EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TheBrowserToolDirective/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TheBrowserToolDirective/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TheBrowserToolDirective>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Mon, 09 Feb 2004 02:04:46 -0500
X-Spam-Status: OK (default 0.000)

The <browser:tool> directive

  Status

  Author

    JimFulton, AnthonyBaxter

  Background

    The current site management interface has many and varied kinds
    of things you can add, both utilities and services. At the moment,
    the interface is not task-oriented - a site manager doesn't care
    whether something is a utility or a service, they just want to add
    a database adapter.

    For historical (CMF compatible) reasons we'll call these things Tools.
    
  Proposal
  
    We create a new <browser:tool> directive, to allow the definition of
    tool types. A couple of simple examples to illustrate::
    
        <browser:tool
            interface="zope.app.interfaces.rdb.IZopeDatabaseAdapter"
            title="Database Adapters"
            description="Database Adapters provide connectivity
                         to external relational databases"
        />

        <browser:tool
            interface="zope.app.interfaces.catalog.Catalog 
                       zope.app.interfaces.services.service.ILocalUtility"
            title="Catalogs"
            description="Catalogs allow the indexing and searching
                         of objects in the ZODB"
        />
        

    This allows us to automatically generate views in the site manager to
    show tools of a given type, to compute a list of tool types (along with
    some descriptive text), and to build an add screen for a given tool type.
    
    The add screen will provide a list of factories that implement the
    interface for the selected tool - this requires the refactoring to
    manage interfaces via the Utility service.

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TheBrowserToolDirective

From shane at zope.com  Mon Feb  9 14:15:30 2004
From: shane at zope.com (Shane Hathaway)
Date: Mon Feb  9 14:16:07 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <20040209111821.3f2c3f7e.casey@zope.com>
References: <20040208203643.GD1723@slinkp.com>
	<20040209111821.3f2c3f7e.casey@zope.com>
Message-ID: <Pine.LNX.4.50.0402091338130.1859-100000@shane.zope.com>

On Mon, 9 Feb 2004, Casey Duncan wrote:

> To me this sort of thing is like inline styles in HTML. Do I ever use
> inline styles? Yes I do, but very rarely and (hopefully) only when there
> is no other effective way to do what I want with the stylesheet (perhaps
> too dynamic), or I just plain can't change the stylesheet (or the
> document <head></head>). Do I feel a little dirty when I decide to use
> them? Yes. Sometimes I use them temporarily just to sketch something,
> knowing that I will create a stylesheet and do it the "right way" later.

Inline code is attractive because it lets you accomplish a task without
switching context.  Inline code is unmanageable, however, because it
allows you to specify arbitrary complexity in an anonymous code block.  
In general, complex things need a name in order to be manageable.

A possible compromise is to make it easy to move inline code to a Python
module.  In fact, maybe moving inline code to a module could be automated.  
That way, you might not even have to feel dirty when you write inline
code.

Further, one way to make inline code portable is to treat inline code as a
module, rather than as a collection of anonymous code blocks.  For
example:

<html>
<head><title>Shane's Example</title>
<script type="text/server-python">
import time
def showtime():
    return time.asctime()
</script>
</head>
<body>
Date and time: <span tal:content="code/showtime">(time)</span>.
</body>
</html>

An automated procedure could move that snippet to a library called
"shanesexample" and transform the script tag to:

<script type="text/server-python" src="library/shanesexample" />

The module "shanesexample" would be obvious:

import time
def showtime():
    return time.asctime()


Another way to make the snippets portable, though messier, is to require
that all scripts have a name.  For example:

<body>
Date and time: 
<script type="text/server-python" name="showtime">
import time
print time.asctime()
</script>.
</body>

This is much less portable because the module representation would have to
munge the code.  The converted code would have to be indented, 
and somehow it has to collect the output of print statements and 
return the results:

def showtime():
    import time
    print time.asctime()
    return print_collector()  # Yuck

That's similar to the transformation Zope 2 does to Python scripts.

Shane

From stuart at stuartbishop.net  Mon Feb  9 19:30:41 2004
From: stuart at stuartbishop.net (Stuart Bishop)
Date: Mon Feb  9 19:31:32 2004
Subject: [Zope3-dev] Re: CVS: Zope3/src/zope/app/browser/skins/rotterdam -
	zope3.css:1.28
In-Reply-To: <40274E44.4050504@weitershausen.de>
References: <200402090107.i1917e8f004800@cvs.zope.org>
	<40274E44.4050504@weitershausen.de>
Message-ID: <5B8701D0-5B60-11D8-8D61-000A95A06FC6@stuartbishop.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 09/02/2004, at 8:09 PM, Philipp von Weitershausen wrote:

> Anthony Baxter wrote:
>> -    scrollbar-3dlight-color: #336699;
>> -    scrollbar-shadow-color: #336699;
>> +    scrollbar-3dlight-color: #369;
>> +    scrollbar-shadow-color: #369;
>
> Maybe I'm not too familiar with the CSS spec, but is this a unique 
> description of an RGB colour? Even if it is, I personally would prefer 
> the full RRGGBB colour for easier human interpretation...

Not all browsers honor 3 character RGB specs (I think IE 5.0 was
the culprit, don't know if IE 5.5 & 6 fix this). It *is*
valid though:
	http://www.w3.org/TR/REC-CSS2/syndata.html#color-units

- --  
Stuart Bishop <stuart@stuartbishop.net>
http://www.stuartbishop.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFAKCY5AfqZj7rGN0oRAnRlAKCV8zFoiT590pFyKAQ6OnD2MbiYFACfT7sW
0O3PrvySps77xrxnRfzbKp4=
=UDik
-----END PGP SIGNATURE-----


From anthony at interlink.com.au  Mon Feb  9 20:42:35 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Mon Feb  9 20:42:37 2004
Subject: [Zope3-dev] best way to deal with dependency errors
Message-ID: <20040210014235.8826625ADA0@bonanza.off.ekorp.com>


At the moment if you try to delete a registered service or utility,
you get a system error. The traceback shows a dependency error on
the registration object. This could be handled by one of two ways:

before deleting, auto-delete the registration(s)
or
make the delete code catch dependencyerror and present a nice
message. 

Which is preferred? Or both?



From anthony at interlink.com.au  Mon Feb  9 22:50:21 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Mon Feb  9 22:51:02 2004
Subject: [Zope3-dev] apidoc (and notfound) break the introspector 'modify'
	button
In-Reply-To: <200402092043.15362.stephan.richter@tufts.edu> 
Message-ID: <20040210035021.7945A25ADA0@bonanza.off.ekorp.com>


At the moment, the 'introspector' modify button gives an error, 
AttributeError: 'Implements' object has no attribute 'names' 
from line 184 of zope/app/introspector.py

Modifying the code like so:

--- introspector.py     21 Nov 2003 17:10:44 -0000      1.19
+++ introspector.py     10 Feb 2004 03:34:19 -0000
@@ -181,6 +181,9 @@
         results = []
         iservice = getService(self.context, Interfaces)
         for id, interface in iservice.items(base=base):
+            if not hasattr(interface, 'names'):
+                print "no names", interface
+                continue
             if base in interface.__bases__ and not interface.names():
                 results.append(interface)
         results.sort()

produces the following output:

no names <implementedBy zope.products.apidoc.zcmlmodule.Directive> 
no names <implementedBy zope.products.apidoc.utilitymodule.Utility> 
no names <implementedBy zope.products.apidoc.APIDocumentation> 
no names <implementedBy zope.products.apidoc.servicemodule.Service> 
no names <implementedBy zope.products.apidoc.classmodule.ClassModule> 
no names <implementedBy zope.products.apidoc.servicemodule.Service> 
no names <implementedBy zope.products.apidoc.utilitymodule.Utility> 
no names <implementedBy zope.products.apidoc.utilitymodule.UtilityModule> 
no names <implementedBy zope.products.apidoc.zcmlmodule.ZCMLModule> 
no names <implementedBy zope.products.apidoc.viewmodule.ViewModule> 
no names <implementedBy zope.publisher.interfaces.NotFound> 


Looking further - the above are all of type 
zope.interface.declarations.Implements
while everything else is of type
zope.interface.interface.InterfaceClass

The error is because Implements doesn't have a 'names' method.

I'm not sure if it's the introspector or the code doing the 
provideInterface that's doing the wrong thing here.

Anyone?


From bjorn at exoweb.net  Mon Feb  9 23:20:51 2004
From: bjorn at exoweb.net (Bjorn Stabell)
Date: Mon Feb  9 23:25:19 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
Message-ID: <223FDE230D02BA47BC04261D5B0F91F50152F5@ntbox.backup-exoweb>

Hi,

[ Casey's example ]

Well, the Hapless guy is in deep shit anyways.  Even if he didn't see
the Python code, it'll still be there, under the hood.  He wouldn't be
able to change it.  If he didn't want to change it, he could leave it as
it is, it doesn't matter if it is in the HTML or if it's a separate
method.

I do understand and appreciate the concern about separating presentation
from code, but I think reducing the learning curve is the most important
factor in achieving market share, and without market share there is no
long-term future for Zope.  Separating presentation from code is vital
for big projects and products, and just a pain in the butt for small
hobby projects and for prototyping; we need to cater to both.

I was reading The Art of Unix Programming by ERS
http://www.faqs.org/docs/artu/, especially what he says about the Unix
philosophy to design and modularity struck me as very true.  It had me
wishing Zope could be simpler, more modular, with clearer (fewer?)
layers.  Especially the "transparency" and "discoverability" parts of
Zope are not very ideal.  I'm hoping Zope 3 will be much better.

To me, the presentation/code separation is the argument against DTML and
for ZPT as well.  DTML was simple, or at least had the potential to be
if it was even more Python-esque and was less "magical".  ZPT adds
another layer of complexity by encoding everything into attributes,
making the logic of your program incredibly complex to track by making
it hard to visually distinguish HTML from code, and by introducing a
whole new "attribute programming concept" that doesn't support common
programming constructs such as if-then (the test-method is such a
kludge).

The benefit of ZPT was supposed to be that you can have HTML programmers
do HTML programming, whereas coders do coding.  In dynamic sites, the
main template is often hand-coded anyways; and you often only need one
of it, so you can have your coder copy-paste (or more often recreate)
the HTML code that the designer made into the template.  That one
template often has very complex logic which is further made more complex
if encoded in ZPT.  ZPT templates are, in my experience, much more
verbose than DTML templates.  I think we bought a small benefit
(slightly more HTML editor-friendly templates) for a big price (more
complex templates).

Maybe this is not common, but in my experience, designers make great
designs in PSD, and they can transfer it to HTML.  But they aren't very
good at HTML/CSS, their HTML usually sucks.  Our coders, however, are
excellent at it.  HTML/CSS is more akin to coding than it is to design;
you need a programmer's mindset to do it to a high quality, and
CMS-driven sites need a high quality master template.

Bye,
-- 
Bjorn

From jim at zope.com  Mon Feb  9 23:34:23 2004
From: jim at zope.com (Jim Fulton)
Date: Mon Feb  9 23:41:57 2004
Subject: [Zope3-dev] Re: [Zope3-checkins]
	CVS:	Zope3/src/zope/app/browser/services
	- error.zcml:1.1	configure.zcml:1.81 error.py:1.8
In-Reply-To: <20040209105141.E05BD25ADA2@bonanza.off.ekorp.com>
References: <20040209105141.E05BD25ADA2@bonanza.off.ekorp.com>
Message-ID: <40285F4F.5060504@zope.com>

Anthony Baxter wrote:
>>>>Stephan Richter wrote
>>
>>I consider this not to be a good thing. One of the annoying things    
>>about the Zope 2 tabs was that there were usually more general tabs   
>>that applied to all objects than specific ones. Please let's not      
>>repeat this for Zope 3.                                               
> 
> 
> Spot polling of everyone here (including Jim) was that this was a good
> thing, not a bad thing. The Errors tab is almost always useful.

Besides which, the errors link is not a tab.

Developers definately want this to be handy.  Perhaps we'll
eventually arrange the authorization data so that programmers
won't see this.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Mon Feb  9 23:57:22 2004
From: jim at zope.com (Jim Fulton)
Date: Mon Feb  9 23:58:01 2004
Subject: [Zope3-dev] Issue 124 in the collector.
In-Reply-To: <20040209113519.GA28560@smarties.nutellux.ath.cx>
References: <20040209113519.GA28560@smarties.nutellux.ath.cx>
Message-ID: <402864B2.4010508@zope.com>

Nicolas ?vrard wrote:
> Hello everyone,
> 
> I've met the issue 124 from the collector again but I found a way around
> this issue.

AFAICT, this bug has been fixed.

> The Python you're using when running zope3 should have
> sys.defaultencoding set to 'utf' and not 'ascii'.

Absolutely, positively not!

We will not change the default encoding in Zope 3.  This would
be a bug magnet.

Conversion to and from unicode is done by the publishing
layer.  Application code should always deal with unicode.
Application code should almost never encode or decode strings.
If it does, it needs to specify an encoding.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Tue Feb 10 00:17:10 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 10 00:17:52 2004
Subject: [Zope3-dev] Re: [ZODB-Dev] Is anyone using persistent modules at
	the moment?
In-Reply-To: <1076338814.21762.22.camel@localhost.localdomain>
References: <4026BAA1.8080408@zope.com>
	<1076338814.21762.22.camel@localhost.localdomain>
Message-ID: <40286956.8000303@zope.com>

Jeremy Hylton wrote:
> On Sun, 2004-02-08 at 17:39, Jim Fulton wrote:
> 
>>I'm thinking of breaking them for a while and not taking the time to fix them,
>>assuming that no one is actually using them.
> 
> 
> I'm not using them.  Are you planning to break them in Zope or ZODB?

That was a poor choice of words on my part.  Let me put it this way,
I'm thinking of making them a low priority for a while.  I want to push
for getting a Zope 3 1.0 out ASAP and I'm ready to reduce features,
including through the web development, which is in a rather experimental
state at this point.  We will make TTW development work, but after 1.0.

Jim


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From dev at projekt01.ch  Tue Feb 10 03:46:37 2004
From: dev at projekt01.ch (Roger ineichen)
Date: Tue Feb 10 03:47:46 2004
Subject: AW: [Zope3-dev] best way to deal with dependency errors
In-Reply-To: <20040210014235.8826625ADA0@bonanza.off.ekorp.com>
Message-ID: <000401c3efb2$6606ba80$1e63a8c0@projekt01.local>

> Auftrag von Anthony Baxter wrote
> 
> At the moment if you try to delete a registered service or 
> utility, you get a system error. The traceback shows a 
> dependency error on the registration object. This could be 
> handled by one of two ways:
> 
> before deleting, auto-delete the registration(s)
> or
> make the delete code catch dependencyerror and present a nice 
> message. 
> 
> Which is preferred? Or both?

I whould prefere a message which must be commited.
That reminds you what's really going on.

Regards 
Roger Ineichen
> 
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org http://mail.zope.org/mailman/listinfo/zope3-dev
> 


From jim at zope.com  Tue Feb 10 04:38:26 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 10 04:39:09 2004
Subject: [Zope3-dev] best way to deal with dependency errors
In-Reply-To: <20040210014235.8826625ADA0@bonanza.off.ekorp.com>
References: <20040210014235.8826625ADA0@bonanza.off.ekorp.com>
Message-ID: <4028A692.2010608@zope.com>

Anthony Baxter wrote:
> At the moment if you try to delete a registered service or utility,
> you get a system error. The traceback shows a dependency error on
> the registration object. This could be handled by one of two ways:
> 
> before deleting, auto-delete the registration(s)
> or
> make the delete code catch dependencyerror and present a nice
> message. 
> 
> Which is preferred? Or both?

Neither. :)

I want a more general solution. I'm willing to live with the current
blight until that happens, especially since I'd like to get rid
(or redo) the dependency framework soon.

Here's the issue: when we generate an event, there may be more than
one subscriber that has an issue with it. There needs to be a way of
resolving these issues and the code generating the event shouldn't
be responsible for resolving the issues specifically, although there
should be a general way for it to do so.

The thing that makes it hard is that we want to be able to collect
multiple issues.  Exceptions don't work very well for this, unless
there is something willing to collect them together.

One idea that Steve and I came up with was to generate tentative events
to collect issues. Something like:

   # publish a tentative event
   event = Tentative(ObjectRemovedEvent(ob))
   publish(event)
   if event,issues:
      # There were issues, do something
      ....

   # Now that we've dealt with the issues, publish the event
   publish(event.event)

If we want to raise issues, we create two subscribers. One subscriber
subscribes to tentative events and one subscribes to normal events.
The tentative event subscribers can add issues to the event to be resolved:

   def notify_tentative_remove(tentative_event):
      real_event = tentative_event.event
      if has_dependents(event.object):
          tentative_event.addIssue(DependencyIssue(event.object))


This seems rather complicated for the code that generates events,
especially since, I suppose, it could, potentially, apply to most events.

Another possibility is to provide a specialized event channel that
can help with the tentative events.  The application code would just publish
the normal event. The channel gets the event and sends a tentative event
to it's subscribers. If there are no issues it sends the regular event.

If there are issues, the event channel could just raise a special
exception (e.g. EventRejected).  The exception could contain the issues.
At that point, the application code can catch the exception
and try to deal with the issues.  How would the application code deal with
the issues?  Well, in a number of ways. First, let's assume that EventRejected
exceptions have event and issues attributes.  The issues attribute is an iterable
of issues.

We can suppose some properties of issues:

- We can display them by displaying views of them

- Some issues might have (or be adaptable to objects that have) a
   reolve method.  If we have a resolve method, we can call it to resolve the
   issue.

- Some issues might require confirmation. If this is the case, the user
   should be asked to confirm the action necessary to resolve the issue.
   if this is the case, the application should display the issue to the user
   and get them to confirm it before calling the fixup method.

- Some issues may be unresolvable.  I'm not sure we should allow this.
   Perhaps this could be useful in the case of issues that can't be simply
   resolved but that could be resolved through some more involved action
   by the user.  This is a little bit risky, as you can end up in a position
   in which you can't resolve an issue and can't make progress.

If all of the issues are resolvable without confirmation, then the event
channel can just resolve them.  I suppose that if one of the events are
not resolveable, the channel could raise a different exception
(e.g. EventError) that isn't caught by the app.  In that case, the
app only needs to worry about confirmation.

So, careful application code might look something like this:

    try:
       publish(ObjectRemovedEvent(ob))
    except EventRejected, exc:
       # we have some issues that can be resolved, but these
       # need to be confirmed.  We'll check to see if the user has
       # confirmed the issues.  We'll call a helper view that checks
       # this for us:
       if getViewProviding(exc, request, IVerifyConfirmation):
           # The user has said OK, do it. Publish a confirmed
           # event:
           publish(ConfirmedEvent(ObjectRemovedEvent(ob), exc.issues)
       else:
           # Raise a confirmation exception that, when viewed displays
           # a conformation message and returns to the request URL.
           raise ConfirmationRequired(exc)

The ConfirmationRequired exception has a view that:

   - Displays the issues and a confirmation button

   - Includes hidden fields that identify the issue.
     This is needed to make sure that we have confirmed all
     of the same issues when the application is reexecuted.

The IVerifyConfirmation view compares the information in the hidden
request data (setup by the ConfirmationRequired view) with the issues
in the exception.to make sure that all of the issues in the esception
have been confirmed.

When the event channnel gets a ConfirmedEvent, it:

   - Sends a tentative event to its subscribers, and collects all of the
     issues.

   - Compares the issues collected with the issues passed to it.

     o If the issues are the same, it knows that they have been confirmed
       and calls resolve on each of them

     o Otherwise, it raises EventRejected.

If the application doesn't catch the exception, then the exception will
be displayed to the user.  In doing so it will display the issues.
It will display the issues with a different view than the one used for
confirmations. The issue views could provide UIs or links to UIs for resolving
the issues.  In this way, even if the application doesn't handle the issues,
the issues could lead the user to take actions that will resolve the issues.
Having done so, the user can then redo the application action, which should
succeed.

Whew!  But I think this is workable. :)

Thoughts?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From request at global-submit.com  Tue Feb 10 08:17:29 2004
From: request at global-submit.com (request@global-submit.com)
Date: Tue Feb 10 08:17:33 2004
Subject: [Zope3-dev] Regarding: mail.zope.org/pipermail/zope3-dev/
Message-ID: <200402101317.IAA13241@sg1.global-submit.com>

Hello,

This e-mail has been sent to inform you that your 
web site URL has been submitted to our search engine
database. This is the URL that will be added.

    URL : mail.zope.org/pipermail/zope3-dev/
   DATE : 02/10/2004 8:17:29
IP ADDR : Unknown IP. User had used an automated software for url submission

In order to complete this request we require that you 
click on the web site link below. This will confirm
that you do wish to be added to our search engine.

http://www.global-submit.com/confirm.cgi?T887458R569975

If you feel that you received this message in error
or you did not have your web site submitted to our
search engine, please click on the link below. We 
will make every effort to make sure that you are 
no longer bothered by this automated system. 

http://www.global-submit.com/clipout.cgi?T887458R569975

Thank you and please have a nice day

Global-Submit.com tech Staff
www.global-submit.com
1 819 571 4943






From casey at zope.com  Tue Feb 10 09:25:40 2004
From: casey at zope.com (Casey Duncan)
Date: Tue Feb 10 09:28:25 2004
Subject: [Zope3-dev] Re: [ZODB-Dev] Is anyone using persistent modules at
	the moment?
In-Reply-To: <40286956.8000303@zope.com>
References: <4026BAA1.8080408@zope.com>
	<1076338814.21762.22.camel@localhost.localdomain>
	<40286956.8000303@zope.com>
Message-ID: <20040210092540.63c10b07.casey@zope.com>

On Tue, 10 Feb 2004 00:17:10 -0500
Jim Fulton <jim@zope.com> wrote:

> Jeremy Hylton wrote:
> > On Sun, 2004-02-08 at 17:39, Jim Fulton wrote:
> > 
> >>I'm thinking of breaking them for a while and not taking the time to
> >fix them,>assuming that no one is actually using them.
> > 
> > 
> > I'm not using them.  Are you planning to break them in Zope or ZODB?
> 
> That was a poor choice of words on my part.  Let me put it this way,
> I'm thinking of making them a low priority for a while.  I want to
> push for getting a Zope 3 1.0 out ASAP and I'm ready to reduce
> features, including through the web development, which is in a rather
> experimental state at this point.  We will make TTW development work,
> but after 1.0.

+1 (But you knew that ;^)

-Casey

From casey at zope.com  Tue Feb 10 09:49:47 2004
From: casey at zope.com (Casey Duncan)
Date: Tue Feb 10 09:52:50 2004
Subject: [Zope3-dev] best way to deal with dependency errors
In-Reply-To: <4028A692.2010608@zope.com>
References: <20040210014235.8826625ADA0@bonanza.off.ekorp.com>
	<4028A692.2010608@zope.com>
Message-ID: <20040210094947.14b728bf.casey@zope.com>

On Tue, 10 Feb 2004 04:38:26 -0500
Jim Fulton <jim@zope.com> wrote:

[..]
> The ConfirmationRequired exception has a view that:
> 
>    - Displays the issues and a confirmation button
> 
>    - Includes hidden fields that identify the issue.
>      This is needed to make sure that we have confirmed all
>      of the same issues when the application is reexecuted.

This is an interesting pattern. Interactive exception views. Actually I
think that in a well-mannered application, most exceptions should be
interactive in some way.

In general application exception views are a way for the app to express
an "Oh crap, I'm too stupid to figure this out for myself, what should I
do now?".

A simple example would be a transitory error, like lets say a conflict
that recurs after 3 retrys. It could perhaps have a "Try Again" button
that lets the user replay the request.

Or let's say a user tried to delete a locked item. If the user can
unlock the object then the exception view could have a "Delete Anyway"
button that unlocks the object and retrys the delete.

Or let's say you are adding a new item to a folder and you choose a name
that already exists. The exception view could provide a form where the
user can choose a different name.

All of these assume some way to store enough info about the previous
request to replay it (sometimes with modifications). There are of course
many ways to do this, but it would be nice to have this automated by the
framework in some way since it is a common operation.

We may want to think about not limiting this sort of functionality to
events. Otherwise I see myself using events just to get this nice
"resolve issues" functionality even if I wouldn't otherwise use them.
OTOH, maybe that should be a reason to use events.

-Casey

From shane at zope.com  Tue Feb 10 10:27:37 2004
From: shane at zope.com (Shane Hathaway)
Date: Tue Feb 10 10:27:45 2004
Subject: [Zope3-dev] Inline code
In-Reply-To: <Pine.LNX.4.50.0402091338130.1859-100000@shane.zope.com>
References: <20040209111821.3f2c3f7e.casey@zope.com>
	<Pine.LNX.4.50.0402091338130.1859-100000@shane.zope.com>
Message-ID: <Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>

On Mon, 9 Feb 2004, Shane Hathaway wrote:

> Further, one way to make inline code portable is to treat inline code as a
> module, rather than as a collection of anonymous code blocks.  For
> example:
> 
> <html>
> <head><title>Shane's Example</title>
> <script type="text/server-python">
> import time
> def showtime():
>     return time.asctime()
> </script>
> </head>
> <body>
> Date and time: <span tal:content="code/showtime">(time)</span>.
> </body>
> </html>

I'm surprised I received no response on this.  I'll help you guys start
debating. :-)

Pros:

- You can write code inline.  It would replace the need for complex
expressions.

- Unlike the current script tag, moving the inline code to a separate
module is always straightforward.  Once it's in a separate module, you get
all the manageability of Python modules.

- Unlike the current script tag, we don't have to manipulate print
statements.  In fact, for the whole story to work, we might not allow
print statements (except perhaps as a debugging tool.)

Cons:

- It's not like Javascript; there is no "document.write()" equivalent.  
It's a lot more like CSS, since CSS styles apply to the whole document 
regardless of what part of the document defines them.

Hmm, I can't think of any more cons. :-)  This seems like a big win 
overall.  Maybe we could try this in Zope 2 first.

Shane

From contact_tonico at yahoo.de  Tue Feb 10 10:52:45 2004
From: contact_tonico at yahoo.de (Tonico Strasser)
Date: Tue Feb 10 10:41:03 2004
Subject: [Zope3-dev] Re: Inline code
In-Reply-To: <Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
References: <20040209111821.3f2c3f7e.casey@zope.com>	<Pine.LNX.4.50.0402091338130.1859-100000@shane.zope.com>
	<Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
Message-ID: <4028FE4D.1090400@yahoo.de>

Shane Hathaway wrote:
> I'm surprised I received no response on this.  I'll help you guys start
> debating. :-)
> 
> Pros:
> 
> - You can write code inline.  It would replace the need for complex
> expressions.
> 
> - Unlike the current script tag, moving the inline code to a separate
> module is always straightforward.  Once it's in a separate module, you get
> all the manageability of Python modules.
> 
> - Unlike the current script tag, we don't have to manipulate print
> statements.  In fact, for the whole story to work, we might not allow
> print statements (except perhaps as a debugging tool.)
> 
> Cons:
> 
> - It's not like Javascript; there is no "document.write()" equivalent.  
> It's a lot more like CSS, since CSS styles apply to the whole document 
> regardless of what part of the document defines them.
> 
> Hmm, I can't think of any more cons. :-)  This seems like a big win 
> overall.  Maybe we could try this in Zope 2 first.

I'm a scripter, I like it. I'm dealing a lot with ugly expressions in ZPT.

Tonico


From contact_tonico at yahoo.de  Tue Feb 10 10:52:45 2004
From: contact_tonico at yahoo.de (Tonico Strasser)
Date: Tue Feb 10 10:41:15 2004
Subject: [Zope3-dev] Re: Inline code
In-Reply-To: <Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
References: <20040209111821.3f2c3f7e.casey@zope.com>	<Pine.LNX.4.50.0402091338130.1859-100000@shane.zope.com>
	<Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
Message-ID: <4028FE4D.1090400@yahoo.de>

Shane Hathaway wrote:
> I'm surprised I received no response on this.  I'll help you guys start
> debating. :-)
> 
> Pros:
> 
> - You can write code inline.  It would replace the need for complex
> expressions.
> 
> - Unlike the current script tag, moving the inline code to a separate
> module is always straightforward.  Once it's in a separate module, you get
> all the manageability of Python modules.
> 
> - Unlike the current script tag, we don't have to manipulate print
> statements.  In fact, for the whole story to work, we might not allow
> print statements (except perhaps as a debugging tool.)
> 
> Cons:
> 
> - It's not like Javascript; there is no "document.write()" equivalent.  
> It's a lot more like CSS, since CSS styles apply to the whole document 
> regardless of what part of the document defines them.
> 
> Hmm, I can't think of any more cons. :-)  This seems like a big win 
> overall.  Maybe we could try this in Zope 2 first.

I'm a scripter, I like it. I'm dealing a lot with ugly expressions in ZPT.

Tonico


From casey at zope.com  Tue Feb 10 10:41:57 2004
From: casey at zope.com (Casey Duncan)
Date: Tue Feb 10 10:44:41 2004
Subject: [Zope3-dev] Re: Inline code
In-Reply-To: <Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
References: <20040209111821.3f2c3f7e.casey@zope.com>
	<Pine.LNX.4.50.0402091338130.1859-100000@shane.zope.com>
	<Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
Message-ID: <20040210104157.241a12a5.casey@zope.com>

On Tue, 10 Feb 2004 10:27:37 -0500 (EST)
Shane Hathaway <shane@zope.com> wrote:

> On Mon, 9 Feb 2004, Shane Hathaway wrote:
> 
> > Further, one way to make inline code portable is to treat inline
> > code as a module, rather than as a collection of anonymous code
> > blocks.  For example:
> > 
> > <html>
> > <head><title>Shane's Example</title>
> > <script type="text/server-python">
> > import time
> > def showtime():
> >     return time.asctime()
> > </script>
> > </head>
> > <body>
> > Date and time: <span tal:content="code/showtime">(time)</span>.
> > </body>
> > </html>
> 
[..]
> Hmm, I can't think of any more cons. :-)  This seems like a big win 
> overall.  Maybe we could try this in Zope 2 first.

I personally would prefer the "python library" approach. My templates
are already ugly enough as it is.

And just to let it be known again, I would really prefer a world where
one wrote python and html (or xml) and the former transformed the
latter. The latter would not have any scripting or additional markup in
it what so ever. So that makes me naturally oppose anything that mixes
more logic into the template.

-Casey

From pw_lists at slinkp.com  Tue Feb 10 11:39:46 2004
From: pw_lists at slinkp.com (Paul Winkler)
Date: Tue Feb 10 11:39:52 2004
Subject: [Zope3-dev] Re: Inline code
In-Reply-To: <Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
References: <20040209111821.3f2c3f7e.casey@zope.com>
	<Pine.LNX.4.50.0402091338130.1859-100000@shane.zope.com>
	<Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
Message-ID: <20040210163946.GC2026@slinkp.com>

On Tue, Feb 10, 2004 at 10:27:37AM -0500, Shane Hathaway wrote:
> On Mon, 9 Feb 2004, Shane Hathaway wrote:
> 
> > Further, one way to make inline code portable is to treat inline code as a
> > module, rather than as a collection of anonymous code blocks.  For
> > example:
> > 
> > <html>
> > <head><title>Shane's Example</title>
> > <script type="text/server-python">
> > import time
> > def showtime():
> >     return time.asctime()
> > </script>
> > </head>
> > <body>
> > Date and time: <span tal:content="code/showtime">(time)</span>.
> > </body>
> > </html>
> 
> I'm surprised I received no response on this.  I'll help you guys start
> debating. :-)

OK fine, I can't resist ... debate ensues :-)
 
> Pros:
> 
> - You can write code inline.  It would replace the need for complex
> expressions.

*shrug*  give me TTW libraries and I'd never need this.
i guess some people would like it.
 
> - Unlike the current script tag, moving the inline code to a separate
> module is always straightforward. 

Ah, my favorite horse to flog. This is *really* important.
If we're determined to give people mess-enabling tools,
we must take steps to ease the burden on the guy who gets
to clean it up later!

This means that you should never have to learn one way
of doing something in inline python, another way in
Script (Python), yet another way in modules.
Zope 2 accumulated a number of these inconsistencies
and they are very trying for a newcomer.

We all know this, otherwise nobody would have cared to
replace "here" with "context". Let's apply that principle
everywhere. Therefore, no print statements, please.

> Once it's in a separate module, you get
> all the manageability of Python modules.
 
> - Unlike the current script tag, we don't have to manipulate print
> statements.  In fact, for the whole story to work, we might not allow
> print statements (except perhaps as a debugging tool.)

> Cons:
> 
> - It's not like Javascript; there is no "document.write()" equivalent.

What does document.write() allow that tal/content and tal/replace does
not? I have done very little javascript.


-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's THE WHIZZING SKULL!
(random hero from isometric.spaceninja.com)

From shane at zope.com  Tue Feb 10 11:55:45 2004
From: shane at zope.com (Shane Hathaway)
Date: Tue Feb 10 11:58:39 2004
Subject: [Zope3-dev] Re: Inline code
In-Reply-To: <20040210163946.GC2026@slinkp.com>
References: <Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
	<20040210163946.GC2026@slinkp.com>
Message-ID: <Pine.LNX.4.50.0402101146230.9991-100000@shane.zope.com>

On Tue, 10 Feb 2004, Paul Winkler wrote:

> OK fine, I can't resist ... debate ensues :-)

I think it's a good thing to think about, and maybe we can even come to a 
consensus. ;-)

> > Pros:
> > 
> > - You can write code inline.  It would replace the need for complex
> > expressions.
> 
> *shrug*  give me TTW libraries and I'd never need this.
> i guess some people would like it.

This idea is designed to work seamlessly with libraries.  In theory, code
written in a template could be cut and pasted verbatim into a library.  

> > - Unlike the current script tag, moving the inline code to a separate
> > module is always straightforward. 
> 
> Ah, my favorite horse to flog. This is *really* important.
> If we're determined to give people mess-enabling tools,
> we must take steps to ease the burden on the guy who gets
> to clean it up later!

+1

> > Cons:
> > 
> > - It's not like Javascript; there is no "document.write()" equivalent.
> 
> What does document.write() allow that tal/content and tal/replace does
> not? I have done very little javascript.

Nothing at all, really.  The only difference is that scripters will be
required to write a function and call the function, which is better style
anyway.

Shane

From gary at modernsongs.com  Tue Feb 10 13:13:26 2004
From: gary at modernsongs.com (Gary Poster)
Date: Tue Feb 10 13:13:35 2004
Subject: [Zope3-dev] Inline code
In-Reply-To: <Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
References: <20040209111821.3f2c3f7e.casey@zope.com>	<Pine.LNX.4.50.0402091338130.1859-100000@shane.zope.com>
	<Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
Message-ID: <40291F46.4070407@modernsongs.com>

Do I understand correctly that in this scheme effectively each template 
page would have its own local module?

Gary

Shane Hathaway wrote:
> On Mon, 9 Feb 2004, Shane Hathaway wrote:
> 
> 
>>Further, one way to make inline code portable is to treat inline code as a
>>module, rather than as a collection of anonymous code blocks.  For
>>example:
>>
>><html>
>><head><title>Shane's Example</title>
>><script type="text/server-python">
>>import time
>>def showtime():
>>    return time.asctime()
>></script>
>></head>
>><body>
>>Date and time: <span tal:content="code/showtime">(time)</span>.
>></body>
>></html>
> 
> 
> I'm surprised I received no response on this.  I'll help you guys start
> debating. :-)
> 
> Pros:
> 
> - You can write code inline.  It would replace the need for complex
> expressions.
> 
> - Unlike the current script tag, moving the inline code to a separate
> module is always straightforward.  Once it's in a separate module, you get
> all the manageability of Python modules.
> 
> - Unlike the current script tag, we don't have to manipulate print
> statements.  In fact, for the whole story to work, we might not allow
> print statements (except perhaps as a debugging tool.)
> 
> Cons:
> 
> - It's not like Javascript; there is no "document.write()" equivalent.  
> It's a lot more like CSS, since CSS styles apply to the whole document 
> regardless of what part of the document defines them.
> 
> Hmm, I can't think of any more cons. :-)  This seems like a big win 
> overall.  Maybe we could try this in Zope 2 first.
> 
> Shane
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope3-dev
> 
> 

From shane at zope.com  Tue Feb 10 14:04:05 2004
From: shane at zope.com (Shane Hathaway)
Date: Tue Feb 10 14:04:15 2004
Subject: [Zope3-dev] Inline code
In-Reply-To: <40291F46.4070407@modernsongs.com>
References: <20040209111821.3f2c3f7e.casey@zope.com>
	<Pine.LNX.4.50.0402091338130.1859-100000@shane.zope.com>
	<Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
	<40291F46.4070407@modernsongs.com>
Message-ID: <Pine.LNX.4.50.0402101326280.9991-100000@shane.zope.com>

On Tue, 10 Feb 2004, Gary Poster wrote:

> Do I understand correctly that in this scheme effectively each template 
> page would have its own local module?

Yes.

However, I just came up with another issue.  Imagine if someone wrote the 
following:

<script type="text/server-python">
def getstuff():
    return '%s' % context.stuff
</script>

That script discreetly references the name "context".  If the name
"context" is available, the script can't be moved painlessly to another
module.  OTOH, if the name "context" is not available, the template has
two global namespaces: one for ZPT and one for Python code.  That's not
good.

Given the choices presented, here are my votes.

1. No inline code; rely on code in modules.  Also make it easy to write
modules TTW.

  +1

2. Allow inline code with print statements.  Also unify the TALES and
Python namespaces, making names like "context" available to inline code.  
(The status quo.)

  -1

3. Allow inline code, but no print statements.  Disassociate the TALES and
Python namespaces.  (Shane's suggestion.)

  +0

4. Drop ZPT and use scripts to do simple document transformation.  
(Casey's suggestion.  Similar to XMLC.)

  -0

Shane

From jeff at bottlerocket.net  Tue Feb 10 14:31:31 2004
From: jeff at bottlerocket.net (Jeffrey P Shell)
Date: Tue Feb 10 14:31:35 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <223FDE230D02BA47BC04261D5B0F91F50152F5@ntbox.backup-exoweb>
References: <223FDE230D02BA47BC04261D5B0F91F50152F5@ntbox.backup-exoweb>
Message-ID: <BAA3718F-5BFF-11D8-B781-003065415378@bottlerocket.net>

On Feb 9, 2004, at 9:20 PM, Bjorn Stabell wrote:
> To me, the presentation/code separation is the argument against DTML 
> and
> for ZPT as well.  DTML was simple, or at least had the potential to be
> if it was even more Python-esque and was less "magical".  ZPT adds
> another layer of complexity by encoding everything into attributes,
> making the logic of your program incredibly complex to track by making
> it hard to visually distinguish HTML from code, and by introducing a
> whole new "attribute programming concept" that doesn't support common
> programming constructs such as if-then (the test-method is such a
> kludge).

ZPT is not code to me.  It's templating.  It's HTML.  I treat it and 
think of it as such.  And it's an absolute f***ing joy.  I love it.  
I'm happy there's no if/else.  It fits the HTML and XML mindset (much 
better than XSLT), and gives me something that I can see in GoLive.  I 
have customers who can then edit their templates and modify the 
visuals.  I'm still the one responsible for working in the TAL 
statements, but the HTML guys I've worked with (of many different 
intelligences, tools, and backgrounds) have NOT minded it at all.

They hated DTML, because it would cause us to take a visual idea of 
theirs and rip it out into small modular chunks that could not be 
edited in a visual fashion.  And seemingly small changes would take up 
way too much time.

I love ZPT.

I'm hoping that Zope 3 does NOT cripple it for these customers, as I've 
outlined above.  I know ZPT will be full featured (I hope) in TTW 
development mode, but I want to ensure that my customers, who don't 
even fall under the 'scripter' hat, see their site as a whole and can 
continue to edit pages - including dynamic ones - with full macro 
expansion so that they (and I) can see the impact of changes for sites 
that have a small collection of dynamic pages among a lot of static 
ones.  I'll still be the one responsible for providing the public API 
for the site to use and putting the TAL/METAL markup in the target 
pages.  But it's not something that should require views and all that 
to be set up.

That's great for larger scale web applications, and something I've been 
wanting for a while - but I've been increasingly worried that I have a 
lot of customers who I won't be able to transition to Zope 3 easily 
because their sites don't necessarily fall totally in the area of the 
Scriptor (they'll do very little scripting, if any, themselves, and the 
heavy code is placed deeper in the system) nor are they really a web 
application with new Content objects, views, menus, all that stuff.  
I'll be the scripter for them, and a lot of my concerns revolve around 
the perception scripting for the smart-set in this situation is going 
to be difficult because we've stripped the scripter of any real power 
or semi-advanced tools in order to coddle someone we're afraid of 
scaring off.

> The benefit of ZPT was supposed to be that you can have HTML 
> programmers
> do HTML programming, whereas coders do coding.  In dynamic sites, the
> main template is often hand-coded anyways; and you often only need one
> of it, so you can have your coder copy-paste (or more often recreate)
> the HTML code that the designer made into the template.  That one
> template often has very complex logic which is further made more 
> complex
> if encoded in ZPT.  ZPT templates are, in my experience, much more
> verbose than DTML templates.  I think we bought a small benefit
> (slightly more HTML editor-friendly templates) for a big price (more
> complex templates).

I've had a huge benefit from ZPT.  Primarily because I can have other 
people make it look good, and it's a lot easier for me to keep it 
looking good because the general HTML structure is so well preserved 
when templating rules are added in.  This is aided by tools such as 
GoLive (which has an excellent WebDAV client) which lets me see the 
repercussions of my edits on sites with complex designs; while at the 
same time I can use BBEdit or VIM for sites and pages I make myself.  
Do some templates get really complex so that hand coding is needed to 
make most edits?  Yes.  But I can still see the effect of style sheets, 
table column spans, etc, in a way that makes sense to my HTML side.

Huge benefit.

And it's encouraged me to write better code that builds the data 
structures used in those pages, whereas in DTML (or some other 
language) I may have tried to build those data structures inside the 
template for expediency's sake.  Those data structure builders, playing 
the role of 'code-behind' (to use ASP.NET terms) then have the benefit 
of being cachable (caching the results of the built data structure 
while keeping the page dynamic and responsive to other events), 
reusable, refactorable, etc.

That's a huge benefit to me, and it helps keep the majority of my 
templates much simpler than their DTML counterparts.  Yes - you could 
code this way in DTML (and old Bobo/DTML code promoted this concept), 
but DTML in Zope 2 didn't promote it well, I felt - partially due to 
being hampered by lack of anything like Python Scripts until Zope 2.3, 
and then still held back by confusing namespace rules (which are kept 
very clear in TALES expressions).

> Maybe this is not common, but in my experience, designers make great
> designs in PSD, and they can transfer it to HTML.  But they aren't very
> good at HTML/CSS, their HTML usually sucks.  Our coders, however, are
> excellent at it.  HTML/CSS is more akin to coding than it is to design;
> you need a programmer's mindset to do it to a high quality, and
> CMS-driven sites need a high quality master template.

Some people would say the same about Postscript, and that by hand you 
can generate much better postscript than you can with a tool like 
Illustrator.

It didn't take too much work for me to eke good HTML out of GoLive.  
For the changes that my designers can't make themselves, I can still 
apply major changes in a fraction of the time it used to take with 
DTML.

I just may have lucked out with the people I get to work with.  But 
they don't know TAL.  However, they know enough to sidestep around it 
or keep an eye out for it using split code/source views.


From jeff at bottlerocket.net  Tue Feb 10 14:36:20 2004
From: jeff at bottlerocket.net (Jeffrey P Shell)
Date: Tue Feb 10 14:36:23 2004
Subject: [Zope3-dev] Re: Inline code
In-Reply-To: <20040210104157.241a12a5.casey@zope.com>
References: <20040209111821.3f2c3f7e.casey@zope.com>
	<Pine.LNX.4.50.0402091338130.1859-100000@shane.zope.com>
	<Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
	<20040210104157.241a12a5.casey@zope.com>
Message-ID: <66E5ADAB-5C00-11D8-B781-003065415378@bottlerocket.net>


On Feb 10, 2004, at 8:41 AM, Casey Duncan wrote:

> On Tue, 10 Feb 2004 10:27:37 -0500 (EST)
> Shane Hathaway <shane@zope.com> wrote:
>
>> On Mon, 9 Feb 2004, Shane Hathaway wrote:
>>
>>> Further, one way to make inline code portable is to treat inline
>>> code as a module, rather than as a collection of anonymous code
>>> blocks.  For example:
>>>
>>> <html>
>>> <head><title>Shane's Example</title>
>>> <script type="text/server-python">
>>> import time
>>> def showtime():
>>>     return time.asctime()
>>> </script>
>>> </head>
>>> <body>
>>> Date and time: <span tal:content="code/showtime">(time)</span>.
>>> </body>
>>> </html>
>>
> [..]
>> Hmm, I can't think of any more cons. :-)  This seems like a big win
>> overall.  Maybe we could try this in Zope 2 first.
>
> I personally would prefer the "python library" approach. My templates
> are already ugly enough as it is.
>
> And just to let it be known again, I would really prefer a world where
> one wrote python and html (or xml) and the former transformed the
> latter. The latter would not have any scripting or additional markup in
> it what so ever. So that makes me naturally oppose anything that mixes
> more logic into the template.

I've had nightmarishly bad experiences with such systems.  The 
transformation code for anything beyond basics became very difficult to 
maintain in a matter similar to inline.  I think ZPT are about as close 
to perfect as one gets.

I prefer building good data structures in Python code, and then trying 
to keep the TAL/TALES statements in my templates as clean as possible 
(not always possible, but often enough).

Which is why I'd prefer the Python Library approach.  Although I do 
like Shane's proposal, as it's easier to refactor/restructure inline 
script code (which sometimes is a benefit) into such a library.  That's 
been my problem with many HTML + inline_scripting engines - they're 
very very difficult to restructure into a more general purpose library.


From jeff at bottlerocket.net  Tue Feb 10 15:02:48 2004
From: jeff at bottlerocket.net (Jeffrey P Shell)
Date: Tue Feb 10 15:02:57 2004
Subject: [Zope3-dev] Re: Last chance to mess with the source layout of
	Zope 3
In-Reply-To: <4026DCD0.7050509@weitershausen.de>
References: <4026BF7B.3050407@zope.com> <4026DCD0.7050509@weitershausen.de>
Message-ID: <1958CE3E-5C04-11D8-B781-003065415378@bottlerocket.net>


On Feb 8, 2004, at 6:05 PM, Philipp von Weitershausen wrote:

>> In a separate note, I suggested a much flatter layout.  I suggested
>> getting rid of zope.app.browser (and the like) and 
>> zope.app.interafces.
>> I suggested that zope.app have top-level packages in it that are 
>> pretty
>> self-contained with their own interfaces.py and browser.py (and etc.).
>> A variation on this would be to provide separate UI packages
>> (e.g, zope.app.folder and zope.app.folderweb).
>
> +1 for self-contained packages inside zope.app.

+ 0

> -1 to zope.app.folderweb or similar

Agreed.  (on the -1)


From jeff at bottlerocket.net  Tue Feb 10 15:31:20 2004
From: jeff at bottlerocket.net (Jeffrey P Shell)
Date: Tue Feb 10 15:31:24 2004
Subject: [Zope3-dev] What is Core?
In-Reply-To: <c04vkh$r5p$1@sea.gmane.org>
References: <402573CA.9030409@zope.com>
	<200402071837.44347.srichter@cosmos.phy.tufts.edu>
	<c04vkh$r5p$1@sea.gmane.org>
Message-ID: <16395402-5C08-11D8-B781-003065415378@bottlerocket.net>

On Feb 8, 2004, at 2:28 AM, Michael Haubenwallner wrote:

> Stephan Richter wrote:
>> On Saturday 07 February 2004 18:24, Jim Fulton wrote:
>>> One possibility is to say that 1.0 (perhaps a different designation
>>> would be better) is really for those people who are already 
>>> delivering
>>> Zope 3 apps.  It emphasizes the things that work pretty well now,
>>> meaning core services and file-system-based developmen
>> Yes, I agree with that based on your previous message. I can always 
>> make a experimental TTW-enabled release, like "1.0+TTW" for people 
>> who want to try it and give feedback. Zope 3 1.0 will get a lot of 
>> attention, and I would love to use some of this momentum to get TTW 
>> development feedback. On the other hand I do not want to make the 
>> main release messy, late and unstable, so that people will look at it 
>> and say: What the hell is this?
>>
>
> Would it make sense to remove the TTW-management-interface from the 
> 'core' and into a product ? Could this product be used as an example 
> of how to write management products for zope3 ?

Alright - what is 'core'?  I remember typing up this question, but I 
don't know if I ever sent it.

I thought core was everything *but* zope.app.  zope.component, 
zope.publisher, etc - that was the core core.  Is that stuff now 
'sub-core?' (which is kindof hard to do ;).  Or is it the meta-core?

I just hear a lot of people batting the term 'core' around an awful lot 
these days.  Usually in terms of "maybe that shouldn't be in the core."

And I hope will also help us avoid the 'man, we really need to bust up 
zope.products' conversation if everything from 'zope.app' ends up in 
there.

Maybe 'ttw' should not necessarily be in 'zope.products', but as 
'zope.ttw'.  This changes some of the definitions of what those top 
level zope.* packages should be, but I think that's been shifting 
anyways.

Or maybe it's really time to start looking at component packaging, 
distribution, and installation issues, so that elements that could very 
well be part of the so-called 'core' can be distributed and installed 
on their own until they become part of the core.  Component Management 
is a pretty significant part of many component architectures, which 
includes installation as well as configuration.  We've got the 
configuration bit pretty much down, it seems, but adding and removing 
the actual software bits seems to be another matter.

I guess that's been one of the benefits of the magical 'Products' 
package of Zope 2.  You can refer to 'Products.PythonScripts', which is 
installed in /usr/local/zope/2.6.1/lib/python/Products; and refer to 
Products.SuperTemplates, which is installed in 
/home/jshell/projects/cust1/Products.

I don't like how this was used to install and deal with third party 
products - I'd prefer to keep our packages in our own top namespace (ie 
'bottlerocket.commerce' or 'bottlerocket.ticketing'), and I like that 
Zope 3 supports this (now that 'path' configuration is in the ZConfig 
setup).  However, I do like that Products.* was a system that allowed 
for packages like Page Templates to be distributed individually until 
they became part of the common distribution - in a way that was 
forwards compatible with their acceptance.


From pw_lists at slinkp.com  Tue Feb 10 16:25:09 2004
From: pw_lists at slinkp.com (Paul Winkler)
Date: Tue Feb 10 16:25:19 2004
Subject: [Zope3-dev] Inline code
In-Reply-To: <Pine.LNX.4.50.0402101326280.9991-100000@shane.zope.com>
References: <20040209111821.3f2c3f7e.casey@zope.com>
	<Pine.LNX.4.50.0402091338130.1859-100000@shane.zope.com>
	<Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
	<40291F46.4070407@modernsongs.com>
	<Pine.LNX.4.50.0402101326280.9991-100000@shane.zope.com>
Message-ID: <20040210212509.GE2026@slinkp.com>

On Tue, Feb 10, 2004 at 02:04:05PM -0500, Shane Hathaway wrote:
> On Tue, 10 Feb 2004, Gary Poster wrote:
> 
> > Do I understand correctly that in this scheme effectively each template 
> > page would have its own local module?
> 
> Yes.
> 
> However, I just came up with another issue.  Imagine if someone wrote the 
> following:
> 
> <script type="text/server-python">
> def getstuff():
>     return '%s' % context.stuff
> </script>
> 
> That script discreetly references the name "context".  If the name
> "context" is available, the script can't be moved painlessly to another
> module.

Erk. That's exactly the kind of impedance mismatch I was thinking of.

>  OTOH, if the name "context" is not available, the template has
> two global namespaces: one for ZPT and one for Python code.  That's not
> good.

Double-erk. I'd argue it's worse than the above mismatch.
 
> Given the choices presented, here are my votes.
> 
> 1. No inline code; rely on code in modules.  Also make it easy to write
> modules TTW.
> 
>   +1

 +1

Your #2 seems like several different things to me:

2a. Allow inline code with unified TALES & python namespaces,
and no print statements.

 -1.

 
> 2. Allow inline code with print statements.  Also unify the TALES and
> Python namespaces, making names like "context" available to inline code.  
> (The status quo.)
> 
>   -1

 -1

> 3. Allow inline code, but no print statements.  Disassociate the TALES and
> Python namespaces.  (Shane's suggestion.)
> 
>   +0

 -1

3b. Allow inline code, but no print statements, and unify the TALES
and Python namespaces ("context" et al).
(Paul's suggestion)

  +0 ... unless it could make sense for "context" to be portable
     to other TTW python code, which AFAICT would not make any
     sense for Python Libraries or persistent modules.

 
> 4. Drop ZPT and use scripts to do simple document transformation.  
> (Casey's suggestion.  Similar to XMLC.)
>   -0
> 

 -1. ZPT is not the template language for zope that should be first 
in line for being dropped ;-)
I doubt that anyone wants to rewrite all the existing ZPT
for z3 in this new paradigm.
 
For people that want to work this way, it would make a nice
add-on product.

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's PARA-WINO!
(random hero from isometric.spaceninja.com)

From edwardam at interlix.com  Tue Feb 10 16:26:46 2004
From: edwardam at interlix.com (Edward Muller)
Date: Tue Feb 10 16:26:58 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <223FDE230D02BA47BC04261D5B0F91F50152F5@ntbox.backup-exoweb>
References: <223FDE230D02BA47BC04261D5B0F91F50152F5@ntbox.backup-exoweb>
Message-ID: <1076448406.28167.95.camel@palin>

On Mon, 2004-02-09 at 22:20, Bjorn Stabell wrote:
[snip]

> I do understand and appreciate the concern about separating presentation
> from code, but I think reducing the learning curve is the most important
> factor in achieving market share, and without market share there is no
> long-term future for Zope.  Separating presentation from code is vital
> for big projects and products, and just a pain in the butt for small
> hobby projects and for prototyping; we need to cater to both.

Agreed.

> 
> I was reading The Art of Unix Programming by ERS
> http://www.faqs.org/docs/artu/, especially what he says about the Unix
> philosophy to design and modularity struck me as very true.  It had me
> wishing Zope could be simpler, more modular, with clearer (fewer?)
> layers.  Especially the "transparency" and "discoverability" parts of
> Zope are not very ideal.  I'm hoping Zope 3 will be much better.
> 
> To me, the presentation/code separation is the argument against DTML and
> for ZPT as well.  DTML was simple, or at least had the potential to be
> if it was even more Python-esque and was less "magical". 

At this point I consider DTML to be more "magical".

>  ZPT adds
> another layer of complexity by encoding everything into attributes,
> making the logic of your program incredibly complex to track by making
> it hard to visually distinguish HTML from code, and by introducing a
> whole new "attribute programming concept" that doesn't support common
> programming constructs such as if-then (the test-method is such a
> kludge).

There should be no core logic in ZPTs, it wasn't meant for that. Display
login is another thing. <tal:block condition/> tags are meant for
display login, not doing any heavy logic.

ZPT makes things clean, understandable and simple, unlike DTML which
forces you to switch mindsets, allows you to mix application logic with
presentation logic and just generally make for bad coding habits.

> 
> The benefit of ZPT was supposed to be that you can have HTML programmers
> do HTML programming, whereas coders do coding.  In dynamic sites, the
> main template is often hand-coded anyways; and you often only need one
> of it, so you can have your coder copy-paste (or more often recreate)
> the HTML code that the designer made into the template.  That one
> template often has very complex logic which is further made more complex
> if encoded in ZPT.  ZPT templates are, in my experience, much more
> verbose than DTML templates.  I think we bought a small benefit
> (slightly more HTML editor-friendly templates) for a big price (more
> complex templates).

I don't understand the above at all. HTML coder creates template. If
it's HTML, then there is no logic in it. Period. HTML doesn't have logic
in it.

So lets assume you mean that the HTML guy created the template and
explains some additional logic to the back-end developer. That means
someone with zope experience creates a ZPT template from it. During this
process removes the non-display parts of any logic into python scripts
and/or real products. Future pages use this template using METAL and
there is no need to copy/paste.

ZPT are, in my experience, more verbose than DTML at the cost of
simplicity, understandability and cleanliness.

[snip]
-- 
Edward Muller - http://www.interlix.com - "Open Source Specialists"
Dedicated Zope Hosting - Web Hosting - Open Source Consulting
Network & PC Service & Support - Custom Programming
Phone: 417-862-0573 - Cell: 417-844-2435 - Fax: 417-862-0572
Jabber: edwardam@jabber.interlix.com - AIM: edwardam453 - ICQ: 287033


From jim at zope.com  Tue Feb 10 16:29:01 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 10 16:29:45 2004
Subject: [Zope3-dev] best way to deal with dependency errors
In-Reply-To: <20040210094947.14b728bf.casey@zope.com>
References: <20040210014235.8826625ADA0@bonanza.off.ekorp.com>	<4028A692.2010608@zope.com>
	<20040210094947.14b728bf.casey@zope.com>
Message-ID: <40294D1D.8040307@zope.com>

Casey Duncan wrote:
> On Tue, 10 Feb 2004 04:38:26 -0500
> Jim Fulton <jim@zope.com> wrote:
> 
> [..]
> 
>>The ConfirmationRequired exception has a view that:
>>
>>   - Displays the issues and a confirmation button
>>
>>   - Includes hidden fields that identify the issue.
>>     This is needed to make sure that we have confirmed all
>>     of the same issues when the application is reexecuted.
> 
> 
> This is an interesting pattern.

I think so too. In general, I thjink that the new-in-Zope-3
pattern of using views on exceptions to handle errors provides
lots of interesting opportunities.

 > Interactive exception views. Actually I
> think that in a well-mannered application, most exceptions should be
> interactive in some way.
> 
> In general application exception views are a way for the app to express
> an "Oh crap, I'm too stupid to figure this out for myself, what should I
> do now?".
> 
> A simple example would be a transitory error, like lets say a conflict
> that recurs after 3 retrys. It could perhaps have a "Try Again" button
> that lets the user replay the request.
> 
> Or let's say a user tried to delete a locked item. If the user can
> unlock the object then the exception view could have a "Delete Anyway"
> button that unlocks the object and retrys the delete.
 >
> Or let's say you are adding a new item to a folder and you choose a name
> that already exists. The exception view could provide a form where the
> user can choose a different name.

Yup

> All of these assume some way to store enough info about the previous
> request to replay it (sometimes with modifications). There are of course
> many ways to do this, but it would be nice to have this automated by the
> framework in some way since it is a common operation.

<shrug>

> We may want to think about not limiting this sort of functionality to
> events. Otherwise I see myself using events just to get this nice
> "resolve issues" functionality even if I wouldn't otherwise use them.
> OTOH, maybe that should be a reason to use events.

You can do this sort of thing without events. Events simply provide
a way to decouple things, so, for example, the application that deletes
things doesn't need to know about locks or dependencies.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From dpharris76 at msn.com  Tue Feb 10 16:31:31 2004
From: dpharris76 at msn.com (Dave Harris)
Date: Tue Feb 10 16:31:43 2004
Subject: [Zope3-dev] Repost: Q on conf error reporting
Message-ID: <BAY3-F21BL0Qacfde5Z00024044@hotmail.com>

I posted this just before all the list activity ramped up Sunday afternoon. 
It's not as momentous as decisions about 'core' or 'inline', but I'd still 
like to get a opinion.

Thanks,
Dave Harris


>From: "Dave Harris" <dpharris76@msn.com>
>To: "zope3-dev" <zope3-dev@zope.org>
>Subject: [Zope3-dev] Q on conf error reporting
>Date: Sun, 8 Feb 2004 13:57:15 -0600
>
>I added an server entry to zope.conf using a silly type:
>
><server>
>   type LEMMING
>   address 8083
></server>
>
>and received (deservedly) a program failure marking my misdeed:
>
>Traceback (most recent call last):
>   File "z3.py", line 65, in ?
>     run()
>   File "z3.py", line 61, in run
>     main(argv[1:])
>   File "C:\rascal\dev\Z3SB\src\zope\app\process\main.py", line 56, in main
>     setup(args)
>   File "C:\rascal\dev\Z3SB\src\zope\app\process\main.py", line 99, in 
>setup
>     server.create(task_dispatcher, db)
>   File "C:\rascal\dev\Z3SB\src\zope\app\process\server.py", line 42, in
>create
>     servertype.create(task_dispatcher, database,
>AttributeError: 'NoneType' object has no attribute 'create'
>
>This leads to a couple (or four) questions:
>
>1) When getServerType() returns None, should create() still proceed with 
>the
>servertype.create() call?
>
>2) When a bad but well-formed configuration entry is processed, should Zope
>3 report the specifics (e.g. the config file line and the reason for
>failure)?
>
>3) In general, should Zope 3 disguise the fact that Python is the
>implementation language - that is, not generate tracebacks?
>
>4) Would a test for this situation be a unit test of
>zope.app.process.setup()? Or would it be considered a functional test?
>
>Thanks,
>Dave Harris
>
>_______________________________________________
>Zope3-dev mailing list
>Zope3-dev@zope.org
>http://mail.zope.org/mailman/listinfo/zope3-dev

_________________________________________________________________
Find great local high-speed Internet access value at the MSN High-Speed 
Marketplace. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/


From pw_lists at slinkp.com  Tue Feb 10 16:38:11 2004
From: pw_lists at slinkp.com (Paul Winkler)
Date: Tue Feb 10 16:38:15 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <223FDE230D02BA47BC04261D5B0F91F50152F5@ntbox.backup-exoweb>
References: <223FDE230D02BA47BC04261D5B0F91F50152F5@ntbox.backup-exoweb>
Message-ID: <20040210213811.GF2026@slinkp.com>

On Tue, Feb 10, 2004 at 12:20:51PM +0800, Bjorn Stabell wrote:
> To me, the presentation/code separation is the argument against DTML and
> for ZPT as well.  DTML was simple, or at least had the potential to be
> if it was even more Python-esque and was less "magical".

Don't know what you mean.
<dtml-var foo> is probably the most magical thing in Zope 2.

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's PRAYER ZIPPER WITH TIME TO SPARE!
(random hero from isometric.spaceninja.com)

From casey at zope.com  Tue Feb 10 17:03:30 2004
From: casey at zope.com (Casey Duncan)
Date: Tue Feb 10 17:06:15 2004
Subject: [Zope3-dev] Inline code
In-Reply-To: <Pine.LNX.4.50.0402101326280.9991-100000@shane.zope.com>
References: <20040209111821.3f2c3f7e.casey@zope.com>
	<Pine.LNX.4.50.0402091338130.1859-100000@shane.zope.com>
	<Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
	<40291F46.4070407@modernsongs.com>
	<Pine.LNX.4.50.0402101326280.9991-100000@shane.zope.com>
Message-ID: <20040210170330.4881541c.casey@zope.com>

On Tue, 10 Feb 2004 14:04:05 -0500 (EST)
Shane Hathaway <shane@zope.com> wrote:

[..]
> 4. Drop ZPT and use scripts to do simple document transformation.  
> (Casey's suggestion.  Similar to XMLC.)
> 
>   -0

I'm not suggesting dropping ZPT. That'd be throwing the baby out with
the bath water. ZPT is far too entrenched an encumbent to just toss.
Many people like it (some emphatically ;^), and it is by all accounts a
huge success by many measures. Especially when measured against it's
predecessor.

IOW I don't expect my perfect world to suit everyone ;^)

I find ZPT has a "sweet spot" that you have to be careful to stay in. If
you can tilt the world correctly it usually just plunks in. It takes
some zen to get the tilt right, though, and sometimes you can't.

The three main places it breaks down for me is:

- Trying to read templates with huge define blocks, python expressions
and <tal:block> tags (which are never written by moi, heavens no ;^).
Regardless of whether they are "right" or not, ZPT makes it easy to do
it so people do.

- Modularizing things for maintainability or reuse though macros. This
quickly defeats many of its benefits and makes it hard to follow.
Especially where macros are parameterized or variable. Sometimes I feel
like I'm programming in BASIC (x = 1: y = 2: gosub 10250)

- Highly dynamic pages where the structure varies on multiple axis.
These quickly turn to mush in ZPT. The worst example I ever contrived
was an XML template where some element names were dynamic. It was
clearly outside of the range intented for ZPT and it smelled real bad.
Most are much less evil then that, but still mushy.

I think of the last one like inheritance versus composition. ZPT is like
an inheritance model where everything you do to the page is inside the
page. If you want to add a little thing here or there sometimes, you end
up adding lots of conditional code blocks every which way.
Transformation is more like composition. The things I do to make a page
can be spread out to different (hopefully simple) transformers that can
be mixed and matched. Adding an external editor pencil icon to the rows
in a folder view doesn't have to mean changing the folder view at all
directly. You just apply the transformer to do it. Maybe the same
transform (or a derived version) can also be applied to many other pages
too that show lists of items. Transformers also let you do global
changes in one broad stroke like: Change all <img> src attributes to
absolute urls, or insert standard <link> tags into the <head>, etc. 

Both ways have their place. Transformation is more abstract and
abstraction can be inconvenient and less transparent. ZPT's inline
notation is transparent assuming it is kept simple enough. OTOH the
potential for reusability in transforms (in a way like adapters) is
pretty compelling.

-Casey


From jim at zope.com  Tue Feb 10 17:23:07 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 10 17:24:00 2004
Subject: [Zope3-dev] What is Core?
In-Reply-To: <16395402-5C08-11D8-B781-003065415378@bottlerocket.net>
References: <402573CA.9030409@zope.com>	<200402071837.44347.srichter@cosmos.phy.tufts.edu>	<c04vkh$r5p$1@sea.gmane.org>
	<16395402-5C08-11D8-B781-003065415378@bottlerocket.net>
Message-ID: <402959CB.7050402@zope.com>

Jeffrey P Shell wrote:
> On Feb 8, 2004, at 2:28 AM, Michael Haubenwallner wrote:
> 
>> Stephan Richter wrote:
>>
>>> On Saturday 07 February 2004 18:24, Jim Fulton wrote:
>>>
>>>> One possibility is to say that 1.0 (perhaps a different designation
>>>> would be better) is really for those people who are already delivering
>>>> Zope 3 apps.  It emphasizes the things that work pretty well now,
>>>> meaning core services and file-system-based developmen
>>>
>>> Yes, I agree with that based on your previous message. I can always 
>>> make a experimental TTW-enabled release, like "1.0+TTW" for people 
>>> who want to try it and give feedback. Zope 3 1.0 will get a lot of 
>>> attention, and I would love to use some of this momentum to get TTW 
>>> development feedback. On the other hand I do not want to make the 
>>> main release messy, late and unstable, so that people will look at it 
>>> and say: What the hell is this?
>>>
>>
>> Would it make sense to remove the TTW-management-interface from the 
>> 'core' and into a product ? Could this product be used as an example 
>> of how to write management products for zope3 ?
> 
> 
> Alright - what is 'core'?  I remember typing up this question, but I 
> don't know if I ever sent it.

I doubt that people are using this word consistently.  In fact,
it is often used as an adjective. In other words, it's meaning
is often relative to the context it's used in.

> I thought core was everything *but* zope.app.  zope.component, 
> zope.publisher, etc - that was the core core.  Is that stuff now 
> 'sub-core?' (which is kindof hard to do ;).  Or is it the meta-core?

:)

I think of these as core in the sense that they are required to run the
zope application server.  But, zope.app is also core.  Things being lifted
out of zope.app into zope.products are things that are either not strictly
required or things for which alternative implementations might be used.
What's left in zope.app will be core for the application server. One could
argue that the other required zope packages will be core too. <shrug>

> I just hear a lot of people batting the term 'core' around an awful lot 
> these days.  Usually in terms of "maybe that shouldn't be in the core."

Yes, and, as I said before, the meaning is a bit confused.

Right now, the most important questions are:

- What work needs to be done to release 1.0?

- How should the 1.0 release be described, so that people
   have clear expectations about what 1.0 is and isn't and
   can know what to expect for the future?

Some somewhat less important questions are:

- How should we arrange the sources to make them easier to understand and use>
   We are doing this again now because it may be our last chance.

- What should we include in the 1.0 distribution?

> And I hope will also help us avoid the 'man, we really need to bust up 
> zope.products' conversation if everything from 'zope.app' ends up in there.

:)

I think that there is some consensus that both zope.app and zope.products
should be very flat.  Given this, I have to admit that the distinction
between zope.app and zope.products seems somehow to be less important.

> Maybe 'ttw' should not necessarily be in 'zope.products', but as 
> 'zope.ttw'.  This changes some of the definitions of what those top 
> level zope.* packages should be, but I think that's been shifting anyways.

This illustrates why I'm a little queasy about the add-on/core distinction
between zope.products and zope.app. There are a lot of ways we can
classify the software. Given that, it is perhaps counter productive
to carve the classifications into a package structure.  Perhaps there should
be a separate package catalog for zope paclages that superimposes
dynamic classification schems on the package structure.


> Or maybe it's really time to start looking at component packaging, 
> distribution, and installation issues, so that elements that could very 
> well be part of the so-called 'core' can be distributed and installed on 
> their own until they become part of the core.  Component Management is a 
> pretty significant part of many component architectures, which includes 
> installation as well as configuration.  We've got the configuration bit 
> pretty much down, it seems, but adding and removing the actual software 
> bits seems to be another matter.

Perhaps.

> I guess that's been one of the benefits of the magical 'Products' 
> package of Zope 2.  You can refer to 'Products.PythonScripts', which is 
> installed in /usr/local/zope/2.6.1/lib/python/Products; and refer to 
> Products.SuperTemplates, which is installed in 
> /home/jshell/projects/cust1/Products.

That's a benefit of Python packages in general. You don't need special
container packages to get that.

> I don't like how this was used to install and deal with third party 
> products - I'd prefer to keep our packages in our own top namespace (ie 
> 'bottlerocket.commerce' or 'bottlerocket.ticketing'), and I like that 
> Zope 3 supports this (now that 'path' configuration is in the ZConfig 
> setup).  However, I do like that Products.* was a system that allowed 
> for packages like Page Templates to be distributed individually until 
> they became part of the common distribution - in a way that was forwards 
> compatible with their acceptance.

Again, I don't think you need a special container package to do that.
In fact, I think it makes it harder, which is why we've dropped
zopeproducts.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Tue Feb 10 20:25:18 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 10 20:26:05 2004
Subject: [Zope3-dev] Remove src/zope/context from your cvs checkouts
Message-ID: <4029847E.7050107@zope.com>


rm -rf src/zoep/context

I have moved this no-longer-used package to a different part of the
repository.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From edwardam at interlix.com  Tue Feb 10 20:45:46 2004
From: edwardam at interlix.com (Edward Muller)
Date: Tue Feb 10 20:45:54 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
In-Reply-To: <1076345977.20894.99.camel@athlon>
References: <40230606.4090805@zope.com>
	<200402070811.35507.srichter@cosmos.phy.tufts.edu>
	<40257358.5040607@zope.com>
	<200402071929.25507.srichter@cosmos.phy.tufts.edu>
	<402586CC.8040503@zope.com> <20040208203643.GD1723@slinkp.com>
	<20040209111821.3f2c3f7e.casey@zope.com>
	<20040209165025.GF1716@slinkp.com>
	<1076345977.20894.99.camel@athlon>
Message-ID: <1076463945.28167.144.camel@palin>

+1

On Mon, 2004-02-09 at 10:59, Chris McDonough wrote:
> +1 to Casey's concerns ;-)
> 
> 
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope3-dev
-- 
Edward Muller - http://www.interlix.com - "Open Source Specialists"
Dedicated Zope Hosting - Web Hosting - Open Source Consulting
Network & PC Service & Support - Custom Programming
Phone: 417-862-0573 - Cell: 417-844-2435 - Fax: 417-862-0572
Jabber: edwardam@jabber.interlix.com - AIM: edwardam453 - ICQ: 287033


From jim at zope.com  Tue Feb 10 21:00:42 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 10 21:01:31 2004
Subject: [Zope3-dev] What don't file-system-based developers need
Message-ID: <40298CCA.4040806@zope.com>


If we decode that the next release is for file-system-based developers,
I wonder what they need.  I'm particularly interested in getting input
from folks who've already been creating production applications with
Zope 3.

Do file-system-based developers need:

- Database adapters (SQL database connections)?

- SQL scripts?

- Catalogs?

- Workflow?

- Caches?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From bjorn at exoweb.net  Wed Feb 11 03:56:48 2004
From: bjorn at exoweb.net (Bjorn Stabell)
Date: Wed Feb 11 04:01:12 2004
Subject: [Zope3-dev] Need help planning Zope X3 1.0
Message-ID: <223FDE230D02BA47BC04261D5B0F91F501530F@ntbox.backup-exoweb>

Jeffrey:
> I love ZPT.

Okay, I can see ZPT has real benefits in your situation.

In our situation it isn't as clear, and although I've been using ZPT for
a long time, I am still not very proficient with it.  DTML didn't take
long to learn... for me.  It didn't try to reinvent the world of
programming (except for acquistion, that is).  I also really hate ZPT
being more verbose, and so I don't find it cleaner. :-/  But I see that
ZPT does make it easier to make templates that are valid HTML since
you're enforced to work with valid markup all the time.

You can say PHP and ASP don't encourage presentation/code separation,
but at least you can't say PHP and ASP aren't popular, and that's an
important success criteria for technology in my mind (it's not the most
important, however).  And them being easy to learn and easy to use is
probably a big reason for their popularity.  To gain marketshare, Zope
should be easy to learn, especially for the "casual website hacker" who
is probably going to be the one who drives Zope popularity, the same way
he did for PHP.  PHP is now mainstream, has a plethora of hosting
options etc, and so it's easy to convince businesses to use it as well.

Hm, I never thought I'd see the day that I would be advocating a more
conservative technology option :)  Maybe I'm getting old.

All in all, I think ZPT isn't bad--it is innovative and useful--it's
just not the best solution in all cases.

Bye,
-- 
Bjorn

From Mailer-Daemon at python.org  Wed Feb 11 06:42:56 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Wed Feb 11 06:42:58 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1Aqslc-0007Ro-Ao@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1AqskD-00065z-FB; Wed, 11 Feb 2004 06:41:29 -0500
From: zope3-dev@zope.org (philikon)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [Zope3Proposals] 
Message-ID: <20040211064129EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Proposals/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Proposals/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Proposals>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Wed, 11 Feb 2004 06:41:29 -0500
X-Spam-Status: OK (default 0.014)

++added:
- [PackageGeddon]

  Move optional/customizable packages from zope.app to zope.products.
--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Proposals

From Mailer-Daemon at python.org  Wed Feb 11 06:43:25 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Wed Feb 11 06:43:28 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1Aqsm5-0007tj-SW@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1Aqski-0006Zj-Mj; Wed, 11 Feb 2004 06:42:00 -0500
From: zope3-dev@zope.org (philikon)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [PackageGeddon] (new) 
Message-ID: <20040211064200EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Wed, 11 Feb 2004 06:42:00 -0500
X-Spam-Status: OK (default 0.000)

PacakgeGeddon

  Author

    Philipp von Weitershausen (philiKON)

  Status

    IsProposal

  Problem

    'zope.app' contains much functionality, too much really. It
    contains many things that are going to be customized by
    applications later, like the browser skins and the content
    components.

    We have decided that the place for everything that is
 
      a) optional in some sense or

      b) going to be customized once or more

    is 'zope.products'.

  Proposal

    The following packages shall be moved:

      - 'zope.app.content' (and its interfaces, browser views) will
      become

        * 'zope.products.folder' (note that the folder component
          itself cannot be moved out because of dependencies; this
          package will only contain its browser views and
          configuration).

        * 'zope.products.file'

        * 'zope.products.image'

        * 'zope.products.i18nfile'

        * 'zope.products.i18nimage'

        * 'zope.products.zptpage'

        * 'zope.products.dtmlpage'

        * 'zope.products.sqlscript'

      - 'zope.app.workflow' (and its interfaces, browser views ) will
      become 'zope.products.workflow'

     - 'zope.app.browser.skin.rotterdam' will become 'zope.products.rotterdam'

     - 'zope.app.browser.skin.zopetop' will become 'zope.products.zopetop'

     - 'zope.app.onlinehelp' (and its interfaces, browser views) will
     become 'zope.products.onlinehelp'.

  Discussion

    Most of the discussion has already been held in the "'Moving more
    stuff to zope.products' thread on the zope-dev
    list":http://mail.zope.org/pipermail/zope3-dev/2004-February/009543.html

    Here's a short summary:

      - the change will make zope.app smaller and easier to maintain

      - it will flatten the hierarchy (no more searching in
      zope.app.interfaces, zope.app.browser for packages that really
      belong together, like workflow).

      - it will show developers what is supposed to be customized and
      what they actually *can* customize easily.

      - it will put certain packages, like the browser skins, in the
      hands of specific maintainers. This will hopefully improve the
      maintainance on these packages.

  Implementation

    This proposal is currently being implemented in the
    'philikon-movecontent-branch'.

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon

From peter at sabaini.at  Wed Feb 11 07:01:08 2004
From: peter at sabaini.at (Peter Sabaini)
Date: Wed Feb 11 07:01:12 2004
Subject: [Zope3-dev] What don't file-system-based developers need
In-Reply-To: <40298CCA.4040806@zope.com>
References: <40298CCA.4040806@zope.com>
Message-ID: <402A1984.1050406@sabaini.at>

My 0.2EUR, speaking as a Zope2 FS Developer...

Jim Fulton wrote:
 >
 > If we decode that the next release is for file-system-based developers,
 > I wonder what they need.  I'm particularly interested in getting input
 > from folks who've already been creating production applications with
 > Zope 3.
 >
 > Do file-system-based developers need:
 >
 > - Database adapters (SQL database connections)?

Yes!

 > - SQL scripts?

Yes please!

 > - Catalogs?

Not essential

 > - Workflow?

No

 > - Caches?

Would be nice to have, but can do without


Thanks for all the great work...
  - peter.

 > Jim
 >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3461 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20040211/6c892ead/smime.bin
From nicoe at altern.org  Wed Feb 11 07:10:54 2004
From: nicoe at altern.org (Nicolas =?iso-8859-15?Q?=C9vrard?=)
Date: Wed Feb 11 07:10:59 2004
Subject: [Zope3-dev] What don't file-system-based developers need
In-Reply-To: <40298CCA.4040806@zope.com>
References: <40298CCA.4040806@zope.com>
Message-ID: <20040211121054.GA851@smarties.nutellux.ath.cx>

* Jim Fulton  [03:00 11/02/04 CET]: 

>Do file-system-based developers need:
>
>- Database adapters (SQL database connections)?

No, I'm embedding this in my python products.

>- SQL scripts?

No.

>- Catalogs?

Yes.

>- Workflow,Caches?

I think, I would use them although I never did for now.

-- 
(?>  Nicolas ?vrard
/ )  Li?ge - Belgique
^^

From philipp at weitershausen.de  Wed Feb 11 07:40:02 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Wed Feb 11 07:33:25 2004
Subject: [Zope3-dev] Re: What don't file-system-based developers need
In-Reply-To: <40298CCA.4040806@zope.com>
References: <40298CCA.4040806@zope.com>
Message-ID: <402A22A2.3050506@weitershausen.de>

Jim Fulton wrote:
> 
> If we decode that the next release is for file-system-based developers,

Who encoded it? ;)

> I wonder what they need.  I'm particularly interested in getting input
> from folks who've already been creating production applications with
> Zope 3.
> 
> Do file-system-based developers need:
> 
> - Database adapters (SQL database connections)?

Yes. People are using them already (even in production).

> - SQL scripts?

If you're referring to the content objects, then I wouldn't need them. 
But that's probably I dislike their concept anyway (as much as I dislike 
ZPT Page and DTML Page).

> - Catalogs?

I dislike the Catalog as a content object. Has that changed now? I 
remember seeing a checkin of some sort. I'd be glad if it is a local 
utility now.

> - Workflow?

Yes.

> - Caches?

Not right now, but in the future, yes.

Philipp


From Mailer-Daemon at python.org  Wed Feb 11 07:52:35 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Wed Feb 11 07:52:37 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1Aqtr1-0002H7-UK@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1Aqtpf-0001VL-Bb; Wed, 11 Feb 2004 07:51:11 -0500
From: zope3-dev@zope.org (philikon)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [PackageGeddon] 
Message-ID: <20040211075111EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Wed, 11 Feb 2004 07:51:11 -0500
X-Spam-Status: OK (default 0.046)

++added:
  Questions/Problems/Drawbacks

    - Which i18n domain shall be applied to the packages in
    zope.products (generally)?
--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon

From peter at sabaini.at  Wed Feb 11 07:54:24 2004
From: peter at sabaini.at (Peter Sabaini)
Date: Wed Feb 11 07:54:27 2004
Subject: [Zope3-dev] What don't file-system-based developers need
In-Reply-To: <20040211121054.GA851@smarties.nutellux.ath.cx>
References: <40298CCA.4040806@zope.com>
	<20040211121054.GA851@smarties.nutellux.ath.cx>
Message-ID: <402A2600.6020402@sabaini.at>

Nicolas ?vrard wrote:
> * Jim Fulton  [03:00 11/02/04 CET]:
> 
>> Do file-system-based developers need:
>>
>> - Database adapters (SQL database connections)?
> 
> 
> No, I'm embedding this in my python products.

So you are keeping a database connection open per product? I'd like to 
keep them more centralized, so different classes / class hierarchies can 
share one connection; that would fit in nicely with the "service" or 
"utility" concepts (if I understood them correctly).

>> - SQL scripts?
> 
> 
> No.

So how do you manage your SQL queries? I wouldn't want to just keep a 
bunch of SQL strings around...

>> - Catalogs?
> 
> 
> Yes.
> 
>> - Workflow,Caches?
> 
> 
> I think, I would use them although I never did for now.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3461 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20040211/8b34210e/smime.bin
From Mailer-Daemon at python.org  Wed Feb 11 08:00:43 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Wed Feb 11 08:00:46 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1Aqtyt-0004rD-6F@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1AqtxZ-0003ZD-Bt; Wed, 11 Feb 2004 07:59:21 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [PackageGeddon] I18n-specific content types
Message-ID: <20040211075920EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Wed, 11 Feb 2004 07:59:20 -0500
X-Spam-Status: OK (default 0.000)

++added:

>From srichter Wed Feb 11 07:59:00 US/Eastern 2004 From: srichter Date:
2004/02/11 07:59 EST Subject: I18n-specific content types Message-ID:
<20040211075918EST@dev.zope.org>

I think you can merge i18nimage into zope.products.image and i18nfile
to zope.products.file. Also note that image depends on file. We need a
way to tell users which products depend on each other. (The same is
true for apidoc and statictree, btw.)

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon

From nicoe at altern.org  Wed Feb 11 08:17:19 2004
From: nicoe at altern.org (Nicolas =?iso-8859-15?Q?=C9vrard?=)
Date: Wed Feb 11 08:17:25 2004
Subject: [Zope3-dev] What don't file-system-based developers need
In-Reply-To: <402A2600.6020402@sabaini.at>
References: <40298CCA.4040806@zope.com>
	<20040211121054.GA851@smarties.nutellux.ath.cx>
	<402A2600.6020402@sabaini.at>
Message-ID: <20040211131719.GF851@smarties.nutellux.ath.cx>

* Peter Sabaini  [13:54 11/02/04 CET]: 

>>>Do file-system-based developers need:
>>>
>>>- Database adapters (SQL database connections)?
>>
>>
>>No, I'm embedding this in my python products.
>
>So you are keeping a database connection open per product?
>I'd like to keep them more centralized, so different classes / class
>hierarchies can share one connection; that would fit in nicely with the
>"service" or "utility" concepts

In fact, my product is an utily, which in turn query his database (I
have not found the time to code this yet, so this might change, but
that's how I will handle it).

The main reason for this is because, I have two frontends for the
database one zope-based and the other one using wxpython. Maybe one day
views will include a wxpython adapter ...

> (if I understood them correctly).

I'm not sure either. I think that I will see more clearly when I'll try
it (unfortunatly I've got to work on a Zope2 project now and I'm already
used to some zope3 thinking).

>>>- SQL scripts?
>>
>>
>>No.
>
>So how do you manage your SQL queries? I wouldn't want to just keep a 
>bunch of SQL strings around...

No SQL strings around, I've made a python module who is able to create
SQL queries from a database schema definition. Basicaly I compose a
product with a dbschema and a sqlconnection. This product can now
insert, remove, update its information in the db. You can also make some
dbschema cross-selection (albeit simple ones).

But this product is a work in progress and I feel the need to rewrite it
from scratch.

-- 
(?>  Nicolas ?vrard
/ )  Li?ge - Belgique
^^
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20040211/b91ef0a3/attachment.bin
From sidnei at awkly.org  Wed Feb 11 08:25:27 2004
From: sidnei at awkly.org (Sidnei da Silva)
Date: Wed Feb 11 08:26:15 2004
Subject: [Zope3-dev] What don't file-system-based developers need
In-Reply-To: <20040211131719.GF851@smarties.nutellux.ath.cx>
References: <40298CCA.4040806@zope.com>
	<20040211121054.GA851@smarties.nutellux.ath.cx>
	<402A2600.6020402@sabaini.at>
	<20040211131719.GF851@smarties.nutellux.ath.cx>
Message-ID: <20040211132527.GB11402@moria.redesul.com.br>

| No SQL strings around, I've made a python module who is able to create
| SQL queries from a database schema definition. Basicaly I compose a
| product with a dbschema and a sqlconnection. This product can now
| insert, remove, update its information in the db. You can also make some
| dbschema cross-selection (albeit simple ones).
| 
| But this product is a work in progress and I feel the need to rewrite it
| from scratch.

Why don't you just use SQLObject? I've been doing this for quite some
time now, and it even copes well with transactions. 

-- 
Sidnei da Silva <sidnei@awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher

The world is coming to an end ... SAVE YOUR BUFFERS!!!

From nicoe at altern.org  Wed Feb 11 08:46:23 2004
From: nicoe at altern.org (Nicolas =?iso-8859-15?Q?=C9vrard?=)
Date: Wed Feb 11 08:46:47 2004
Subject: [Zope3-dev] What don't file-system-based developers need
In-Reply-To: <20040211132527.GB11402@moria.redesul.com.br>
References: <40298CCA.4040806@zope.com>
	<20040211121054.GA851@smarties.nutellux.ath.cx>
	<402A2600.6020402@sabaini.at>
	<20040211131719.GF851@smarties.nutellux.ath.cx>
	<20040211132527.GB11402@moria.redesul.com.br>
Message-ID: <20040211134623.GG851@smarties.nutellux.ath.cx>

* Sidnei da Silva  [14:25 11/02/04 CET]: 
>| No SQL strings around, I've made a python module who is able to create
>| SQL queries from a database schema definition. Basicaly I compose a
>| product with a dbschema and a sqlconnection. This product can now
>| insert, remove, update its information in the db. You can also make some
>| dbschema cross-selection (albeit simple ones).
>| 
>| But this product is a work in progress and I feel the need to rewrite it
>| from scratch.
>
>Why don't you just use SQLObject?

For historical reasons. But as I said, I'm thinking about a rewrite some
days, then I will investigate other solutions.

>I've been doing this for quite some time now, and it even copes well
>with transactions. 

It looks, great indeed. I'll definitvely try it.

-- 
(?>  Nicolas ?vrard
/ )  Li?ge - Belgique
^^
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20040211/6aa8f9d2/attachment.bin
From Mailer-Daemon at python.org  Wed Feb 11 09:10:19 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Wed Feb 11 09:10:22 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1Aqv4F-0007Va-Ti@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1Aqv2v-0006nP-Ce; Wed, 11 Feb 2004 09:08:57 -0500
From: zope3-dev@zope.org (philikon)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [PackageGeddon] typo
Message-ID: <20040211090856EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Wed, 11 Feb 2004 09:08:56 -0500
X-Spam-Status: OK (default 0.068)

??changed:
-PacakgeGeddon
PackageGeddon

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon

From Mailer-Daemon at python.org  Wed Feb 11 09:14:10 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Wed Feb 11 09:14:12 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1Aqv7y-000352-Ve@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1Aqv6f-0002BB-I3; Wed, 11 Feb 2004 09:12:49 -0500
From: zope3-dev@zope.org (philikon)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [PackageGeddon] I18n-specific content types
Message-ID: <20040211091248EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Wed, 11 Feb 2004 09:12:48 -0500
X-Spam-Status: OK (default 0.000)

++added:

>From philikon Wed Feb 11 09:12:00 US/Eastern 2004 From: philikon Date:
2004/02/11 09:12 EST Subject: I18n-specific content types Message-ID:
<20040211091246EST@dev.zope.org> In-reply-to:
<20040211075918EST@dev.zope.org>

As for the dependency, I think this should be documented at least in
README.txt. Though we indeed should watch that products do not depend
on each other too much. I am not so sure about merging i18n{} to
zope.products{}, though.

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon

From jtk at yahoo.com  Wed Feb 11 10:04:59 2004
From: jtk at yahoo.com (Jeff Kowalczyk)
Date: Wed Feb 11 10:03:41 2004
Subject: [Zope3-dev] Re: Inline code
References: <20040209111821.3f2c3f7e.casey@zope.com>
	<Pine.LNX.4.50.0402091338130.1859-100000@shane.zope.com>
	<Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
	<40291F46.4070407@modernsongs.com>
	<Pine.LNX.4.50.0402101326280.9991-100000@shane.zope.com>
Message-ID: <pan.2004.02.11.15.04.55.356728@yahoo.com>

Have you considered allowing the page template to inherit/adapt to a
namespace from a python script/module? ASP.Net .aspx pages can inherit
from a class (the module is called 'code-behind'). It does a fair job of
eliminating the need for inline code, while providing a reasonable place
to locate certain unavoidable code that sits between application libraries
and one specific page template, such as a datagrid editing page. The
inherited namespace aims to provide objects and methods that are purely
callable, representable, indexable or iterable to the ZPT.

Their IDE presents the .aspx and .cs file as a pair, Zope could have an
object that provided a TTW editor for the ZPT and the module/script. It
should be transferrable to filesystem developers, although they'd have
fewer reasons to use it.

This ASPX example is for their webform gui controls, but I don't cite it
because of the event handling model, rather because of the economy of
being able to predict your namespace in python module and its tightly
associated template. It would be more relevant to Zope development with
non-gui python objects representing application libraries. The code-behind
module could serve as the python glue to filesystem python libraries and
application, limiting the namespace of variables, method results and
iterables necessary to build the specific ZPT without inline code.

I don't know what the reaction to this idea will be, but if it worked out,
I could imagine having all page templates inherit from / adapt to some
default base module, giving explicit control over the template namespace.

(FWIW: I don't understand giving up XML formedness for the '<%@' tag, either)

hellocodebehindcs.aspx
------------------------------
<%@ Page Language="cs" Src="hellocodebehindcs.cs" Inherits="HelloWebFormCs"%>
<html><head><title>C# ASP.NET application with "Code Behind"</title></head>
<body>
  <p>C# ASP.NET application with "Code Behind"<p>
     <form runat="server" ID="Form1">
       <asp:button runat="server" text="Say Hello" ID="Button1" />
     <p><asp:label runat="server" text="" id="TheLabel" />
      </form>
   </body>
</html>

hellocodebehindcs.cs
------------------------------
public class HelloWebFormCs : System.Web.UI.Page {
   protected System.Web.UI.WebControls.Button Button1;
   protected System.Web.UI.WebControls.Label TheLabel;
   override protected void OnInit(System.EventArgs e) {
      this.Button1.Click += 
         new System.EventHandler(this.Button1_Click);
      base.OnInit(e);
   }
   private void Button1_Click(object sender, System.EventArgs e) {
      TheLabel.Text = 
      "Hello, world! (from an ASP.NET/C# WebForm with code behind)";
   }
}

Excerpted From:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnguinet/html/drguinet0code.asp



From shane at zope.com  Wed Feb 11 10:32:13 2004
From: shane at zope.com (Shane Hathaway)
Date: Wed Feb 11 10:32:24 2004
Subject: [Zope3-dev] Inline code
In-Reply-To: <20040210170330.4881541c.casey@zope.com>
References: <20040209111821.3f2c3f7e.casey@zope.com>
	<Pine.LNX.4.50.0402091338130.1859-100000@shane.zope.com>
	<Pine.LNX.4.50.0402101001590.9991-100000@shane.zope.com>
	<40291F46.4070407@modernsongs.com>
	<Pine.LNX.4.50.0402101326280.9991-100000@shane.zope.com>
	<20040210170330.4881541c.casey@zope.com>
Message-ID: <Pine.LNX.4.50.0402110948260.18607-100000@shane.zope.com>

On Tue, 10 Feb 2004, Casey Duncan wrote:

> I find ZPT has a "sweet spot" that you have to be careful to stay in. If
> you can tilt the world correctly it usually just plunks in. It takes
> some zen to get the tilt right, though, and sometimes you can't.

I know what you're saying.  The first revision of the "page design" idea
had templates with more dynamic code than static XML.  I did everything I
could to move computation into Python scripts, but the problem space was
simply too complex to allow the templates to be readable.

Eventually, I the logic into CSS and Javascript.  This strategy made the
subsystem far easier to maintain and expand.  CompositePage now uses CSS 
for basic transformation and Javascript for deeper transformation.  I 
essentially used your strategy of transforming the page after rendering.

I tend to believe that this level of complexity is rare, though.  Most
people just want to write a guest book, web log, or shopping cart.  For
them, a little block of code in a template makes them happy quickly.

> The three main places it breaks down for me is:
> 
> - Trying to read templates with huge define blocks, python expressions
> and <tal:block> tags (which are never written by moi, heavens no ;^).
> Regardless of whether they are "right" or not, ZPT makes it easy to do
> it so people do.

Perhaps we should look at the ways that people use tal:block and suggest
alternatives.  I know I've used tal:block to iterative over row groups in
tables, but it turns out I could have used "tbody" just as effectively
instead.

> - Modularizing things for maintainability or reuse though macros. This
> quickly defeats many of its benefits and makes it hard to follow.
> Especially where macros are parameterized or variable. Sometimes I feel
> like I'm programming in BASIC (x = 1: y = 2: gosub 10250)

Parameterized macros are known to be a problem.  Ken and I have discussed
a replacement.

> - Highly dynamic pages where the structure varies on multiple axis.
> These quickly turn to mush in ZPT. The worst example I ever contrived
> was an XML template where some element names were dynamic. It was
> clearly outside of the range intented for ZPT and it smelled real bad.
> Most are much less evil then that, but still mushy.

Another time I reached this point is when I made it possible to not only
sort a table by different columns, but to also select which columns to
display.  The ZPT became an incredible mess.  In this case, I solved the
problem by representing the presentation of the table as an object.  I
still used ZPT, but the work it had to do was simple.  It even renders
more quickly.

But the more common case is a template with just one or two spots of ugly 
logic.  We need a better way to refactor those parts.  Unfortunately, 
since I realized my suggestion has a namespace problem, I don't have a 
solution.

Shane

From philipp at weitershausen.de  Wed Feb 11 11:50:44 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Wed Feb 11 11:44:02 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <4026BD5D.9050205@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org> <402652C1.9070200@weitershausen.de>
	<4026BD5D.9050205@zope.com>
Message-ID: <402A5D64.1080907@weitershausen.de>

Jim Fulton wrote:
>> Comments are appreciated, as well as help chasing down the last test 
>> failures and fixing the modulealias.
> 
> As I mentioend earlier, I don't want zope.products.content and
> zope.products.codecontent.  Please split these into top-level packages
> in zope.products:
> 
>   zope.products.zptpage,
>   zope.products.dtmlpage,
>   zope.products,sqlscript,
>   zope.products,file,
>   zope.products.i18nfile
>   zope.products,image,
>   zope.products.i18nimage

Done. It's all in the 'philikon-movecontent-branch'. All unit tests 
pass, Z3 starts up and the content types seem to work normally (except 
for I18nFile which seems like a configuration bug; I'm on it).

I still haven't made advancements with the functional tests.

> Before we have you do much more work, I think it would be
> a good idea to step back and work out the new treee as we did for
> namegeddon.
> 
> I suggest doing this on a wiki page.

See http://dev.zope.org/Zope3/PackageGeddon

Philipp


From shane at zope.com  Wed Feb 11 11:46:08 2004
From: shane at zope.com (Shane Hathaway)
Date: Wed Feb 11 11:46:17 2004
Subject: [Zope3-dev] Inline code
In-Reply-To: <Pine.LNX.4.50.0402110948260.18607-100000@shane.zope.com>
References: <20040210170330.4881541c.casey@zope.com>
	<Pine.LNX.4.50.0402110948260.18607-100000@shane.zope.com>
Message-ID: <Pine.LNX.4.50.0402111144370.18607-100000@shane.zope.com>

On Wed, 11 Feb 2004, Shane Hathaway wrote:

> Eventually, I the logic into CSS and Javascript.  This strategy made the

Make that "Eventually, I moved the logic"...

:-)

Shane

From philipp at weitershausen.de  Wed Feb 11 12:29:06 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Wed Feb 11 12:22:25 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <402A5D64.1080907@weitershausen.de>
References: <bvr8od$o8u$1@sea.gmane.org>
	<402652C1.9070200@weitershausen.de>	<4026BD5D.9050205@zope.com>
	<402A5D64.1080907@weitershausen.de>
Message-ID: <402A6662.50002@weitershausen.de>

Philipp von Weitershausen wrote:
> I still haven't made advancements with the functional tests.

I take that back. All functional tests but one are passing now (and I 
don't understand why the remaining fails). Note that for one test I had 
to import from zope.products.zptpage to make it work. :(.

Philipp


From jim at zope.com  Wed Feb 11 15:49:42 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Feb 11 15:50:41 2004
Subject: [Zope3-dev] Re: What don't file-system-based developers need
In-Reply-To: <402A22A2.3050506@weitershausen.de>
References: <40298CCA.4040806@zope.com> <402A22A2.3050506@weitershausen.de>
Message-ID: <402A9566.1070701@zope.com>

Philipp von Weitershausen wrote:
> Jim Fulton wrote:
> 


...

>> - SQL scripts?
> 
> 
> If you're referring to the content objects, then I wouldn't need them. 
> But that's probably I dislike their concept anyway (as much as I dislike 
> ZPT Page and DTML Page).

Do we have a file-system-based flavor of these?


>> - Catalogs?
> 
> 
> I dislike the Catalog as a content object. Has that changed now? I 
> remember seeing a checkin of some sort. I'd be glad if it is a local 
> utility now.

It's both.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From Mailer-Daemon at python.org  Wed Feb 11 15:59:44 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Wed Feb 11 15:59:46 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1Ar1SS-00063z-TG@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1Ar1Rd-00059b-S2; Wed, 11 Feb 2004 15:58:53 -0500
From: zope3-dev@zope.org (jim)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [PackageGeddon] This proposal is too small
Message-ID: <20040211155853EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Wed, 11 Feb 2004 15:58:53 -0500
X-Spam-Status: OK (default 0.000)

++added:

>From jim Wed Feb 11 15:58:00 US/Eastern 2004 From: jim Date:
2004/02/11 15:58 EST Subject: This proposal is too small Message-ID:
<20040211155851EST@dev.zope.org>

A major problem that you haven't addressed is that zope.app is too
deep. There is too much structure and the structure gets in the way.

To be honest, the more I think about it, the less I think that the
distinction between zope.app and zope.products is important. It's just
one classification among many. I think that having a really flat
organization will point this out.
--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PackageGeddon

From Mailer-Daemon at python.org  Wed Feb 11 16:14:58 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Wed Feb 11 16:15:02 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1Ar1hC-00015c-Nm@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1Ar1gW-0008Vx-7i; Wed, 11 Feb 2004 16:14:16 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [DevelCookbook] removed another recipe which I think is not necessary
Message-ID: <20040211161416EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Wed, 11 Feb 2004 16:14:16 -0500
X-Spam-Status: OK (default 0.001)

--removed:
-       06. Application Security Audit (SecurityAudit) - Even though Zope 3
-           provided great facilities to ensure security, the application can
-	   be only secure, if the developer knows how to use these tools an
-           how to look out for them. This recipe introduces the most common
-           issues. (4 pages)
-

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook

From jim at zope.com  Wed Feb 11 16:30:40 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Feb 11 16:31:22 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <402A5D64.1080907@weitershausen.de>
References: <bvr8od$o8u$1@sea.gmane.org> <402652C1.9070200@weitershausen.de>
	<4026BD5D.9050205@zope.com> <402A5D64.1080907@weitershausen.de>
Message-ID: <402A9F00.6060702@zope.com>

Philipp von Weitershausen wrote:

...

> See http://dev.zope.org/Zope3/PackageGeddon

I'm thinking of something much bigger. This hardly qualifies as a geddon. :)

The main problem I see is that that the existing structure is too deep.
I want a drastic flattening of the structure.  I'll work up a cut at this
on the way home.  This will leave zope.app and zope.products very broad
and shallow.

Further, given a flat structure, I'm not sure that the distinction
between zope.app and zope.products will be that useful any more.
I need to think more about this, but I suspect we may want a more fluid
organization that isn't chisseled into the directory structure. This relates
to Jeffrey's (and, in the past, Kapil's and more recently Tres') remarks
about packaging.  Perhaps the dependencies and individual configurations
should be dealt with at a higher level.  As I said, I need to think about this.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From philipp at weitershausen.de  Thu Feb 12 07:38:38 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Thu Feb 12 07:31:57 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <402A9F00.6060702@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org> <402652C1.9070200@weitershausen.de>
	<4026BD5D.9050205@zope.com> <402A5D64.1080907@weitershausen.de>
	<402A9F00.6060702@zope.com>
Message-ID: <402B73CE.9040609@weitershausen.de>

Jim Fulton wrote:
>> See http://dev.zope.org/Zope3/PackageGeddon
> 
> I'm thinking of something much bigger. This hardly qualifies as a 
> geddon. :)

Well, taking core packages out of zope.app is a pretty big thing to me. 
And believe me, moving zope.app.content was not just a matter of cvs 
remove and cvs add... :)

> The main problem I see is that that the existing structure is too deep.
> I want a drastic flattening of the structure.  I'll work up a cut at this
> on the way home.  This will leave zope.app and zope.products very broad
> and shallow.

Well, you're right, I'm not covering flattening the structure in 
zope.app. That's mainly because I have no idea where you are on this 
subject, and from what you're writing me now, I guess you don't know 
either yet :).

> Further, given a flat structure, I'm not sure that the distinction
> between zope.app and zope.products will be that useful any more.
> I need to think more about this, but I suspect we may want a more fluid
> organization that isn't chisseled into the directory structure. This 
> relates
> to Jeffrey's (and, in the past, Kapil's and more recently Tres') remarks
> about packaging.  Perhaps the dependencies and individual configurations
> should be dealt with at a higher level.  As I said, I need to think 
> about this.

This is how I think about it:

- zope.app contains too much optional stuff. That stuff needs to go to 
zope.products

- zope.app is too deep, so it needs to be flattened. I think treating 
subpackages of zope.app as independent packages with their own 
interfaces and browser packages is the way to go.

- Packages in zope.app have loads of dependencies on each other. 
Especially the tests insanely depend on other packages. Moving optional 
stuff out and flattening zope.app will automatically reduce some of 
that. We can also take this as an opportunity to de-spaghetti-fy 
dependencies...

Philipp


From philipp at weitershausen.de  Thu Feb 12 07:54:15 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Thu Feb 12 07:47:30 2004
Subject: [Zope3-dev] Re: What don't file-system-based developers need
In-Reply-To: <402A9566.1070701@zope.com>
References: <40298CCA.4040806@zope.com> <402A22A2.3050506@weitershausen.de>
	<402A9566.1070701@zope.com>
Message-ID: <402B7777.7030109@weitershausen.de>

Jim Fulton wrote:
>> If you're referring to the content objects, then I wouldn't need them. 
>> But that's probably I dislike their concept anyway (as much as I 
>> dislike ZPT Page and DTML Page).
> 
> Do we have a file-system-based flavor of these?

No, and I don't think that would be necessary. Scripters use SQLScripts 
and SQLExpressions TTW. File-system developers would probably use 
SQLObjects. Sidnei uses that, for example. I think he has a 
'sqlobjectsupport' product to bind them into Zope3. Don't know where 
that is, though... (wink at dreamcatcher ;)).

Philipp


From sidnei at awkly.org  Thu Feb 12 09:05:53 2004
From: sidnei at awkly.org (Sidnei da Silva)
Date: Thu Feb 12 09:06:39 2004
Subject: [Zope3-dev] Re: What don't file-system-based developers need
In-Reply-To: <402B7777.7030109@weitershausen.de>
References: <40298CCA.4040806@zope.com> <402A22A2.3050506@weitershausen.de>
	<402A9566.1070701@zope.com> <402B7777.7030109@weitershausen.de>
Message-ID: <20040212140553.GE11402@moria.redesul.com.br>

On Thu, Feb 12, 2004 at 01:54:15PM +0100, Philipp von Weitershausen wrote:
| Jim Fulton wrote:
| >>If you're referring to the content objects, then I wouldn't need them. 
| >>But that's probably I dislike their concept anyway (as much as I 
| >>dislike ZPT Page and DTML Page).
| >
| >Do we have a file-system-based flavor of these?
| 
| No, and I don't think that would be necessary. Scripters use SQLScripts 
| and SQLExpressions TTW. File-system developers would probably use 
| SQLObjects. Sidnei uses that, for example. I think he has a 
| 'sqlobjectsupport' product to bind them into Zope3. Don't know where 
| that is, though... (wink at dreamcatcher ;)).

Coming out on the next weeks, once we figure out the license.

-- 
Sidnei da Silva <sidnei@awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher

User hostile.

From tseaver at zope.com  Thu Feb 12 10:25:14 2004
From: tseaver at zope.com (Tres Seaver)
Date: Thu Feb 12 10:25:20 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <402B73CE.9040609@weitershausen.de>
References: <bvr8od$o8u$1@sea.gmane.org>
	<402652C1.9070200@weitershausen.de>	<4026BD5D.9050205@zope.com>
	<402A5D64.1080907@weitershausen.de>	<402A9F00.6060702@zope.com>
	<402B73CE.9040609@weitershausen.de>
Message-ID: <402B9ADA.40509@zope.com>

Philipp von Weitershausen wrote:

> - Packages in zope.app have loads of dependencies on each other. 
> Especially the tests insanely depend on other packages. Moving optional 
> stuff out and flattening zope.app will automatically reduce some of 
> that. We can also take this as an opportunity to de-spaghetti-fy 
> dependencies...

We are definitely at a now-or-never point about this.  As a conceptual 
exercise, imaging packaging Zope as follows:

   1) Zope is distributed as a single, monolithic chunk (all that
      "dependency spaghetti" will allow).

   2) Each product and subsection of zope.app is packaged as a separate,
      loosely coupled package (RPMs, .deb's, whatever) *with explicitly-
      identified dependencies on the others.*

The first scenario makes the "what is in the core?" question crucial; 
the second allows different "super-packages" to be created to suit 
different needs (e.g., my "filesystem-developer only" distro would not
preclude a separate "ttw-devel-and-the-kitchen-sink" distro).  Given 
that the two best-known package systems (.deb / .rpm) can both do 
dependency resolution (rpm + apt or yum, anyway), the major advantage of 
the monolithic strategy ("batteries included") is reduced.

Packaging for Windows and platforms without such dependency resolution 
remains thornier;  nonetheless, I think we should attempt the "fine 
grained" mdel.  From this POV, it should be a goal of PackageGeddon both 
to identify *and to reduce* such interpackage dependencies.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com


From steve at z3u.com  Thu Feb 12 11:07:33 2004
From: steve at z3u.com (Steve Alexander)
Date: Thu Feb 12 11:07:38 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <402B9ADA.40509@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org>	<402652C1.9070200@weitershausen.de>	<4026BD5D.9050205@zope.com>	<402A5D64.1080907@weitershausen.de>	<402A9F00.6060702@zope.com>	<402B73CE.9040609@weitershausen.de>
	<402B9ADA.40509@zope.com>
Message-ID: <402BA4C5.6090802@z3u.com>


> Packaging for Windows and platforms without such dependency resolution 
> remains thornier;  nonetheless, I think we should attempt the "fine 
> grained" mdel.  From this POV, it should be a goal of PackageGeddon both 
> to identify *and to reduce* such interpackage dependencies.

+1

Perhaps tests that aren't unit tests (or rather, tests that have 
cross-package dependencies) can be put into a separate package, that 
depends on the two or more packages that are involved in the tests?

We could have an itests container package for all such test modules.

--
Steve Alexander


From jeff at bottlerocket.net  Thu Feb 12 13:07:58 2004
From: jeff at bottlerocket.net (Jeffrey P Shell)
Date: Thu Feb 12 13:10:58 2004
Subject: [Zope3-dev] Re: What don't file-system-based developers need
In-Reply-To: <402B7777.7030109@weitershausen.de>
References: <40298CCA.4040806@zope.com> <402A22A2.3050506@weitershausen.de>
	<402A9566.1070701@zope.com> <402B7777.7030109@weitershausen.de>
Message-ID: <63478166-5D86-11D8-B781-003065415378@bottlerocket.net>

On Feb 12, 2004, at 5:54 AM, Philipp von Weitershausen wrote:

> Jim Fulton wrote:
>>> If you're referring to the content objects, then I wouldn't need 
>>> them. But that's probably I dislike their concept anyway (as much as 
>>> I dislike ZPT Page and DTML Page).
>> Do we have a file-system-based flavor of these?
>
> No, and I don't think that would be necessary. Scripters use 
> SQLScripts and SQLExpressions TTW. File-system developers would 
> probably use SQLObjects. Sidnei uses that, for example. I think he has 
> a 'sqlobjectsupport' product to bind them into Zope3. Don't know where 
> that is, though... (wink at dreamcatcher ;)).

Would probably use them, but not always.  I've become disillusioned 
with O-R Mapping, and there are definitely times when - NOT AS A 
SCRIPTER - I still need to use fairly plain SQL.

I've been doing this in file system development in Zope 2 by doing:

from Products.ZSQLMethods.SQL import SQL as SQLMethod
DBNAME = 'dbc'         #name of Database Adapter

class Frobnitz(...):
	listUpcomingShows = SQLMethod(
		'listUpcomingShows', '', DBNAME,
		'max_date=""',
		""" <SQL Method Code Here> """,
		)

We're moving to our own data management framework anyways, but there 
are still situations where:

- I need to do complex queries.
- I don't want the overhead of O-R Mapping (shocking, considering how 
much I used
   to want it).
- I do want Zope to manage the database connections and transactions 
automatically.
   (it's been nice, for example, to not have to worry about threads and 
all that -
   just query your adapter and run with it).

I'd like to have the latter, even if I don't have something akin to SQL 
Methods.  I just want a [service|utility] that I can configure and then 
send SQL Statements to and get result objects back from.  The DTML SQL 
tags are nice, but I could live without them.


From LBerezhny at DevIS.com  Thu Feb 12 13:25:55 2004
From: LBerezhny at DevIS.com (Lex Berezhny)
Date: Thu Feb 12 13:26:05 2004
Subject: [Zope3-dev] Re: What don't file-system-based developers need
In-Reply-To: <63478166-5D86-11D8-B781-003065415378@bottlerocket.net>
References: <40298CCA.4040806@zope.com> <402A22A2.3050506@weitershausen.de>
	<402A9566.1070701@zope.com> <402B7777.7030109@weitershausen.de>
	<63478166-5D86-11D8-B781-003065415378@bottlerocket.net>
Message-ID: <1076610355.9093.5.camel@hortus>

On Thu, 2004-02-12 at 12:07, Jeffrey P Shell wrote:
> On Feb 12, 2004, at 5:54 AM, Philipp von Weitershausen wrote:
> 
> > No, and I don't think that would be necessary. Scripters use 
> > SQLScripts and SQLExpressions TTW. File-system developers would 
> > probably use SQLObjects. Sidnei uses that, for example. I think he has 
> > a 'sqlobjectsupport' product to bind them into Zope3. Don't know where 
> > that is, though... (wink at dreamcatcher ;)).
> 
> Would probably use them, but not always.  I've become disillusioned 
> with O-R Mapping, and there are definitely times when - NOT AS A 
> SCRIPTER - I still need to use fairly plain SQL.

+1

> I'd like to have the latter, even if I don't have something akin to SQL 
> Methods.  I just want a [service|utility] that I can configure and then 
> send SQL Statements to and get result objects back from.  The DTML SQL 
> tags are nice, but I could live without them.

+1


From faassen at infrae.com  Thu Feb 12 14:36:25 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Thu Feb 12 14:38:09 2004
Subject: [Zope3-dev] What don't file-system-based developers need
In-Reply-To: <40298CCA.4040806@zope.com>
References: <40298CCA.4040806@zope.com>
Message-ID: <20040212193625.GA799@vet.uu.nl>

Jim Fulton wrote:
> 
> If we decode that the next release is for file-system-based developers,
> I wonder what they need.  I'm particularly interested in getting input
> from folks who've already been creating production applications with
> Zope 3.

Obviously filesystem based developers *could* find productive use
for any of what's listed below, except possibly SQL scripts as they
seem to be geared towards TTW developers.

I think we need to reason from Zope 3's ability to deliver certain 
features within a reasonable timeframe more than Zope 3 developers's need
for certain infrastructure though, if we want any release happening soon.

So I'd say rip out anything that needs a lot of attention that can't be
spared right now. I suspect most in the list below is not in practical
use by anybody as it isn't mature enough to be useful.

But I guess the intent is just to get actual confirmation of this. :)

(eventually I hope many of the things listed will be maintained by
separate projects altogether, as Zope 3 excels in making this possible)

Regards,

Martijn


From faassen at infrae.com  Thu Feb 12 14:44:56 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Thu Feb 12 14:46:40 2004
Subject: [Zope3-dev] Re: Issue 124 in the collector.
In-Reply-To: <40277BA2.4070003@zope.com>
References: <20040209113519.GA28560@smarties.nutellux.ath.cx>
	<40277BA2.4070003@zope.com>
Message-ID: <20040212194456.GB799@vet.uu.nl>

Tres Seaver wrote:
> Nicolas ?vrard wrote:
> 
> >I've met the issue 124 from the collector again but I found a way around
> >this issue.
> >
> >The Python you're using when running zope3 should have
> >sys.defaultencoding set to 'utf' and not 'ascii'.
> >
> >On my debian system, it's impossible to use sys.setdefaultencoding() so
> >I could not try the patch but it should work.
> 
> Can you edit /path/to/python2.3/site-packges/sitecustomize.py?  That 
> file is the only possible place to change the encoding, I think.
> 
>   $ more /opt/zc/lib/python2.3/site-packages/sitecustomize.py
>   import sys
>   sys.setdefaultencoding('latin-1')

Yes, that's the only possible way to do it; the method gets deleted after
site.py gets run. Of course it's not very useful to require you change this
globally on your system. I very much suspect it'll screw up other packages,
and if you develop with such a thing set other people would need to have
the same setting, etc. I suspect therefore that this thing is fairly useless
if you care about compatibility.

I've missed what the original discussion is about, but if Zope 3 now
requires you change the default encoding in order for it to run
properly then I'd say that's really really bad. :)

Regards,

Martijn


From faassen at infrae.com  Thu Feb 12 14:50:19 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Thu Feb 12 14:52:02 2004
Subject: [Zope3-dev] Re: Issue 124 in the collector.
In-Reply-To: <4027A4F1.3070100@zope.com>
References: <20040209113519.GA28560@smarties.nutellux.ath.cx>
	<40277BA2.4070003@zope.com>
	<20040209134355.GB28560@smarties.nutellux.ath.cx>
	<40279FD1.5030609@zope.com>
	<20040209150522.GC28560@smarties.nutellux.ath.cx>
	<4027A4F1.3070100@zope.com>
Message-ID: <20040212195018.GC799@vet.uu.nl>

Tres Seaver wrote:
> Perhaps we should be lobbying to have Python add a command-line 
> parameter for specifying the default encoding?  /me checks:
> 
>  $ /opt/zc/bin/python -h
>  ...
>  -S     : don't imply 'import site' on initialization
> 
> So, one could run python with -S, and then invoke 
> 'sys.setdefaultencoding("latin-1")' later during Zope startup.

Argh, no, no, really unwise. You'll cut yourself off from the rest
of the Python world during development.

It'd be really bad if I had to force my Python to a certain encoding 
in order for a module to actually work properly, and I couldn't reuse
modules developed under other encoding assumptions..

The way to avoid unicode errors is to religiously unicodize any incoming
data at any boundary with external systems. Then inside your system,
only use unicode (or plain ascii literals, which means no latin 1 characters
in literals).

It's far better to do this right from the start as converting to unicode
is rather hellish. I'm speaking from personal experience; Silva stores
all its information in unicode now, but that wasn't true a year ago.
Zope 2 isn't a very unicode-friendly environment, but friendly enough now.
When I went through this hell last year I made a determination to have 
Zope 3 do it right from the start.

I'm not sure whether we're there yet. There are a few tricky bits with
making sure request data is turned into unicode properly upon input.

Regards,

Martijn


From faassen at infrae.com  Thu Feb 12 14:52:08 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Thu Feb 12 14:53:52 2004
Subject: [Zope3-dev] Issue 124 in the collector.
In-Reply-To: <402864B2.4010508@zope.com>
References: <20040209113519.GA28560@smarties.nutellux.ath.cx>
	<402864B2.4010508@zope.com>
Message-ID: <20040212195208.GD799@vet.uu.nl>

Jim Fulton wrote:
> >The Python you're using when running zope3 should have
> >sys.defaultencoding set to 'utf' and not 'ascii'.
> 
> Absolutely, positively not!
> 
> We will not change the default encoding in Zope 3.  This would
> be a bug magnet.
> 
> Conversion to and from unicode is done by the publishing
> layer.  Application code should always deal with unicode.
> Application code should almost never encode or decode strings.
> If it does, it needs to specify an encoding.

Exactly. :)

In addition, if an application is dealing with other sources of string
data besides the publisher (for instance a relational database, or
a file), the same care should be taken to decode these into unicode before
these enter into your application.

Regards,

Martijn


From faassen at infrae.com  Thu Feb 12 14:52:47 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Thu Feb 12 14:54:30 2004
Subject: [Zope3-dev] Heads Up! Namegeddon 2
In-Reply-To: <4026D19B.5060905@zope.com>
References: <4026D19B.5060905@zope.com>
Message-ID: <20040212195247.GE799@vet.uu.nl>

Jim Fulton wrote:
> I think we are going to decide to have a second and final
> namegeddon before the first release.

What does this namegeddon entail? 

Regards,

Martijn


From faassen at infrae.com  Thu Feb 12 15:02:07 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Thu Feb 12 15:03:51 2004
Subject: [Zope3-dev] Last chance to mess with the source layout of Zope 3
In-Reply-To: <4026BF7B.3050407@zope.com>
References: <4026BF7B.3050407@zope.com>
Message-ID: <20040212200207.GF799@vet.uu.nl>

Hi there,

Ah, this must be what you mean with 'namegeddon' in the another post right?
Though this is more like a 'move-geddon', not so much a renaming geddon,
which was a large component of the previous namegeddon.

Jim Fulton wrote:
> Given that, I'd like to put the layout strategy on the table.
> 
> The last time we did a major reorganization, we separated the presentation
> and interface code from the application code.  This was it make it
> easier for user-interface developers to contribute.  I know of one person
> whih actually liked the separation of presentation and interfaces from
> application code. AFAICT, it's been wildly unpopular for everyone else.
> I'm not sure that the people it was done for have even been all that 
> involved.

Right, doesn't seem to have been working out, unfortunately. In part I
suspect the right people didn't get involved, and in part because Zope 3's
hierarchy is too deep so it's really hard on developers.

> A few people have been working on UI, but I don't think they consider 
> themselves UI folk and I bet they don't like the separation.
> 
> In a separate note, I suggested a much flatter layout.

Flatter layout +1. This in itself should eliminate much of the issue
with deeply nested separate interface trees and browser trees. 

> I suggested
> getting rid of zope.app.browser (and the like) and zope.app.interafces.
> I suggested that zope.app have top-level packages in it that are pretty
> self-contained with their own interfaces.py and browser.py (and etc.).

+1

Note that these packages can still grow an interfaces sub-package or
browser sub-package when they become larger. If they're self-contained
they're in effect 'extensions' to the Zope 3 core, and what you're proposing
is very similar to what you'd be doing with a Zope 3 extension already
*under the current naming scheme*. :)

I still am uneasy that this exercise will scatter .pt files across
the system so that layout developers can't find a grip on them, but
since the aim of Zope 3 1.0 has shifted to developers and since the
difference is not unsurmountable with regular naming (look for .pt files,
look for browser.py), this uneasiness isn't well founded. :)

> A variation on this would be to provide separate UI packages
> (e.g, zope.app.folder and zope.app.folderweb).

-1 to folderweb like everybody else.

Regards,

Martijn


From srichter at cosmos.phy.tufts.edu  Thu Feb 12 15:13:22 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Thu Feb 12 15:13:30 2004
Subject: [Zope3-dev] Last chance to mess with the source layout of Zope 3
In-Reply-To: <20040212200207.GF799@vet.uu.nl>
References: <4026BF7B.3050407@zope.com> <20040212200207.GF799@vet.uu.nl>
Message-ID: <200402121513.23184.srichter@cosmos.phy.tufts.edu>

On Thursday 12 February 2004 15:02, Martijn Faassen wrote:
> Note that these packages can still grow an interfaces sub-package or
> browser sub-package when they become larger.

Yes, this is how I develop Zope 3 products these days. If the browser code is 
minimal and has only 1-2 templates I use browser.py otherwise I am shifting 
to a directory browser, but usually leave the views in __init__.py, so that 
the imports don't change.

Also, I have recently started to move implementation of interfaces to 
__init__.py as well. For example a simple content object like "File" would 
look like:

zope/products/file
  __init__.py --> File
  interfaces.py --> IFile
  browser.py --> FileEditView

Note how nice the imports are:

from zope.products.file import File
from zope.products.file.interfaces import IFile
from zope.products.file.browser import FileEditView

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From srichter at cosmos.phy.tufts.edu  Thu Feb 12 15:19:36 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Thu Feb 12 15:19:41 2004
Subject: [Zope3-dev] Re: What don't file-system-based developers need
In-Reply-To: <63478166-5D86-11D8-B781-003065415378@bottlerocket.net>
References: <40298CCA.4040806@zope.com> <402B7777.7030109@weitershausen.de>
	<63478166-5D86-11D8-B781-003065415378@bottlerocket.net>
Message-ID: <200402121519.36096.srichter@cosmos.phy.tufts.edu>

On Thursday 12 February 2004 13:07, Jeffrey P Shell wrote:
> I'd like to have the latter, even if I don't have something akin to SQL
> Methods. ?I just want a [service|utility] that I can configure and then
> send SQL Statements to and get result objects back from. ?The DTML SQL
> tags are nice, but I could live without them.

Check out zope/app/rdb/__init__.py. In there, there is a method (that is also 
used by SQLScript) called queryForResults(connection, query). So you pass in 
a connection and your query and out comes a result set in the usual Zope (2 
and 3) format. 

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From srichter at cosmos.phy.tufts.edu  Thu Feb 12 15:28:21 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Thu Feb 12 15:28:28 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <402BA4C5.6090802@z3u.com>
References: <bvr8od$o8u$1@sea.gmane.org> <402B9ADA.40509@zope.com>
	<402BA4C5.6090802@z3u.com>
Message-ID: <200402121528.21537.srichter@cosmos.phy.tufts.edu>

On Thursday 12 February 2004 11:07, Steve Alexander wrote:
> > Packaging for Windows and platforms without such dependency resolution
> > remains thornier; ?nonetheless, I think we should attempt the "fine
> > grained" mdel. ?From this POV, it should be a goal of PackageGeddon both
> > to identify *and to reduce* such interpackage dependencies.
>
> +1
>
> Perhaps tests that aren't unit tests (or rather, tests that have
> cross-package dependencies) can be put into a separate package, that
> depends on the two or more packages that are involved in the tests?
>
> We could have an itests container package for all such test modules.

I think this mess comes from not differentiating unit tests from regression 
tests (if I understand XP correctly).

- unit tests: They should never depend on other packages. They should 
definitely live in the package and be self-contained.

- regression tests: depend on a well-defined set of other packages. Note 
though that often these packages are often required for the entire product 
anyway. So they could still live in the package. If there is a dependency in 
the tests that does not exist in the implementation in general, we should be 
able to rewrite the test, so that it has no dependencies.

- functional tests: They will always depend on other components. Heck, their 
entire reason of existence is to test a fully functional environment.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From srichter at cosmos.phy.tufts.edu  Thu Feb 12 15:29:21 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Thu Feb 12 15:29:29 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <402B9ADA.40509@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org> <402B73CE.9040609@weitershausen.de>
	<402B9ADA.40509@zope.com>
Message-ID: <200402121529.21969.srichter@cosmos.phy.tufts.edu>

On Thursday 12 February 2004 10:25, Tres Seaver wrote:
> ? ?2) Each product and subsection of zope.app is packaged as a separate,
> ? ? ? loosely coupled package (RPMs, .deb's, whatever) *with explicitly-
> ? ? ? identified dependencies on the others.*

Yeah, that would be nice. Maybe we can use distutils or some other framework 
to specify the requirements.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From fred at zope.com  Thu Feb 12 17:03:22 2004
From: fred at zope.com (Fred Drake)
Date: Thu Feb 12 17:03:34 2004
Subject: [Zope3-dev] One possibility for 1.0
In-Reply-To: <200402071837.44347.srichter@cosmos.phy.tufts.edu>
References: <402573CA.9030409@zope.com>
	<200402071837.44347.srichter@cosmos.phy.tufts.edu>
Message-ID: <200402121703.22760.fred@zope.com>

On Saturday 07 February 2004 06:37 pm, Stephan Richter wrote:
 > Yes, I agree with that based on your previous message. I can always make
 > a experimental TTW-enabled release, like "1.0+TTW" for people who want
 > to try it and give feedback. Zope 3 1.0 will get a lot of attention, and

Actually, it would be really nice if the TTW package was really a second 
package that intergrated with the first only through a ZCML <include/>, and 
not a complete Zope 3 Core+TTW distro.  I think that would help make it 
very clear that the dependency relationship is one-way.

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation


From srichter at cosmos.phy.tufts.edu  Thu Feb 12 17:07:08 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Thu Feb 12 17:07:14 2004
Subject: [Zope3-dev] One possibility for 1.0
In-Reply-To: <200402121703.22760.fred@zope.com>
References: <402573CA.9030409@zope.com>
	<200402071837.44347.srichter@cosmos.phy.tufts.edu>
	<200402121703.22760.fred@zope.com>
Message-ID: <200402121707.08888.srichter@cosmos.phy.tufts.edu>

On Thursday 12 February 2004 17:03, Fred Drake wrote:
> On Saturday 07 February 2004 06:37 pm, Stephan Richter wrote:
> ?> Yes, I agree with that based on your previous message. I can always make
> ?> a experimental TTW-enabled release, like "1.0+TTW" for people who want
> ?> to try it and give feedback. Zope 3 1.0 will get a lot of attention, and
>
> Actually, it would be really nice if the TTW package was really a second
> package that intergrated with the first only through a ZCML <include/>, and
> not a complete Zope 3 Core+TTW distro. ?I think that would help make it
> very clear that the dependency relationship is one-way.

+1 
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From fred at zope.com  Thu Feb 12 17:07:06 2004
From: fred at zope.com (Fred Drake)
Date: Thu Feb 12 17:07:24 2004
Subject: [Zope3-dev] widget question: propertyNames/getValue
In-Reply-To: <4025850C.5030901@zope.com>
References: <FB37E9B9E9354A4788F1B322E4AAD1D880A4@server1.mojave.local>
	<4025850C.5030901@zope.com>
Message-ID: <200402121707.06805.fred@zope.com>

Garrett Smith wrote:
 > I'm trying to make sense of propertyNames in the widget facility. From
 > what I can see, propertyNames and getValue can be removed from IWidget

On Saturday 07 February 2004 07:38 pm, Jim Fulton wrote:
 > My opinion is that widgets should implement schemas that describe their
 > configuration data, which are exposed via attributes.

So there's no need to hold on to the existing propertyNames/getValue cruft.  
Let's ditch those now!  Adding a simple base widget schema would be nice, 
but doesn't seem necessary.  I'd be just as happy to say all of that is 
implementation and not part of the interface.


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation


From gary at modernsongs.com  Thu Feb 12 17:40:42 2004
From: gary at modernsongs.com (Gary Poster)
Date: Thu Feb 12 17:40:49 2004
Subject: [Zope3-dev] widget question: propertyNames/getValue
In-Reply-To: <200402121707.06805.fred@zope.com>
References: <FB37E9B9E9354A4788F1B322E4AAD1D880A4@server1.mojave.local>	<4025850C.5030901@zope.com>
	<200402121707.06805.fred@zope.com>
Message-ID: <402C00EA.7040708@modernsongs.com>

I'd really like a schema of the configurables, though, because then we 
could make zcml do one of those "if I don't know the attribute I'll try 
to see if the widget class's schema knows about it, and use it to cast 
the zcml value" tricks.  You know, one of those.  :-)  So we could have
<addform ...>
   <widget class=".widgets.DatePicker" format="%Y-%m-%d" />
</addform>

where format is cast as appropriate, as defined in the widget 
configuration schema (ok, it's easy in this case, but you see what I 
mean), and then CustomWidgetFactory is called with the class, setting 
the format.

That would be nice.  Generating a view class on the file system just to 
make my text field display at 50 characters wide feels overly heavy to me.

Gary

Fred Drake wrote:
> Garrett Smith wrote:
>  > I'm trying to make sense of propertyNames in the widget facility. From
>  > what I can see, propertyNames and getValue can be removed from IWidget
> 
> On Saturday 07 February 2004 07:38 pm, Jim Fulton wrote:
>  > My opinion is that widgets should implement schemas that describe their
>  > configuration data, which are exposed via attributes.
> 
> So there's no need to hold on to the existing propertyNames/getValue cruft.  
> Let's ditch those now!  Adding a simple base widget schema would be nice, 
> but doesn't seem necessary.  I'd be just as happy to say all of that is 
> implementation and not part of the interface.
> 
> 
>   -Fred
> 

From fred at zope.com  Thu Feb 12 17:45:23 2004
From: fred at zope.com (Fred Drake)
Date: Thu Feb 12 17:45:33 2004
Subject: [Zope3-dev] widget question: propertyNames/getValue
In-Reply-To: <402C00EA.7040708@modernsongs.com>
References: <FB37E9B9E9354A4788F1B322E4AAD1D880A4@server1.mojave.local>
	<200402121707.06805.fred@zope.com>
	<402C00EA.7040708@modernsongs.com>
Message-ID: <200402121745.23373.fred@zope.com>

On Thursday 12 February 2004 05:40 pm, Gary Poster wrote:
 > I'd really like a schema of the configurables, though, because then we
 > could make zcml do one of those "if I don't know the attribute I'll try
 > to see if the widget class's schema knows about it, and use it to cast
 > the zcml value" tricks.  You know, one of those.  :-)  So we could have
 > <addform ...>
 >    <widget class=".widgets.DatePicker" format="%Y-%m-%d" />
 > </addform>

That would be really nice.

Since the current propertyNames/getValue mess doesn't help with that, Garret 
can go ahead and rip out that cruft, and you can write the schema and ZCML 
magic.  ;-)

I think these are still two independent tasks.  Both should be done, but 
cleaning out the cruft we don't like shouldn't be held up waiting for the 
new feature.


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation


From gary at modernsongs.com  Thu Feb 12 17:47:19 2004
From: gary at modernsongs.com (Gary Poster)
Date: Thu Feb 12 17:47:26 2004
Subject: [Zope3-dev] widget question: propertyNames/getValue
In-Reply-To: <200402121745.23373.fred@zope.com>
References: <FB37E9B9E9354A4788F1B322E4AAD1D880A4@server1.mojave.local>	<200402121707.06805.fred@zope.com>	<402C00EA.7040708@modernsongs.com>
	<200402121745.23373.fred@zope.com>
Message-ID: <402C0277.6080007@modernsongs.com>

agreed. ;-)

Gary

Fred Drake wrote:
> On Thursday 12 February 2004 05:40 pm, Gary Poster wrote:
>  > I'd really like a schema of the configurables, though, because then we
>  > could make zcml do one of those "if I don't know the attribute I'll try
>  > to see if the widget class's schema knows about it, and use it to cast
>  > the zcml value" tricks.  You know, one of those.  :-)  So we could have
>  > <addform ...>
>  >    <widget class=".widgets.DatePicker" format="%Y-%m-%d" />
>  > </addform>
> 
> That would be really nice.
> 
> Since the current propertyNames/getValue mess doesn't help with that, Garret 
> can go ahead and rip out that cruft, and you can write the schema and ZCML 
> magic.  ;-)
> 
> I think these are still two independent tasks.  Both should be done, but 
> cleaning out the cruft we don't like shouldn't be held up waiting for the 
> new feature.
> 
> 
>   -Fred
> 

From philipp at weitershausen.de  Fri Feb 13 05:09:03 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Fri Feb 13 05:02:25 2004
Subject: [Zope3-dev] Re: What don't file-system-based developers need
In-Reply-To: <63478166-5D86-11D8-B781-003065415378@bottlerocket.net>
References: <40298CCA.4040806@zope.com> <402A22A2.3050506@weitershausen.de>
	<402A9566.1070701@zope.com> <402B7777.7030109@weitershausen.de>
	<63478166-5D86-11D8-B781-003065415378@bottlerocket.net>
Message-ID: <402CA23F.30400@weitershausen.de>

Jeffrey P Shell wrote:
> Would probably use them, but not always.  I've become disillusioned with 
> O-R Mapping, and there are definitely times when - NOT AS A SCRIPTER - I 
> still need to use fairly plain SQL.

I understand that. O-R Mappings can be a bit overhead some time.

> I've been doing this in file system development in Zope 2 by doing:
> 
> from Products.ZSQLMethods.SQL import SQL as SQLMethod

from zope.products.sqlscript.sqlscript import SQLScript

(that's if you're in philikon-movecontent-branch. in HEAD you'd do
from zope.app.content.sql import SQLScript)

> DBNAME = 'dbc'         #name of Database Adapter
> 
> class Frobnitz(...):
>     listUpcomingShows = SQLMethod(
>         'listUpcomingShows', '', DBNAME,
>         'max_date=""',
>         """ <SQL Method Code Here> """,
>         )

Should work the same way with SQLScript.

> I'd like to have the latter, even if I don't have something akin to SQL 
> Methods.  I just want a [service|utility] that I can configure and then 
> send SQL Statements to and get result objects back from.

Well, you can still talk to the SQL adapter (a utility) yourself::

   from zope.app.interfaces.rdb import IZopeDatabaseAdapter
   from zope.app.rdb import queryForResults

   query = "SELECT %(columns)s FROM %(table)s" % parameter_dict
   connection = zapi.getUtility(context, IZopeDatabaseAdapter, DBNAME)
   result = queryForResults(connection, query)

SQLScript has the advantage that it can cache results just like SQLMethods.

> The DTML SQL  tags are nice, but I could live without them.

They are supported by SQLScript.

I guess the answer to whether we have a file-system flavour of SQLScript 
is "No, but you can use them from the file-system like SQLMethods back 
in Zope 2"...

Philipp


From faassen at infrae.com  Fri Feb 13 05:08:23 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Fri Feb 13 05:10:08 2004
Subject: [Zope3-dev] Last chance to mess with the source layout of Zope 3
In-Reply-To: <200402121513.23184.srichter@cosmos.phy.tufts.edu>
References: <4026BF7B.3050407@zope.com> <20040212200207.GF799@vet.uu.nl>
	<200402121513.23184.srichter@cosmos.phy.tufts.edu>
Message-ID: <20040213100823.GA2974@vet.uu.nl>

Stephan Richter wrote:
> Yes, this is how I develop Zope 3 products these days. If the browser code is 
> minimal and has only 1-2 templates I use browser.py otherwise I am shifting 
> to a directory browser, but usually leave the views in __init__.py, so that 
> the imports don't change.

Putting stuff in __init__.py... Why don't you use modules and 'from .. import'
the views into __init__.py if you want to do this? Much cleaner.

> Also, I have recently started to move implementation of interfaces to 
> __init__.py as well.

Putting a ton of stuff into __init__.py sounds like bad practice to me.
It's very easily avoided by placing a few 'from .. import' statements in your
__init__.py and doing the rest in a module where they belong.

Regards,

Martijn


From philipp at weitershausen.de  Fri Feb 13 05:20:54 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Fri Feb 13 05:14:14 2004
Subject: [Zope3-dev] Re: Heads Up! Namegeddon 2
In-Reply-To: <20040212195247.GE799@vet.uu.nl>
References: <4026D19B.5060905@zope.com> <20040212195247.GE799@vet.uu.nl>
Message-ID: <402CA506.8010601@weitershausen.de>

Martijn Faassen wrote:
> Jim Fulton wrote:
> 
>>I think we are going to decide to have a second and final
>>namegeddon before the first release.
> 
> What does this namegeddon entail? 

It's really a packagegeddon.
http://dev.zope.org/Zope3/PackageGeddon

Philipp


From peter at sabaini.at  Fri Feb 13 06:17:45 2004
From: peter at sabaini.at (Peter Sabaini)
Date: Fri Feb 13 06:17:50 2004
Subject: [Zope3-dev] Re: What don't file-system-based developers need
In-Reply-To: <402CA23F.30400@weitershausen.de>
References: <40298CCA.4040806@zope.com>
	<402A22A2.3050506@weitershausen.de>	<402A9566.1070701@zope.com>
	<402B7777.7030109@weitershausen.de>	<63478166-5D86-11D8-B781-003065415378@bottlerocket.net>
	<402CA23F.30400@weitershausen.de>
Message-ID: <402CB259.1020409@sabaini.at>

Philipp von Weitershausen wrote:
> Jeffrey P Shell wrote:
> 
>> Would probably use them, but not always.  I've become disillusioned 
>> with O-R Mapping, and there are definitely times when - NOT AS A 
>> SCRIPTER - I still need to use fairly plain SQL.
> 
> 
> I understand that. O-R Mappings can be a bit overhead some time.

Oh well one can always try to do it right *this* time :-)

>> I've been doing this in file system development in Zope 2 by doing:
>>
>> from Products.ZSQLMethods.SQL import SQL as SQLMethod
> 
> 
> from zope.products.sqlscript.sqlscript import SQLScript

Great to hear that; for day to day RDBMS connectivity thats all I need.

[snip]

Thanks,
peter.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3461 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20040213/c14023e4/smime-0001.bin
From philipp at weitershausen.de  Fri Feb 13 06:57:58 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Fri Feb 13 06:51:20 2004
Subject: [Zope3-dev] Re: Moving more stuff to zope.products
In-Reply-To: <402B9ADA.40509@zope.com>
References: <bvr8od$o8u$1@sea.gmane.org>
	<402652C1.9070200@weitershausen.de>	<4026BD5D.9050205@zope.com>
	<402A5D64.1080907@weitershausen.de>	<402A9F00.6060702@zope.com>
	<402B73CE.9040609@weitershausen.de> <402B9ADA.40509@zope.com>
Message-ID: <402CBBC6.6060503@weitershausen.de>

Tres Seaver wrote:
> We are definitely at a now-or-never point about this.  As a conceptual 
> exercise, imaging packaging Zope as follows:
> 
>   1) Zope is distributed as a single, monolithic chunk (all that
>      "dependency spaghetti" will allow).
> 
>   2) Each product and subsection of zope.app is packaged as a separate,
>      loosely coupled package (RPMs, .deb's, whatever) *with explicitly-
>      identified dependencies on the others.*
> 
> The first scenario makes the "what is in the core?" question crucial; 
> the second allows different "super-packages" to be created to suit 
> different needs (e.g., my "filesystem-developer only" distro would not
> preclude a separate "ttw-devel-and-the-kitchen-sink" distro).  Given 
> that the two best-known package systems (.deb / .rpm) can both do 
> dependency resolution (rpm + apt or yum, anyway), the major advantage of 
> the monolithic strategy ("batteries included") is reduced.

I really like scenario #2, especially with the option to have 
super-packages with dependencies (that's very debianic, which I like).

Looking at a package in zope.app then, it

   - would have well-defined and well-documented dependencies (maybe we
     can come up with a format that automatic build machines can create
     packages easily)

   - could very well be optional, depending whether other crucial
     packages depend on it

   - is in some sense standard though, because it's in zope.app and not
     some other top-level package.

That means, we could really dump the idea of zope.products (fine with 
me!), because packages in zope.app would already fullfil its requirements.

> Packaging for Windows and platforms without such dependency resolution 
> remains thornier;

I don't know how packaging for Windows is done, but I guess you could 
have a dependency resolution system in Python that would checkout the 
right packages from CVS and you'd only have to build that and zip it up, 
or feed it to an installer...

Same applies to MacOS X, I guess. It would be easy to get it into fink 
(since they use debian packages), but maybe it'd be nice to provide a 
.dmg distribution. If ZC can't, there should at least be an easy 
framework for others to use, so they can make packages.

> nonetheless, I think we should attempt the "fine grained" mdel.  From
> this POV, it should be a goal of PackageGeddon both to identify *and
> to reduce* such interpackage dependencies.

Yup.

Philipp


From jim at zope.com  Fri Feb 13 09:54:12 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 13 09:54:18 2004
Subject: [Zope3-dev] widget question: propertyNames/getValue
In-Reply-To: <200402121707.06805.fred@zope.com>
References: <FB37E9B9E9354A4788F1B322E4AAD1D880A4@server1.mojave.local>	<4025850C.5030901@zope.com>
	<200402121707.06805.fred@zope.com>
Message-ID: <402CE514.2020801@zope.com>

We want the configurable fields of a widget to be part of a widget's
interface, so that we can configure the widget externally and automatically.
I think this is what Gary was saying.

And, as Gary pointed out, it will facilitate the definition of custom
widgets for forms through ZCML without writing a separate ZCML directive for each
widget type.

Jim


Fred Drake wrote:
> Garrett Smith wrote:
>  > I'm trying to make sense of propertyNames in the widget facility. From
>  > what I can see, propertyNames and getValue can be removed from IWidget
> 
> On Saturday 07 February 2004 07:38 pm, Jim Fulton wrote:
>  > My opinion is that widgets should implement schemas that describe their
>  > configuration data, which are exposed via attributes.
> 
> So there's no need to hold on to the existing propertyNames/getValue cruft.  
> Let's ditch those now!  Adding a simple base widget schema would be nice, 
> but doesn't seem necessary.  I'd be just as happy to say all of that is 
> implementation and not part of the interface.
> 
> 
>   -Fred
> 


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Fri Feb 13 10:00:11 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 13 10:00:53 2004
Subject: [Zope3-dev] Last chance to mess with the source layout of Zope 3
In-Reply-To: <20040213100823.GA2974@vet.uu.nl>
References: <4026BF7B.3050407@zope.com>
	<20040212200207.GF799@vet.uu.nl>	<200402121513.23184.srichter@cosmos.phy.tufts.edu>
	<20040213100823.GA2974@vet.uu.nl>
Message-ID: <402CE67B.7050800@zope.com>

Martijn Faassen wrote:
> Stephan Richter wrote:
> 
>>Yes, this is how I develop Zope 3 products these days. If the browser code is 
>>minimal and has only 1-2 templates I use browser.py otherwise I am shifting 
>>to a directory browser, but usually leave the views in __init__.py, so that 
>>the imports don't change.
> 
> 
> Putting stuff in __init__.py... Why don't you use modules and 'from .. import'
> the views into __init__.py if you want to do this? Much cleaner.
> 
> 
>>Also, I have recently started to move implementation of interfaces to 
>>__init__.py as well.
> 
> 
> Putting a ton of stuff into __init__.py sounds like bad practice to me.
> It's very easily avoided by placing a few 'from .. import' statements in your
> __init__.py and doing the rest in a module where they belong.

I think you are probably right.  It's a little tough for small packages.
I find myself often wanting to create very small view packages that
have a single python file and some ZPT and ZCML files.

Suppose we have a package foo.  I'm inclined to have:

   foo:

     foo.py
     __init__.py
     configure.zcml
     bar.pt
     spat.pt

and in __init__.py having:

   from foo.foo import *

I've been uncomrfortable with repeating names inside packages, and
I certainly want to avoid clients doing:

   from foo.foo import x

but I'm less confortable with heavy __init__.py modules.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From casey at zope.com  Fri Feb 13 10:55:08 2004
From: casey at zope.com (Casey Duncan)
Date: Fri Feb 13 10:57:58 2004
Subject: [Zope3-dev] Last chance to mess with the source layout of Zope 3
In-Reply-To: <402CE67B.7050800@zope.com>
References: <4026BF7B.3050407@zope.com> <20040212200207.GF799@vet.uu.nl>
	<200402121513.23184.srichter@cosmos.phy.tufts.edu>
	<20040213100823.GA2974@vet.uu.nl> <402CE67B.7050800@zope.com>
Message-ID: <20040213105508.75b20515.casey@zope.com>

On Fri, 13 Feb 2004 10:00:11 -0500
Jim Fulton <jim@zope.com> wrote:
[..]
> 
> Suppose we have a package foo.  I'm inclined to have:
> 
>    foo:
> 
>      foo.py
>      __init__.py
>      configure.zcml
>      bar.pt
>      spat.pt
> 
> and in __init__.py having:
> 
>    from foo.foo import *
> 
> I've been uncomrfortable with repeating names inside packages, and
> I certainly want to avoid clients doing:
> 
>    from foo.foo import x

Yeah, that bites especially when foo.py contains a function foo() ;^).
The traditional way this is avoided of course is by naming the module
something else (like _foo.py ), which is perhaps not aesthetic but at
least it prevents ambiguity. And clients will see that _foo is supposed
to be a private name.
 
> but I'm less confortable with heavy __init__.py modules.

Yes, I find they reduce transparency. I'm always surprised when I find
non-initialization code in __init__.py.

-Casey

From mgedmin at b4net.lt  Fri Feb 13 12:05:12 2004
From: mgedmin at b4net.lt (Marius Gedminas)
Date: Fri Feb 13 12:05:18 2004
Subject: [Zope3-dev] Repost: Q on conf error reporting
In-Reply-To: <BAY3-F21BL0Qacfde5Z00024044@hotmail.com>
References: <BAY3-F21BL0Qacfde5Z00024044@hotmail.com>
Message-ID: <20040213170511.GA30977@perlas>

On Tue, Feb 10, 2004 at 09:31:31PM +0000, Dave Harris wrote:
> I posted this just before all the list activity ramped up Sunday afternoon. 
> It's not as momentous as decisions about 'core' or 'inline', but I'd still 
> like to get a opinion.
<snip>
> >I added an server entry to zope.conf using a silly type:
> >
> ><server>
> >  type LEMMING
> >  address 8083
> ></server>
> >
> >and received (deservedly) a program failure marking my misdeed:
> >
> >Traceback (most recent call last):
<snip>
> >AttributeError: 'NoneType' object has no attribute 'create'
> >
> >This leads to a couple (or four) questions:
> >
> >1) When getServerType() returns None, should create() still proceed with 
> >the
> >servertype.create() call?

I would expect getServerType to raise an exception rather than returning
None.

BTW there seems to be a typo in ISimpleRegistry: it defines a method
called 'getF'.  I think it should be 'get'.

> >2) When a bad but well-formed configuration entry is processed, should Zope
> >3 report the specifics (e.g. the config file line and the reason for
> >failure)?

Yes.

> >3) In general, should Zope 3 disguise the fact that Python is the
> >implementation language - that is, not generate tracebacks?

I believe strongly that tracebacks should always imply a bug in the
software as opposed to user error.

How important this is at the current stage is a question I'm not
qualified to answer.  I'd venture a guess that there are more pressing
issues.

> >4) Would a test for this situation be a unit test of
> >zope.app.process.setup()? Or would it be considered a functional test?

A unit test seems to be more fitting in this case.

Marius Gedminas
-- 
Never trust a computer you can't repair yourself.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20040213/aa582052/attachment.bin
From jim at zope.com  Fri Feb 13 12:08:48 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 13 12:08:52 2004
Subject: [Zope3-dev] Last chance to mess with the source layout of Zope 3
In-Reply-To: <20040212200207.GF799@vet.uu.nl>
References: <4026BF7B.3050407@zope.com> <20040212200207.GF799@vet.uu.nl>
Message-ID: <402D04A0.6050901@zope.com>

Martijn Faassen wrote:
...

>>A variation on this would be to provide separate UI packages
>>(e.g, zope.app.folder and zope.app.folderweb).
> 
> 
> -1 to folderweb like everybody else.

I'd like to pursue this a bit further.

I think that continueing to separate presentations has a number
of advantages:

- It *is* easier for people who just want to modify presentations to
   find them.

- It makes it clearer that presentatations are pluggable and how

- It enforces the separation of presentation and application code

- If we don't separate presentation into separate packages, some
   will create presentation-specific subpackages anyway.

The disadvantages of separate subpackages are:

- More packages, some of which are very small

- More navigation, but the navigation is simpler.  For example, if I'm
   in foo and I want to get to the directory with the browser code, I
   only have to cd to ../foo_browser, which isn't so bad.

I think that the advantages of separating the presentation code far outweigh
the disadvantages.

Note that we won't separate interface code except in the case of "framework"
packages that define pluggable fraemworks with interfaces where there
are expected to be multiple implemantations.

So, I feel rather strongly that we should have:

folder
folder_browser
file
file_browser

and so on. Note, again, that this separation is a good bit different
than what we have now. The presentation code is *close* to the application
code while still being separate.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Fri Feb 13 13:01:21 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 13 13:01:28 2004
Subject: [Zope3-dev] Number of first release should be X3.0.0
Message-ID: <402D10F1.5070108@zope.com>


I propose to number the X3 releases starting from 0 (or from 3 ;).

That is, the first X3 release will be X3.0.0. The next feature
X3 release will be X3.1.0, and so on.  (It will be decided
later whether to restart the numbering for Zope 3 releases.)

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Fri Feb 13 13:30:10 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 13 13:30:51 2004
Subject: [Zope3-dev] More thoughts on packaging
Message-ID: <402D17B2.9040809@zope.com>


There seems to be a possible consensus emerging that we should
use a packaging system.  I suggest that we should use an existing
system (or systems) such as RPM or the debian system and
provide the ability to generate course-grained distributions
from these systems for those systems (e.g. windows) that either
don't have package systems or don't have package systems that
we support.

Suppose, for example, that we support RPMs and Debian packages.
We should still generate Zope source releases that don't require
any OS package support.  These source releases might be mostly a
collection of source packages (or derivatives) with some glue
code to get them built and installed. In particular, a source
release might look little or nothing like a CVS checkout.
Similarly, a binary release might be largely a collection of binary
packages (or derivatives).

Packaging should be largely independent of the repository structure.
In particular, whether a package is or isn't included in a distribution
should not have much of an effect on it's place in the repository.
Whether a package is included in this or that distribution, or even the
degree to which a package is "optional" is likely to change over time.
It would be insane, IMO, to move a package whenever it's status changes.

I think a Python package's status and it's relationship to
other packages, especially its dependencies, should be captured in
meta data, not in it's Python package location.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Fri Feb 13 13:31:41 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 13 13:31:51 2004
Subject: [Zope3-dev] This is a good time for people who care about packaging
 to get involved ;)
Message-ID: <402D180D.8050409@zope.com>

This would be a good time for people interested and knowledgeable
about packaging systems and who want to influence the direction we
take with Zope 3 to get involved. :)

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From barry at python.org  Fri Feb 13 13:52:55 2004
From: barry at python.org (Barry Warsaw)
Date: Fri Feb 13 13:53:02 2004
Subject: [Zope3-dev] Number of first release should be X3.0.0
In-Reply-To: <402D10F1.5070108@zope.com>
References: <402D10F1.5070108@zope.com>
Message-ID: <1076698375.30037.26.camel@anthem>

On Fri, 2004-02-13 at 13:01, Jim Fulton wrote:
> I propose to number the X3 releases starting from 0 (or from 3 ;).
> 
> That is, the first X3 release will be X3.0.0. The next feature
> X3 release will be X3.1.0, and so on.  (It will be decided
> later whether to restart the numbering for Zope 3 releases.)

I'd suggest not restarting the numbering when the 'X' is removed,
otherwise I predict massive confusion.  Unless of course you chose to
number it as Zope 4 -- but you already said you'd never work on that. :)

-Barry



From srichter at cosmos.phy.tufts.edu  Fri Feb 13 14:06:37 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Fri Feb 13 14:06:43 2004
Subject: [Zope3-dev] This is a good time for people who care about
	packaging to get involved ; )
In-Reply-To: <402D180D.8050409@zope.com>
References: <402D180D.8050409@zope.com>
Message-ID: <200402131406.37754.srichter@cosmos.phy.tufts.edu>

On Friday 13 February 2004 13:31, Jim Fulton wrote:
> This would be a good time for people interested and knowledgeable
> about packaging systems and who want to influence the direction we
> take with Zope 3 to get involved. :)

You might want to make that an announcement on zope-announce and zope-dev.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From srichter at cosmos.phy.tufts.edu  Fri Feb 13 14:15:02 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Fri Feb 13 14:15:06 2004
Subject: [Zope3-dev] This is a good time for people who care about
	packaging to get involved ; )
In-Reply-To: <402D180D.8050409@zope.com>
References: <402D180D.8050409@zope.com>
Message-ID: <200402131415.02409.srichter@cosmos.phy.tufts.edu>

On Friday 13 February 2004 13:31, Jim Fulton wrote:
> This would be a good time for people interested and knowledgeable
> about packaging systems and who want to influence the direction we
> take with Zope 3 to get involved. :)

Also, we might want to contact the creators of the Zope 2 Deb and RPM packages 
for some input.

Sorry for the second mail.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From jim at zope.com  Fri Feb 13 14:33:44 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 13 14:33:57 2004
Subject: [Zope3-dev] This is a good time for people who care about packaging
 to get involved ;)
Message-ID: <402D2698.2030806@zope.com>

This would be a good time for people interested and knowledgeable
about packaging systems and who want to influence the direction we
take with Zope 3 to get involved. :)

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org



From pje at telecommunity.com  Fri Feb 13 15:16:45 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri Feb 13 15:16:59 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <402D17B2.9040809@zope.com>
Message-ID: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>

At 01:30 PM 2/13/04 -0500, Jim Fulton wrote:

>There seems to be a possible consensus emerging that we should
>use a packaging system.  I suggest that we should use an existing
>system (or systems) such as RPM or the debian system and
>provide the ability to generate course-grained distributions
>from these systems for those systems (e.g. windows) that either
>don't have package systems or don't have package systems that
>we support.

I haven't been following the packaging discussion that closely, so I may be 
projecting the following from a different set of requirements in mind than 
what you have.  So, apologies in advance if this is completely off-base 
from where you're heading...

Suppose that we put dependency metadata in package directories as an extra 
file, and then we wrote a 'package.py' script that generates a custom 
'setup.py' from the metadata, based on an intended target.  E.g. 
'package.py sometarget'.

Advantages:

* Leverages distutils packaging system support, since you can build Windows 
.exes, RPMs, source tarballs, etc.

* Takes advantage of any future distutils support for additional packaging 
systems

* Keeps the metadata lightweight and focused on Zope-specific needs

* Doesn't require anyone to learn another "full" packaging system


Disadvantages:

* Has to be written (but is relatively lightweight)


The metadata could actually be provided in the form of a Python module 
(e.g. '__setup__.py')  that defines any extensions, datafiles, etc., as 
well as "provides" and "requires" keys.

The 'package.py' script would write a 'setup.py' script that would look 
something like:

execfile('setupstuff/prologue.py')

gatherSetup('src/some/pkg1/__setup__.py')
gatherSetup('src/other/something/__setup__.py')

# ... etc, etc.

execfile('setupstuff/epilogue.py')

Based on sorting out the dependencies.  'epilogue' would then call the 
distutils 'setup' function with the accumulated data.


>Suppose, for example, that we support RPMs and Debian packages.
>We should still generate Zope source releases that don't require
>any OS package support.  These source releases might be mostly a
>collection of source packages (or derivatives) with some glue
>code to get them built and installed. In particular, a source
>release might look little or nothing like a CVS checkout.
>Similarly, a binary release might be largely a collection of binary
>packages (or derivatives).
>
>Packaging should be largely independent of the repository structure.
>In particular, whether a package is or isn't included in a distribution
>should not have much of an effect on it's place in the repository.
>Whether a package is included in this or that distribution, or even the
>degree to which a package is "optional" is likely to change over time.
>It would be insane, IMO, to move a package whenever it's status changes.
>
>I think a Python package's status and it's relationship to
>other packages, especially its dependencies, should be captured in
>meta data, not in it's Python package location.


From srichter at cosmos.phy.tufts.edu  Fri Feb 13 15:55:16 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Fri Feb 13 15:55:22 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
References: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
Message-ID: <200402131555.16371.srichter@cosmos.phy.tufts.edu>

On Friday 13 February 2004 15:16, Phillip J. Eby wrote:
> Advantages:
>
> * Leverages distutils packaging system support, since you can build Windows
> .exes, RPMs, source tarballs, etc.
>
> * Takes advantage of any future distutils support for additional packaging
> systems
>
> * Keeps the metadata lightweight and focused on Zope-specific needs
>
> * Doesn't require anyone to learn another "full" packaging system
>
>
> Disadvantages:
>
> * Has to be written (but is relatively lightweight)

I was hoping that we would be able to use distutils somehow. Unfortunately I 
know nothing about distutils. But your suggestions sound good to me from a 
high-level perspective.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From fred at zope.com  Fri Feb 13 17:03:07 2004
From: fred at zope.com (Fred Drake)
Date: Fri Feb 13 17:03:18 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
References: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
Message-ID: <200402131703.07139.fred@zope.com>

On Friday 13 February 2004 03:16 pm, Phillip J. Eby wrote:
 > Suppose that we put dependency metadata in package directories as an
 > extra file, and then we wrote a 'package.py' script that generates a
 > custom 'setup.py' from the metadata, based on an intended target.  E.g.
 > 'package.py sometarget'.

+1

 > The metadata could actually be provided in the form of a Python module
 > (e.g. '__setup__.py')  that defines any extensions, datafiles, etc., as
 > well as "provides" and "requires" keys.

I'm not so sure this belongs in the same file as any Zope-specific 
information, but I'm not convinced that any of this is Zope-specific; it 
sounds very generally useful for any large collection of packages with 
varied dependency relationships.

This is something I'd very much like to see in distutils anyway.

 > The 'package.py' script would write a 'setup.py' script that would look
 > something like:
 >
 > execfile('setupstuff/prologue.py')
 >
 > gatherSetup('src/some/pkg1/__setup__.py')
 > gatherSetup('src/other/something/__setup__.py')
 >
 > # ... etc, etc.
 >
 > execfile('setupstuff/epilogue.py')

Why two execfile() calls instead of imports?  If we're presuming the files 
are there, make setupstuff a module or package and use that.  So we end up 
with something more like:

-------------------------------------------
from setupstuff import setupFromDirectories

setupFromDirectories([
    'src/some/pkg1',
    'src/other/something',
    # ... etc.
    ])
-------------------------------------------


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation


From jim at zope.com  Fri Feb 13 17:18:55 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 13 17:19:02 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
References: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
Message-ID: <402D4D4F.5040706@zope.com>

Phillip J. Eby wrote:
> At 01:30 PM 2/13/04 -0500, Jim Fulton wrote:
> 
>> There seems to be a possible consensus emerging that we should
>> use a packaging system.  I suggest that we should use an existing
>> system (or systems) such as RPM or the debian system and
>> provide the ability to generate course-grained distributions
>> from these systems for those systems (e.g. windows) that either
>> don't have package systems or don't have package systems that
>> we support.
> 
> 
> I haven't been following the packaging discussion that closely, so I may 
> be projecting the following from a different set of requirements in mind 
> than what you have.  So, apologies in advance if this is completely 
> off-base from where you're heading...

I'd say that you are on target.

> Suppose that we put dependency metadata in package directories as an 
> extra file, and then we wrote a 'package.py' script that generates a 
> custom 'setup.py' from the metadata, based on an intended target.  E.g. 
> 'package.py sometarget'.
> 
> Advantages:
> 
> * Leverages distutils packaging system support, since you can build 
> Windows .exes, RPMs, source tarballs, etc.
> 
> * Takes advantage of any future distutils support for additional 
> packaging systems
> 
> * Keeps the metadata lightweight and focused on Zope-specific needs
> 
> * Doesn't require anyone to learn another "full" packaging system

Yup.

I thnink that dependencies are one central issue that is going
to be critical if we do fine-grained  packaging.

> 
> Disadvantages:
> 
> * Has to be written (but is relatively lightweight)
> 
> 
> The metadata could actually be provided in the form of a Python module 
> (e.g. '__setup__.py')  that defines any extensions, datafiles, etc., as 
> well as "provides" and "requires" keys.

"provides" and "requires"?  I assume that "requires" expresses the
dependencies.  What is "provides" for?

> The 'package.py' script would write a 'setup.py' script that would look 
> something like:
> 
> execfile('setupstuff/prologue.py')
> 
> gatherSetup('src/some/pkg1/__setup__.py')
> gatherSetup('src/other/something/__setup__.py')

why 2 gather setups? Is this for a distribution package that
includes 2 Python packages?

> # ... etc, etc.
> 
> execfile('setupstuff/epilogue.py')
> 
> Based on sorting out the dependencies.  'epilogue' would then call the 
> distutils 'setup' function with the accumulated data.

How does it sort out the dependencies?  Does it retrieve other packages?
Does it assume that they are around and just need to be installed?

(Getting into this level of detail might be premature.)

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Fri Feb 13 17:20:31 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 13 17:20:38 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <200402131703.07139.fred@zope.com>
References: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<200402131703.07139.fred@zope.com>
Message-ID: <402D4DAF.10502@zope.com>

Fred Drake wrote:
> On Friday 13 February 2004 03:16 pm, Phillip J. Eby wrote:
...

> This is something I'd very much like to see in distutils anyway.

Assuming that the "this" you are talking about is dependency management,
I believe that this was planned for distutils.  Do you know of any other
attempts to add dependency management to (or over) distutils?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From pje at telecommunity.com  Fri Feb 13 17:28:37 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri Feb 13 17:28:43 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <200402131703.07139.fred@zope.com>
References: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
Message-ID: <5.1.1.6.0.20040213171952.02c02640@telecommunity.com>

At 05:03 PM 2/13/04 -0500, Fred Drake wrote:
>On Friday 13 February 2004 03:16 pm, Phillip J. Eby wrote:
>  > Suppose that we put dependency metadata in package directories as an
>  > extra file, and then we wrote a 'package.py' script that generates a
>  > custom 'setup.py' from the metadata, based on an intended target.  E.g.
>  > 'package.py sometarget'.
>
>+1
>
>  > The metadata could actually be provided in the form of a Python module
>  > (e.g. '__setup__.py')  that defines any extensions, datafiles, etc., as
>  > well as "provides" and "requires" keys.
>
>I'm not so sure this belongs in the same file as any Zope-specific
>information, but I'm not convinced that any of this is Zope-specific; it
>sounds very generally useful for any large collection of packages with
>varied dependency relationships.
>
>This is something I'd very much like to see in distutils anyway.

Yeah, for big packages it's often annoying to have to edit a central 
setup.py every time you add a subpackage or a data file.  Most of the time 
I forget during development, and don't discover the problem until somebody 
else tries to install the package.



>  > The 'package.py' script would write a 'setup.py' script that would look
>  > something like:
>  >
>  > execfile('setupstuff/prologue.py')
>  >
>  > gatherSetup('src/some/pkg1/__setup__.py')
>  > gatherSetup('src/other/something/__setup__.py')
>  >
>  > # ... etc, etc.
>  >
>  > execfile('setupstuff/epilogue.py')
>
>Why two execfile() calls instead of imports?

To avoid being at the mercy of what's installed on the Python path.  At 
least, that was the theory when I wrote setup extensions for some of my own 
apps.  Whether it really makes any sense or not, I don't know.  Mainly, it 
was because I was using a 'setup' directory, which meant that 'import 
setup' would've imported 'setup.py'.  So, I used execfile and went on with 
my life.  :)

That doesn't mean that Zope needs to emulate my hack, but until you asked 
the question I'd forgotten entirely why I chose to do it that way.  :)


>   If we're presuming the files
>are there, make setupstuff a module or package and use that.  So we end up
>with something more like:
>
>-------------------------------------------
>from setupstuff import setupFromDirectories
>
>setupFromDirectories([
>     'src/some/pkg1',
>     'src/other/something',
>     # ... etc.
>     ])
>-------------------------------------------

That's definitely a lot more compact.


From pje at telecommunity.com  Fri Feb 13 17:49:55 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri Feb 13 17:50:03 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <402D4D4F.5040706@zope.com>
References: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
Message-ID: <5.1.1.6.0.20040213172953.02980cb0@telecommunity.com>

At 05:18 PM 2/13/04 -0500, Jim Fulton wrote:
>Phillip J. Eby wrote:
>>At 01:30 PM 2/13/04 -0500, Jim Fulton wrote:
>>
>>>There seems to be a possible consensus emerging that we should
>>>use a packaging system.  I suggest that we should use an existing
>>>system (or systems) such as RPM or the debian system and
>>>provide the ability to generate course-grained distributions
>>>from these systems for those systems (e.g. windows) that either
>>>don't have package systems or don't have package systems that
>>>we support.
>>
>>I haven't been following the packaging discussion that closely, so I may 
>>be projecting the following from a different set of requirements in mind 
>>than what you have.  So, apologies in advance if this is completely 
>>off-base from where you're heading...
>
>I'd say that you are on target.
>
>>Suppose that we put dependency metadata in package directories as an 
>>extra file, and then we wrote a 'package.py' script that generates a 
>>custom 'setup.py' from the metadata, based on an intended target.  E.g. 
>>'package.py sometarget'.
>>Advantages:
>>* Leverages distutils packaging system support, since you can build 
>>Windows .exes, RPMs, source tarballs, etc.
>>* Takes advantage of any future distutils support for additional 
>>packaging systems
>>* Keeps the metadata lightweight and focused on Zope-specific needs
>>* Doesn't require anyone to learn another "full" packaging system
>
>Yup.
>
>I thnink that dependencies are one central issue that is going
>to be critical if we do fine-grained  packaging.
>
>>Disadvantages:
>>* Has to be written (but is relatively lightweight)
>>
>>The metadata could actually be provided in the form of a Python module 
>>(e.g. '__setup__.py')  that defines any extensions, datafiles, etc., as 
>>well as "provides" and "requires" keys.
>
>"provides" and "requires"?  I assume that "requires" expresses the
>dependencies.  What is "provides" for?

That's if we say that a bundle may offer one or more "features" that other 
bundles require.  For example, the 'zope.interface' package might "provide" 
the "feature" 'zope.interface v1.03'.  Another package might specify that 
it requires 'zope.interface v1.05', and thus won't work with the other 
package.

It might be more useful to have make versions more explicit, instead.  My 
draft of the concept was borrowed from certain 'init' implementations that 
do dependency resolution.  A given script might say that it depends on the 
'http' service, but the 'apache' script says that it "provides" 'http' and 
'https'.

Anyway, feel free to simplify/discard/whatever; I just was throwing this 
out as an idea of a possible general direction to take.  I'm not really 
particular about the details at the moment.  :)


>>The 'package.py' script would write a 'setup.py' script that would look 
>>something like:
>>execfile('setupstuff/prologue.py')
>>gatherSetup('src/some/pkg1/__setup__.py')
>>gatherSetup('src/other/something/__setup__.py')
>
>why 2 gather setups? Is this for a distribution package that
>includes 2 Python packages?

Or maybe 2 "bundles", where there is some mapping between bundles and 
packages.  I'm being somewhat vague and handwavy here.  Also, Fred 
suggested replacing all that with one function call and a list of 
packages/bundles/directories/whatever, which certainly works too.



>># ... etc, etc.
>>execfile('setupstuff/epilogue.py')
>>Based on sorting out the dependencies.  'epilogue' would then call the 
>>distutils 'setup' function with the accumulated data.
>
>How does it sort out the dependencies?

By looking at the metadata, and creating a list of all the setup metadata 
snippets that would constitute a distribution with all the dependencies 
satisfied.


>   Does it retrieve other packages?
>Does it assume that they are around and just need to be installed?

The mental model I have in mind is that you have a "complete" source 
distribution from which you are "packaging" things.  So, let's say I wanted 
to make a "mini-Me" Zope distro that had only what was needed to support 
'zope.publisher'.  I would check-out the entire Zope X3 source tree, and 
run something like 'package.py zope.publisher' (?) and then run setup.py to 
create source and binary distributions.

This is the aspect I thought might be off-base from where you're 
headed.  My presumption here was not to make it possible for an end-user to 
wave a magic wand and download/install dependencies, as that seems like a 
future distutils function.  Instead, I was targeting the ability to *make* 
distribution packages, if one had the source of the things one wanted to 
package.

Of course, it *would* be pretty cool if it could download dependencies.  If 
package metadata files (and their dependencies) were accessed/referenced by 
URLs, and there were standardized formats/methods/locations for 
downloading...  Hm.  But then there are issues with things like the running 
of untrusted code, etc. etc.  I think it'd be better to require the user to 
have everything needed already unpacked on the local machine, in a 
known/standard directory structure.  The 'package.py' program will have to 
tell you about missing dependencies anyway, so you'll at least get a list 
of things you need to download.  Anyway, this keeps the scope of the effort 
from exploding into "rewrite distutils" territory.


From fred at zope.com  Fri Feb 13 18:16:59 2004
From: fred at zope.com (Fred Drake)
Date: Fri Feb 13 18:17:09 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <402D4DAF.10502@zope.com>
References: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<200402131703.07139.fred@zope.com> <402D4DAF.10502@zope.com>
Message-ID: <200402131816.59402.fred@zope.com>

On Friday 13 February 2004 05:20 pm, Jim Fulton wrote:
 > Assuming that the "this" you are talking about is dependency management,
 > I believe that this was planned for distutils.  Do you know of any other
 > attempts to add dependency management to (or over) distutils?

Actually, by "this" I meant something a little different: moving package 
metadata into packages.

Right now, we have the problem that every distribution we ship that includes 
(for example) ZConfig has to deal with all the bits and pieces that go 
along with the code, including not only the documentation but also the 
ancillary files placed inside the packages (schema components, 
configuration files for the tests, etc.).  All this information is repeated 
for Zope 2, Zope 3, ZODB, and StandaloneZConfig.  And maybe other places I 
don't know about.  There is a similar situation for BTrees, zLOG, ZODB, 
ZEO, and who know what else.

We definately want the top-level setup.py scripts to say "that package", but 
we want that package to define for itself what constitutes that package.

Dependency information is just one portion of a package's metadata.  It 
should be included along with the other metadata related to the package 
itself.  I'd be happy for it to live in the same place as the other package 
metadata if we can get that to be in the right place: the package itself.

Using setup.py as a container for the package metadata has not worked well 
as all, given how many setup.py scripts we maintain.


-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation


From philipp at weitershausen.de  Fri Feb 13 18:32:23 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Fri Feb 13 18:25:47 2004
Subject: [Zope3-dev] Re: Number of first release should be X3.0.0
In-Reply-To: <1076698375.30037.26.camel@anthem>
References: <402D10F1.5070108@zope.com> <1076698375.30037.26.camel@anthem>
Message-ID: <402D5E87.3070900@weitershausen.de>

Barry Warsaw wrote:
> On Fri, 2004-02-13 at 13:01, Jim Fulton wrote:
> 
>>I propose to number the X3 releases starting from 0 (or from 3 ;).
>>
>>That is, the first X3 release will be X3.0.0. The next feature
>>X3 release will be X3.1.0, and so on.  (It will be decided
>>later whether to restart the numbering for Zope 3 releases.)
> 
> I'd suggest not restarting the numbering when the 'X' is removed,

What is the deal with the 'X' anyway? AFAIK, no evil Zope2 stuff will 
end up in Zope3 but the other way around; the result will then be called 
Zope 2.9. Am I missing something?

Why not start with Zope 3.0.0 and work our way up...?

Philipp


From fred at zope.com  Fri Feb 13 18:33:06 2004
From: fred at zope.com (Fred Drake)
Date: Fri Feb 13 18:33:15 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <5.1.1.6.0.20040213172953.02980cb0@telecommunity.com>
References: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<5.1.1.6.0.20040213172953.02980cb0@telecommunity.com>
Message-ID: <200402131833.06435.fred@zope.com>

On Friday 13 February 2004 05:49 pm, Phillip J. Eby wrote:
 > The mental model I have in mind is that you have a "complete" source
 > distribution from which you are "packaging" things.  So, let's say I
 > wanted to make a "mini-Me" Zope distro that had only what was needed to
 > support 'zope.publisher'.  I would check-out the entire Zope X3 source
 > tree, and run something like 'package.py zope.publisher' (?) and then
 > run setup.py to create source and binary distributions.

That's one way to approach it.

Another would be to feed the unsatisfied dependency information into 
distutils (somehow) so that when it generates an RPM, that RPM could have 
external dependencies based on the unsatisfied dependencies of the 
components you've told package.py to package.

I'm not sure that either way is better, and I doubt we need to provide 
solutions for both approaches.  We just need to pick one.  Using a 
granualar approach (letting platform packaging systems deal with external 
dependencies) seems more appealing to me.  It would be nice to end up in a 
situation such that if someone wants to extend their Zope installation with 
an optional component, they can just download that one piece, and not a new 
Zope.

 > Of course, it *would* be pretty cool if it could download dependencies. 

Cool, yes.  I think this is out of scope.  Given some sort of processable 
metadata, we can create directories that make it easy to locate any 
additional components based on the ones we need.  This also isn't holding 
things up the way maintaining setup.py files currently is.

 > If package metadata files (and their dependencies) were
 > accessed/referenced by URLs, and there were standardized
 > formats/methods/locations for downloading...  Hm.  But then there are
 > issues with things like the running of untrusted code, etc. etc.  I

It's only an issue of running untrusted code if the metadata is code.  I'd 
be glad to see it be entirely declarative if possible.  At that point, it 
doesn't need to be Python code, but can be some sort of configuration file, 
whether it be ZConfig (nice, but...) or ConfigParser (...available from the 
standard library, making a solution more acceptable for eventual inclusion 
in distutils itself) or even something else (truly sad if we can't reuse an 
existing tool).

 > Anyway, this keeps the scope of the effort from exploding
 > into "rewrite distutils" territory.

Yeah, but that's what we need in too many ways.  ;-(


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation


From fred at zope.com  Fri Feb 13 18:36:12 2004
From: fred at zope.com (Fred Drake)
Date: Fri Feb 13 18:36:21 2004
Subject: [Zope3-dev] Re: Number of first release should be X3.0.0
In-Reply-To: <402D5E87.3070900@weitershausen.de>
References: <402D10F1.5070108@zope.com> <1076698375.30037.26.camel@anthem>
	<402D5E87.3070900@weitershausen.de>
Message-ID: <200402131836.12170.fred@zope.com>

On Friday 13 February 2004 06:32 pm, Philipp von Weitershausen wrote:
 > Why not start with Zope 3.0.0 and work our way up...?

+1 on calling it 3.0.0 and going from there.  Having a weird "X" in front 
just confuses potential users (actual users already got over it, and don't 
get any benefit from it either).

So I guess the "X" is there to ensure the consumption of screen pixels never 
drops below the universal pixelation threshold.  ;-)


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation


From philipp at weitershausen.de  Fri Feb 13 18:44:48 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Fri Feb 13 18:38:08 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <402D17B2.9040809@zope.com>
References: <402D17B2.9040809@zope.com>
Message-ID: <402D6170.9080307@weitershausen.de>

Jim Fulton wrote:
> 
> There seems to be a possible consensus emerging that we should
> use a packaging system.  I suggest that we should use an existing
> system (or systems) such as RPM or the debian system and
> provide the ability to generate course-grained distributions
> from these systems for those systems (e.g. windows) that either
> don't have package systems or don't have package systems that
> we support.
> 
> Suppose, for example, that we support RPMs and Debian packages.
> We should still generate Zope source releases that don't require
> any OS package support.  These source releases might be mostly a
> collection of source packages (or derivatives) with some glue
> code to get them built and installed. In particular, a source
> release might look little or nothing like a CVS checkout.
> Similarly, a binary release might be largely a collection of binary
> packages (or derivatives).

+1

> Packaging should be largely independent of the repository structure.
> In particular, whether a package is or isn't included in a distribution
> should not have much of an effect on it's place in the repository.
> Whether a package is included in this or that distribution, or even the
> degree to which a package is "optional" is likely to change over time.
> It would be insane, IMO, to move a package whenever it's status changes.

Yes, you're probably right. But if we keep a bunch of different packages 
in one place, we need to do something about configuration. Right now 
you'll have to edit src/zope/app/configure.zcml to add or remove a 
zope.app package from global configuration. zope.products packages are 
enabled or disabled in products.zcml which is custom to every instance...

Btw, I think it's still ok to have a special place of core packages. 
Their status is unlikely to ever change.

> I think a Python package's status and it's relationship to
> other packages, especially its dependencies, should be captured in
> meta data, not in it's Python package location.

Yes. I suggested earlier (can't remember where, when and to whom ;)) to 
use some sort of human- and machine-readable metadata description. I 
dislike the idea of using Python packages. I'd rather like to go with 
ini-style or ZConfig-style text files. That's actually what I always 
disliked about distutils, setup.py being a Python script.

Philipp


From pje at telecommunity.com  Fri Feb 13 19:08:58 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri Feb 13 19:09:05 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <200402131833.06435.fred@zope.com>
References: <5.1.1.6.0.20040213172953.02980cb0@telecommunity.com>
	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<5.1.1.6.0.20040213172953.02980cb0@telecommunity.com>
Message-ID: <5.1.1.6.0.20040213185723.023d1950@telecommunity.com>

At 06:33 PM 2/13/04 -0500, Fred Drake wrote:
>On Friday 13 February 2004 05:49 pm, Phillip J. Eby wrote:
>  > The mental model I have in mind is that you have a "complete" source
>  > distribution from which you are "packaging" things.  So, let's say I
>  > wanted to make a "mini-Me" Zope distro that had only what was needed to
>  > support 'zope.publisher'.  I would check-out the entire Zope X3 source
>  > tree, and run something like 'package.py zope.publisher' (?) and then
>  > run setup.py to create source and binary distributions.
>
>That's one way to approach it.
>
>Another would be to feed the unsatisfied dependency information into
>distutils (somehow) so that when it generates an RPM, that RPM could have
>external dependencies based on the unsatisfied dependencies of the
>components you've told package.py to package.

What about Windows?  There's no packaging system there, certainly not one 
supported by distutils, AFAICT.  There's also that whole "somehow" part to 
deal with.  :)

Also, it negates the advantage of not having to learn another external 
packaging system, while seeming to add another N-way support issue.  So, I 
don't think I'd want it as the default usage of 'package.py'.  However, I 
do see the value in being able to provide it as an option that can be used 
if your packaging system of choice is supported, at some later date when 
the distutils has some kind of standard for "somehow".  :)


>It's only an issue of running untrusted code if the metadata is code.  I'd
>be glad to see it be entirely declarative if possible.  At that point, it
>doesn't need to be Python code, but can be some sort of configuration file,
>whether it be ZConfig (nice, but...) or ConfigParser (...available from the
>standard library, making a solution more acceptable for eventual inclusion
>in distutils itself) or even something else (truly sad if we can't reuse an
>existing tool).

Dunno, I've often found it quite handy to be able to use Python code in 
setups.  But I guess if I examine the use cases, most of them boil down to:

* Python version/platform checking (e.g. install the backported 'datetime' 
on 2.2, don't build FastCGI support on Win32, etc.)

* Scan directories to find files of particular types

* Enable/disable things according to options (this would be subsumed by 
package dependencies/inclusions)

* Build Pyrex extensions from either .c or .pyx depending on whether Pyrex 
is installed

But I imagine that there are probably ways to make a dumb configuration 
file support most of this.


From jtk at yahoo.com  Fri Feb 13 20:08:17 2004
From: jtk at yahoo.com (Jeff Kowalczyk)
Date: Fri Feb 13 20:06:57 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
References: <402D17B2.9040809@zope.com>
Message-ID: <pan.2004.02.14.01.08.16.449123@yahoo.com>

Jim Fulton wrote:
> I think a Python package's status and it's relationship to other packages,
> especially its dependencies, should be captured in meta data, not in it's
> Python package location.

Gentoo's python-based portage system has a lot to offer as inspiration
for a Zope-specific packaging system.

A cross-platform subset of that design could be a good fit for the
recently-discussed breakout of Zope3 functional areas (Core,
Filesystem, TTW, etc) as well as an excellent application and
extension library management system.

'ebuild' package definitions are the basic commodity traded
among Gentoo integrators, and comprise the metadata, dependencies,
code-maturity tag, source locations and build steps for a given package.



From jim at zope.com  Sat Feb 14 11:52:59 2004
From: jim at zope.com (Jim Fulton)
Date: Sat Feb 14 11:53:40 2004
Subject: [Zope3-dev] Re: Number of first release should be X3.0.0
In-Reply-To: <402D5E87.3070900@weitershausen.de>
References: <402D10F1.5070108@zope.com> <1076698375.30037.26.camel@anthem>
	<402D5E87.3070900@weitershausen.de>
Message-ID: <402E526B.1000500@zope.com>

Philipp von Weitershausen wrote:
> Barry Warsaw wrote:
> 
>> On Fri, 2004-02-13 at 13:01, Jim Fulton wrote:
>>
>>> I propose to number the X3 releases starting from 0 (or from 3 ;).
>>>
>>> That is, the first X3 release will be X3.0.0. The next feature
>>> X3 release will be X3.1.0, and so on.  (It will be decided
>>> later whether to restart the numbering for Zope 3 releases.)
>>
>>
>> I'd suggest not restarting the numbering when the 'X' is removed,
> 
> 
> What is the deal with the 'X' anyway?

The X indicates that we have not dealt with the very important
issue of transitioning Zope 2 applications to Zope 3.  The X indicates
that we are still in an eXperimental or eXploratory mode.

 > AFAIK, no evil Zope2 stuff will
> end up in Zope3 but the other way around; the result will then be called 
> Zope 2.9. Am I missing something?

Yes.  We haven't really figured out the transition plan yet. Zope 2.9
is *just* one step in that direction.  We *may* provide bits of Zope 2
in Zope 3; we haven't decided yet.

> Why not start with Zope 3.0.0 and work our way up...?

Because we haven't provided the transition plan and we have barely
begun to even think about it.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From shane at zope.com  Sat Feb 14 17:34:05 2004
From: shane at zope.com (Shane Hathaway)
Date: Sat Feb 14 17:34:19 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <pan.2004.02.14.01.08.16.449123@yahoo.com>
References: <402D17B2.9040809@zope.com>
	<pan.2004.02.14.01.08.16.449123@yahoo.com>
Message-ID: <Pine.LNX.4.50.0402141706470.11062-100000@shane.zope.com>

On Fri, 13 Feb 2004, Jeff Kowalczyk wrote:

> Gentoo's python-based portage system has a lot to offer as inspiration
> for a Zope-specific packaging system.
> 
> (snip)
> 
> 'ebuild' package definitions are the basic commodity traded
> among Gentoo integrators, and comprise the metadata, dependencies,
> code-maturity tag, source locations and build steps for a given package.

ebuilds are pretty neat.  They serve the same purpose as RPM .spec files,
but they are much more concise.  Although ebuilds are shell scripts, they
have enough automation to make them mostly declarative.  Merely for
discussion, I'll share most of plone-1.0.5.ebuild (installed on any Gentoo
system at /usr/portage/net-zope/plone).  Plone is probably the most
complex open source application built on Zope 2, yet it doesn't take much
to express its packaging.

---
DESCRIPTION="A Zope Content Management System, based on Zope CMF."
HOMEPAGE="http://plone.org"
SRC_URI="mirror://sourceforge/plone/CMFPlone${PV}.tar.gz"
LICENSE="GPL-2"
KEYWORDS="x86"
RDEPEND="=net-zope/cmf-1.3*
        >=net-zope/formulator-1.2.0
        ${RDEPEND}"
---

SRC_URI specifies how to download the tarball in an automated way.  
KEYWORDS specifies the maturity of the package.  "x86" means that this
package has passed stability tests on the x86 architecture.  RDEPEND
specifies what other packages this package depends on.  CMF version 1.3 is
required (1.4 is disallowed).  Formulator 1.2 or better is required.  
Note that the text of the ebuild doesn't actually specify the version of
Plone.  The version is encoded in the ebuild's filename.

Most Zope product ebuilds are similar.

Shane

From Mailer-Daemon at python.org  Sun Feb 15 10:25:49 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Sun Feb 15 10:25:51 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1AsO9V-0008S0-JZ@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1AsO85-00082u-7C; Sun, 15 Feb 2004 10:24:21 -0500
From: zope3-dev@zope.org (jim)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [Zope 3 Packaging Proposal] (new) 
Message-ID: <20040215102421EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3PackagingProposal/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3PackagingProposal/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3PackagingProposal>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Sun, 15 Feb 2004 10:24:21 -0500
X-Spam-Status: OK (default 0.000)

Packaging of Zope 3 file-system-based software

  Status: IsPreProposal

  Author
 
    JimFulton

  Problem 

    An important feature of Zope 3 is that it provides a highly
    flexable and modular architecture for creating applications.  It
    is hoped that Zope components will be arranged in a variety of
    ways to meet various application needs. (Certainly, at least one
    configuration will be an web application server recognizable as
    Zope. :)

    To support this flexability, we'd like to provide a fine-grained
    packaging system that supports:

    - Easy creation of software distributions to meet a variety of
      needs. For example, we'd like to make it easy to support both
      stable and development Zope distributions.  The Zope X3.0.0
      distribution will include only features that are either very
      stable or needed for file-system-based development.  There are
      many other components in the Zope 3 repository that would be
      useful to people willing to work with still-under-development
      software.  We'd like to be able to easily generate alternative
      "development" distributions with these components.

    - Flexible update and maintenance of distribution components

    This document, which will eventually become a proposal, proposes
    some goals for selection and or design of a packaging system for
    Zope.

    Goals (and assumptions)

      - Support fine-grained software distribution packaging.

        Software distribution packages will often correspond directly
        to Python packages that are rather small. For example, a small
        software distribution package might include a single Python
        package with only a few source files.

        Note that supporting fine-grained distribution packages
        requires a packaging system that supports (requires) and
        leverages information about package dependencies.

      - Work with distutils.  We don't want to reinvent the wheel.
        OTOH, we may have to work with the rest of the Python
        community to improve the wheel we have to provide or support
        package management. The most imporatnt need being dependency
        management.  See PEP 262.

        We should strive to have needed distutils improvements ready
        for inclusion in Python 2.4.    

      - Work with existing platform packaging systems, most notably,
        RPM, Debian packages, and Fink.

      - Support platforms without their own packaging systems, most
        notably windows.

      - Support easy creation of various Zope distributions. These
        distributions will allow simple installation of a collection
        of packages easily without use of a package system by end
        users. 

      - Liberate the Zope repository from having to reflect
        distribution or packages status (e.g. core or not core.)

      - It should remain possible to check out the Zope 3 CVS module, 
        execute a simple build command and run Zope in place.  It
        should be easy to modify software, run tests and Zope and
        check in changes without having to resort to separate
        "install" steps after each change.

      - Provide a simpler repository layout to make Zope 3 software
        easier to understand and navigate.

      - Provide greater visability to software dependencies

    Non Goal

      - An important non-goal is Zope instance creation.  The software
        packaging mechanism will be responsible for installing
        software. It will generally not be responsible for setting up
        Zope instances. Rather, among the software installed will be
        software for creating Zope instances. 

    Jargon problems

      We use the term "package" to refer *both* to Python packages and
      to units of software distribution.  There will often, but not
      always be a one-to-one correspondence between software
      distribution packages and Python packages.   Distutils attempts
      to solve this by refering to software distributions as "module
      distributions". I (Jim) find this rather unsatisfying.  This is
      an issue that will, ultimately, need to be resolved by the
      Python community. We will follow thier lead.

    Possible vision

      - Work with the Python community at large to extend distutils
        to manage information necessary for packaging and create a
        simple package-management system for python.

      - From the above system, provide utilities for automatically
        generating platform (RPM, Debian, etc.) packages.

      - Create a system for generating distributions from packages.
        For example, a source distribution might be defined by
        specifying a root pacakge and satisfying it's deoendency. A
        source distribution might then be simply a collection of
        gathered source packages and glue utilities (obviously based
        on distutils) that build and install the collected packages.

        Note that source and binary distributions may not look
        anything like the CVS repository.

    Distutils issues

      We are aware of a number of issues using distutils to package
      Zope software. These are collected here so we can seek to
      address them in this project:

      - Lack of dependency data needed to support a packaging
        system. See PEP 262.

      - No support for package data files.  Zope makes extensive use
        of Python packages to include files in addition to Python
        modules, including:

        o Source files for other languages (e.g. ZPT and DTML)

        o Configuration files

        o Images

        Distutils has minimal support for installing data files, but
        has no notion of data files that are in and that should be
        installed with packages.

      - Issues with generating (or generated) platforn packages
        (e.g. RPMs).

        This space for Tres to fill in. :)

  Proposal

    Note yet

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3PackagingProposal

From Mailer-Daemon at python.org  Sun Feb 15 10:29:45 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Sun Feb 15 10:29:47 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1AsODJ-0000mN-4E@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1AsOBu-0000ZR-TQ; Sun, 15 Feb 2004 10:28:18 -0500
From: zope3-dev@zope.org (jim)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [IsPreProposal] (new) 
Message-ID: <20040215102818EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/IsPreProposal/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/IsPreProposal/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/IsPreProposal>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Sun, 15 Feb 2004 10:28:18 -0500
X-Spam-Status: OK (default 0.080)

These are documents that are in the formative stages, needed input and
comment before becoming proposals.

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/IsPreProposal

From jim at zope.com  Sun Feb 15 10:31:47 2004
From: jim at zope.com (Jim Fulton)
Date: Sun Feb 15 10:32:27 2004
Subject: [Zope3-dev] Packaging pre-proposal/notes
Message-ID: <402F90E3.3040303@zope.com>

I've collected some goals and other notes in the form of a preproposal
on packaging:

   http://dev.zope.org/Zope3/Zope3PackagingProposal

Comments, here and in the wiki are appreciated.  I'd like to agree
on goals that form a basis for additional work

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Sun Feb 15 11:39:55 2004
From: jim at zope.com (Jim Fulton)
Date: Sun Feb 15 11:40:36 2004
Subject: [Zope3-dev] Separate presentation packages
Message-ID: <402FA0DB.1030406@zope.com>


I sent this earlier in response in another thread, but didn't
get any response.  I'd be happy to assume no one disagrees
and accept silence as assent, but, I thought this would be more
controversal and a terser version got -1's before, so, here it is
again.  :)

I think that continueing to separate presentations has a number
of advantages:

- It *does* make iteasier for people who just want to modify
   presentations to find them.

- It makes it clearer that presentatations are pluggable and how

- It enforces the separation of presentation and application code

- If we don't separate presentation into separate packages, some
   will create presentation-specific subpackages anyway.

The disadvantages of separate subpackages are:

- More packages, some of which are very small

- More navigation, but the navigation is simple under the new
   shallow organization.  For example, if I'm in foo and I want
   to get to the directory with the browser code, I only have to
   cd to ../foo_browser, which isn't so bad.

I think that the advantages of separating the presentation code far outweigh
the disadvantages.

Note that we won't separate interface code except in the case of "framework"
packages that define pluggable frameworks with interfaces where there
are expected to be multiple implemantations.

So, I feel rather strongly that we should have packages like:

folder
folder_browser
file
file_browser

and so on. Note, again, that this separation is a good bit different
than what we have now. The presentation code is *close* to the application
code while still being separate.

Silence is assent. :)

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Sun Feb 15 13:10:12 2004
From: jim at zope.com (Jim Fulton)
Date: Sun Feb 15 13:10:58 2004
Subject: [Zope3-dev] Security: Permissions to use software (?)
Message-ID: <402FB604.5030902@zope.com>

I suggest that one should generally not require a permission to use
software.   We generally don't need to protect algorithms. Rather, we
need to protect resources that software may access.

In general then, utilities, modules, factories, etc. should not
require permissions to use them. An exception is software used to
access system resources (e.g. databases or files).  This means that
access to factories and most utilities should be unconditionally
allowed, by specifying zope.Public as the required permission.
Likewise for module attributes that only perform computation.

If we want to allow access to external resources, we need to do so
carefully.  If we do provide access and require a permission for the
access we need to be aware of the limitations of the security policy
in effect.  For example, the security policy currently used in Zope 3
allows only local grants for most principals.  It does allow global
grants for global principals,  which are defined in ZCML.
This means that access to a global object requiring a permission other
than zope.Public will usually be disallowed.  So, for example, requiing
a permission to access a global module attribute is equivalent to
disallowing access to principals not defined via ZCML. Alternate
security policies could avoid this.

Another way to provide access to system resources is to give them
locations. We do this now with local database connections.  Of course,
the factories for creating these local system accessors need to be
designed carefully.

Adapters (of various kinds, including views) are software that augment
existing objects.  Generally, we don't need to protect the adapter
code itself. We only need to protect the resources it accesses.  This
is complicated by the fact that adapters can be created from trusted
or from untrusted code.  Untrusted code can only directly adapt
objects that are security proxied.  Adapters created directly by
untrusted code need no special protection because the objects that
they adapt are protected.  We need to worry about adapters created
from trusted code, because they will often adapt unprotected
(non-security-proxied) objects.

I suggest that the simplest strategy for most adapters is to:

- Unconditionally allow access by requiring the zope.Public
   permission,

- Assure that the objects they adapt are security proxied.  This can
   be automated, but we need a way, in ZCML, to indicate this should
   happen.

This strategy applies to adapters that:

- Need to be accessed by untrusted code

- Don't access any external resources directly in their code (as
   opposed to accessing resources indirectly through the objects they
   adapt)

- Don't *need* unfettered access to the objects they adapt

Adapters that aren't accessed by untrusted code don't need security
declarations.

Adapters that access external resources have the same issues as other
software that accesses external resources, as described above.  It
should be very unusual for adapters to directly access external
resources. perhaps it should be considered a design flaw for them to
do so.

It is possible that adapters might need access to the objects they
adapt that is not provided to untrused code. This would be the case
for adapters whos purpose, at least in part, is to provide moderated
access that is otherwise not permitted. In this case, the adapter
needs to require an appropriate permission. (Note that, with the
current security policy, adapters that require a permission probably
need to be given a location in the objects they adapt.)

Questions? Comments?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From philipp at weitershausen.de  Sun Feb 15 13:36:33 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Sun Feb 15 13:29:53 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <402F90E3.3040303@zope.com>
References: <402F90E3.3040303@zope.com>
Message-ID: <402FBC31.6040108@weitershausen.de>

Jim,

I agree with most of the goals and assumptions you have listed. So 
assume a +1 from me for everything I've *not* commented below.

 >       - Support fine-grained software distribution packaging.
 >
 >         Software distribution packages will often correspond directly
 >         to Python packages that are rather small. For example, a small
 >         software distribution package might include a single Python
 >         package with only a few source files.

I think we should think of this as being the usual case.

 >       - Work with distutils.  We don't want to reinvent the wheel.
 >         OTOH, we may have to work with the rest of the Python
 >         community to improve the wheel we have to provide or support
 >         package management. The most imporatnt need being dependency
 >         management.  See PEP 262.

Distutils so far have been things magical thing to me, most probably 
because package metadata is provided within the setup.py script. When 
we, err, you guys invented ZCML, you didn't take Python as the 
configuration language for a good reason. I think the same reason 
applies to package installation through distutils. I would really rather 
like to see package metadata being provided in a parseable text file...

I don't think it's too late now. Distutils lacks the ability to express 
package dependencies, so we need to come up with a solution for that 
anyway. PEP 262 suggests to use the following in a setup.py file::

   setup(..., requires=['xml.utils.iso8601', ...)

I don't think we should have a setup.py file in every source code 
package just to express package dependency... Like I've said before and 
was agreed by some people, I would prefer a human- and machine-readable 
text format. The distribution packaging process would then receive a 
list of packages that a certain distribution should include. It would 
resolve all the dependencies and create a distribution containing the 
desired packages including their dependencies. While being at it, that 
process could also read a list of binary modules to be compiled, a list 
of to-be-installed complementary data files, etc. from that text-file.

In the end, I imagine the process to look like this (pseudo code)::

   to_be_installed = []  # command line argument or similar
   all_packages = resolveDependencies(to_be_installed)
   setup(... all_packages ...)

 >     Non Goal
 >
 >       - An important non-goal is Zope instance creation.  The software
 >         packaging mechanism will be responsible for installing
 >         software. It will generally not be responsible for setting up
 >         Zope instances. Rather, among the software installed will be
 >         software for creating Zope instances.

I agree with that being a non-goal. It should be easy for distribution 
makers to create custom instances after the software itself has been 
installed. I think the Plone people are already doing it with their 
Plone Controller... Eventually, we might provide a few hooks, though. 
But we indeed should not worry about that right now.

 >         We should strive to have needed distutils improvements ready
 >         for inclusion in Python 2.4.
...
 >       We use the term "package" to refer *both* to Python packages and
 >       to units of software distribution.  There will often, but not
 >       always be a one-to-one correspondence between software
 >       distribution packages and Python packages.   Distutils attempts
 >       to solve this by refering to software distributions as "module
 >       distributions". I (Jim) find this rather unsatisfying.  This is
 >       an issue that will, ultimately, need to be resolved by the
 >       Python community. We will follow thier lead.
 >
 >     Possible vision
 >
 >       - Work with the Python community at large to extend distutils
 >         to manage information necessary for packaging and create a
 >         simple package-management system for python.

I see why you would like the Python community to help solve this 
problem. I hope you do realize though that we will depend on them in 
this issue. Now, it might be an advantage for you having the majority of 
PythonLabs right next door to your office; but that doesn't change the 
fact that we're going to involve a much bigger community with different 
ideas, etc.

The inevitable result is that this process will take a long time until 
the ideas are set, the infrastructure is in place and stable software is 
produces. We might make it for Python 2.4, but only if we're lucky.

My focus of interest has been the Zope3 package hierarchy. The 
discussion on package and dependency management was kind of started by 
this issue in the first place. So they are connected. But I think the 
links between them are limited, and we should keep it that way. 
Obviously, the package and dependency management needs certain 
requirements to be fullfilled by the Zope3 package hierarchy, which you 
have mentioned:

 >       - Liberate the Zope repository from having to reflect
 >         distribution or packages status (e.g. core or not core.)

 >       - Provide a simpler repository layout to make Zope 3 software
 >         easier to understand and navigate.

 >         Note that source and binary distributions may not look
 >         anything like the CVS repository.

The fact that the packaging/distutils issue will take long time, 
shouldn't stop us from rearranging the Zope3 package hierarchy, though. 
I think we *should* come up with a proposal for that soon, and I think 
we should implement it a.s.a.p. I see the packaging/distutils issue 
decoupled from the package hierarchy issue in the sense that we should 
still go ahead with the latter without being stopped by the former, and 
we should only keep in mind the points mentioned by you above.

We also will have to face the fact that we might not get the 
packaging/dependency management system until after Zope X3.0 has been 
released.

 >       We are aware of a number of issues using distutils to package
 >       Zope software. These are collected here so we can seek to
 >       address them in this project:
 >
 >       - Lack of dependency data needed to support a packaging
 >         system. See PEP 262.

I don't find PEP 262 useful at all for this issue. Other people have 
pointed their fingers towards Linux distribution package managers and 
their format of package dependency description. I think a package file 
format similar to RedHat's dst files, the output of Debian's apt-cache 
show or the listings provided by Gentoo users are good templates to work 
with.

Philipp


From philipp at weitershausen.de  Sun Feb 15 14:16:48 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Sun Feb 15 14:10:08 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <402FA0DB.1030406@zope.com>
References: <402FA0DB.1030406@zope.com>
Message-ID: <402FC5A0.5020701@weitershausen.de>

Jim,

> I sent this earlier in response in another thread, but didn't
> get any response.  I'd be happy to assume no one disagrees
> and accept silence as assent, but, I thought this would be more
> controversal and a terser version got -1's before, so, here it is
> again.  :)

I actually wanted to respond to this and didn't find it in the labyrinth 
of recent packaging threads. :) So, please take this as a big yell to 
cut the silence.

> I think that continueing to separate presentations has a number
> of advantages:
> 
> - It *does* make iteasier for people who just want to modify
>   presentations to find them.

Yup.

> - It makes it clearer that presentatations are pluggable and how

We need to make that *very* clear now. I like to talk to experienced 
Zope2 developers from time to time and have them tell me how they cope 
with application vs. presentation code in large applications. A few 
people have come up with their own frameworks of making presentation 
pluggable in one way or another. Of course, they still have to keep 
everything in one place, 'cause it's Zope2.

The fact that application code, presentation, security, configuration is 
all in different places in Zope3 repells these people (as they have told 
me so personally). So we need to make this separation very attractive in 
a practical and convenient sense.

> The disadvantages of separate subpackages are:
> 
> - More packages, some of which are very small

That's ok. I rather have many small items than few large items.
(modules like zope/app/browser/form/widget.py with >1100 lines scare the 
hell out of me).

> - More navigation, but the navigation is simple under the new
>   shallow organization.  For example, if I'm in foo and I want
>   to get to the directory with the browser code, I only have to
>   cd to ../foo_browser, which isn't so bad.

We need to reduce navigation, for the reason I've stated above: not to 
confuse and scare away people that are not familiar with that scheme.

> I think that the advantages of separating the presentation code far 
> outweigh the disadvantages.

Agreed.

> Note that we won't separate interface code except in the case of 
> "framework" packages that define pluggable frameworks with interfaces
> where there are expected to be multiple implemantations.

+1

> So, I feel rather strongly that we should have packages like:
> 
> folder
> folder_browser
> file
> file_browser

I don't have a constructive competitive idea, but I firmly dislike the 
underscore. Could be that this is a matter of taste. I wish I had an 
idea of my own. All I can do right now is think aloud:

<thinking-out-loud-mode>

What if we had

- zope.app   -- containing flat packages with application code
- zope.browser   -- containing just as flat packages with browser code
- zope.webdav   -- ........ with WebDAV presentation

Hmm... What about a different top-level package?

- zope.app  -- containing flat packages with application code
- zopepresent.browser  -- contains flat browser packages
- zopepresent.webdav  -- contains flat WebDAV packages

Or a different top-level package for each presentation type?

- zope.app  -- containing flat packages with application code
- zopebrowser  -- contains flat browser packages
- zopedav  -- contains flat WebDAV packages

</thinking-out-loud-mode>

> and so on. Note, again, that this separation is a good bit different
> than what we have now. The presentation code is *close* to the application
> code while still being separate.

But it'll look as if it were on the same hierarchical 'layer', while 
conceptually it's not. I still think of it as a trabant, a satellite of 
the actual application code-containing package. An exchangeable 
satellite, if you want :).

> Silence is assent. :)

Waaaaaaaaaaaaaaaaaaaaaaaaaaaa. :)


Philipp


From philipp at weitershausen.de  Sun Feb 15 17:57:54 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Sun Feb 15 17:51:12 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <402FC5A0.5020701@weitershausen.de>
References: <402FA0DB.1030406@zope.com> <402FC5A0.5020701@weitershausen.de>
Message-ID: <402FF972.6080605@weitershausen.de>

Philipp von Weitershausen wrote:
> <thinking-out-loud-mode>
> 
> What if we had
> 
> - zope.app   -- containing flat packages with application code
> - zope.browser   -- containing just as flat packages with browser code
> - zope.webdav   -- ........ with WebDAV presentation
> 
> Hmm... What about a different top-level package?
> 
> - zope.app  -- containing flat packages with application code
> - zopepresent.browser  -- contains flat browser packages
> - zopepresent.webdav  -- contains flat WebDAV packages
> 
> Or a different top-level package for each presentation type?
> 
> - zope.app  -- containing flat packages with application code
> - zopebrowser  -- contains flat browser packages
> - zopedav  -- contains flat WebDAV packages
> 
> </thinking-out-loud-mode>

I took this crazy idea one step further: Why not make zope.app a 
top-level package as well?

Consider:

- zope      -- contains general application code, just like now
- zopeapp    -- like zope.app above (flat packages, etc.)
- zopebrowser -- like above
- ...

I really like this one. And it'll make packaging easy, too. Don't want 
the Zope application server? Don't install zopeapp! Don't want browser 
code? Don't install zopebrowser!

Using several top-level packages has the following advantages:

- The package hierarchy is not deep at all. In fact, it'll be even less 
deep than with zope.app.foo and zope.app.foo_browser...

- Browser and application packages are not in the same container 
package. That'll help to make the pluggability of presentation code 
quite clear.

- It'll make source code navigation pretty easy. You have zope.XYZ or 
zopeapp.XYZ and need to find its browser views? Well, simply look in 
zopebrowser.XYZ. Pretty easy to find, I think.


I see the following disadvantages:

- The top-level package namespaces will be bloated. This danger is 
limited, though, since we can safely assume than other people will not 
make packages starting with the 'zope' prefix.

- The "core" of Zope (whatever that is) will be spread over several 
top-level packages. People might consider this unaesthetic.



Having-found-my-own-idea-after-all-ly,

Philipp


From faassen at infrae.com  Mon Feb 16 04:45:29 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Mon Feb 16 04:47:21 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <402D17B2.9040809@zope.com>
References: <402D17B2.9040809@zope.com>
Message-ID: <20040216094528.GA10775@vet.uu.nl>

Jim Fulton wrote:
> 
> There seems to be a possible consensus emerging that we should
> use a packaging system.  I suggest that we should use an existing
> system (or systems) such as RPM or the debian system and
> provide the ability to generate course-grained distributions
> from these systems for those systems (e.g. windows) that either
> don't have package systems or don't have package systems that
> we support.

Why not Python distutils and go from there? There are ways to create
RPMs from these, and I imagine .debs as well (I use Debian but haven't
tried yet).

Regards,

Martijn


From faassen at infrae.com  Mon Feb 16 04:57:05 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Mon Feb 16 04:58:56 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <402FBC31.6040108@weitershausen.de>
References: <402F90E3.3040303@zope.com> <402FBC31.6040108@weitershausen.de>
Message-ID: <20040216095705.GB10775@vet.uu.nl>

Philipp von Weitershausen wrote:
> >       - Work with the Python community at large to extend distutils
> >         to manage information necessary for packaging and create a
> >         simple package-management system for python.
> 
> I see why you would like the Python community to help solve this 
> problem. I hope you do realize though that we will depend on them in 
> this issue. Now, it might be an advantage for you having the majority of 
> PythonLabs right next door to your office; but that doesn't change the 
> fact that we're going to involve a much bigger community with different 
> ideas, etc.

Note that "The Python Community" has had several attempts to improve the
packaging situation for Python (CPAN for Python projects, etc) for
the last 6 years at least. Eventually people realized that it was hard to
introduce all of this at once, and they started working in steps:

 * distutils

 * simple packaging metadata

 * system on python.org (pypi) that indexes this information

As long as we realize that this won't be easy, I guess we could introduce
new steps:

 * declarative package information used by setup.py

 * declaration for dependency structure

> The inevitable result is that this process will take a long time until 
> the ideas are set, the infrastructure is in place and stable software is 
> produces. We might make it for Python 2.4, but only if we're lucky.

Agreed. I also think the attempt should be made to improve the common
infrastructure nonetheless, even if we think 2.4 is hard to reach for
inclusion.

[snip]
> The fact that the packaging/distutils issue will take long time, 
> shouldn't stop us from rearranging the Zope3 package hierarchy, though. 

Agreed. We shouldn't start to wait for possible future abilities to start
doing what we can to make life easier *now*.

[snip]
> We also will have to face the fact that we might not get the 
> packaging/dependency management system until after Zope X3.0 has been 
> released.

"Might not get" is hopefully "certainly won't have". If Zope X3.0 wants to
be released this year we'd better not wait for a dependency management
system to be done before it. :)

Regards,

Martijn


From faassen at infrae.com  Mon Feb 16 04:59:28 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Mon Feb 16 05:01:17 2004
Subject: [Zope3-dev] Separate presentation packages
In-Reply-To: <402FA0DB.1030406@zope.com>
References: <402FA0DB.1030406@zope.com>
Message-ID: <20040216095927.GC10775@vet.uu.nl>

Jim Fulton wrote:
> So, I feel rather strongly that we should have packages like:
> 
> folder
> folder_browser
> file
> file_browser

I thought people already said in another thread that they didn't like
this. :)

Python already provides a namespacing mechanism, involving the dot notation
(foo.browser). You're inventing your own prefix based namespace mechanism 
here. Prefix based namespace mechanisms aren't necessary in Python and
seeing one is a bad code smell.

Regards,

Martijn


From jim at zope.com  Mon Feb 16 05:27:37 2004
From: jim at zope.com (Jim Fulton)
Date: Mon Feb 16 05:28:18 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <402FC5A0.5020701@weitershausen.de>
References: <402FA0DB.1030406@zope.com> <402FC5A0.5020701@weitershausen.de>
Message-ID: <40309B19.4040000@zope.com>

Philipp von Weitershausen wrote:
> 

...

I said a disadvantage was:

>> - More navigation, but the navigation is simple under the new
>>   shallow organization.  For example, if I'm in foo and I want
>>   to get to the directory with the browser code, I only have to
>>   cd to ../foo_browser, which isn't so bad.
> 

and you agreed:

> We need to reduce navigation, for the reason I've stated above: not to 
> confuse and scare away people that are not familiar with that scheme.

...

>> So, I feel rather strongly that we should have packages like:
>>
>> folder
>> folder_browser
>> file
>> file_browser
> 
> 
> I don't have a constructive competitive idea, but I firmly dislike the 
> underscore. Could be that this is a matter of taste. I wish I had an 
> idea of my own. All I can do right now is think aloud:
> 
> <thinking-out-loud-mode>
> 
> What if we had
> 
> - zope.app   -- containing flat packages with application code
> - zope.browser   -- containing just as flat packages with browser code
> - zope.webdav   -- ........ with WebDAV presentation
> 
> Hmm... What about a different top-level package?
> 
> - zope.app  -- containing flat packages with application code
> - zopepresent.browser  -- contains flat browser packages
> - zopepresent.webdav  -- contains flat WebDAV packages
> 
> Or a different top-level package for each presentation type?
> 
> - zope.app  -- containing flat packages with application code
> - zopebrowser  -- contains flat browser packages
> - zopedav  -- contains flat WebDAV packages
> 
> </thinking-out-loud-mode>


But this moves things far apart.  Now the packages relared to foo
are in different trees.  I think foo-related-ness is at least as important
as browser relatedness.  I *hate* looking in different trees for browser
and application code related to a topic.


>> and so on. Note, again, that this separation is a good bit different
>> than what we have now. The presentation code is *close* to the 
>> application
>> code while still being separate.
> 
> 
> But it'll look as if it were on the same hierarchical 'layer',

Right. That's a good thing. I can see foo and foo_browser together
in one place.

 > while
> conceptually it's not. I still think of it as a trabant, a satellite of 
> the actual application code-containing package. An exchangeable 
> satellite, if you want :).

Yes. I expect to find satallites close to their primary bodies, not off
in a separate solar system.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Mon Feb 16 05:38:51 2004
From: jim at zope.com (Jim Fulton)
Date: Mon Feb 16 05:39:29 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <402FF972.6080605@weitershausen.de>
References: <402FA0DB.1030406@zope.com> <402FC5A0.5020701@weitershausen.de>
	<402FF972.6080605@weitershausen.de>
Message-ID: <40309DBB.6090605@zope.com>

Philipp von Weitershausen wrote:
> Philipp von Weitershausen wrote:
> 
>> <thinking-out-loud-mode>
>>
>> What if we had
>>
>> - zope.app   -- containing flat packages with application code
>> - zope.browser   -- containing just as flat packages with browser code
>> - zope.webdav   -- ........ with WebDAV presentation
>>
>> Hmm... What about a different top-level package?
>>
>> - zope.app  -- containing flat packages with application code
>> - zopepresent.browser  -- contains flat browser packages
>> - zopepresent.webdav  -- contains flat WebDAV packages
>>
>> Or a different top-level package for each presentation type?
>>
>> - zope.app  -- containing flat packages with application code
>> - zopebrowser  -- contains flat browser packages
>> - zopedav  -- contains flat WebDAV packages
>>
>> </thinking-out-loud-mode>
> 
> 
> I took this crazy idea one step further: Why not make zope.app a 
> top-level package as well?
> 
> Consider:
> 
> - zope      -- contains general application code, just like now
> - zopeapp    -- like zope.app above (flat packages, etc.)
> - zopebrowser -- like above
> - ...
> 
> I really like this one. And it'll make packaging easy, too. Don't want 
> the Zope application server? Don't install zopeapp! Don't want browser 
> code? Don't install zopebrowser!

It doesn't make packaging any easier, IMO.  You still have container packages
that you need to install things into. (That reminds me of another
distutils issue.)

> Using several top-level packages has the following advantages:
> 

But that moves things that are closely related (application code for
some topic and the presentation code for some topic) far apart.


> - The package hierarchy is not deep at all. In fact, it'll be even less 
> deep than with zope.app.foo and zope.app.foo_browser...

This is only because you are using a naming convention, a zope
prefix, as a substiture for structure. This is what you objected
to originally.

> - Browser and application packages are not in the same container 
> package. That'll help to make the pluggability of presentation code 
> quite clear.

At the cost of too much distance. This is what we have now, and I
think it's a disaster.

> - It'll make source code navigation pretty easy. You have zope.XYZ or 
> zopeapp.XYZ and need to find its browser views? Well, simply look in 
> zopebrowser.XYZ. Pretty easy to find, I think.

I think it's pretty jarring. This is what we have now.  (Well,
what we have now is worse, because of different levels within
the app and browser hierarchies.

> 
> I see the following disadvantages:
> 
> - The top-level package namespaces will be bloated. This danger is 
> limited, though, since we can safely assume than other people will not 
> make packages starting with the 'zope' prefix.

You are using the same thing you objected to before, a naming convention
as a substiture for structure.

> - The "core" of Zope (whatever that is) will be spread over several 
> top-level packages. People might consider this unaesthetic.

*everything* is separated over multiple trees. This is what we have now
and I think most people hate it.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Mon Feb 16 05:41:18 2004
From: jim at zope.com (Jim Fulton)
Date: Mon Feb 16 05:41:58 2004
Subject: [Zope3-dev] Separate presentation packages
In-Reply-To: <20040216095927.GC10775@vet.uu.nl>
References: <402FA0DB.1030406@zope.com> <20040216095927.GC10775@vet.uu.nl>
Message-ID: <40309E4E.2040002@zope.com>

Martijn Faassen wrote:
> Jim Fulton wrote:
> 
>>So, I feel rather strongly that we should have packages like:
>>
>>folder
>>folder_browser
>>file
>>file_browser
> 
> 
> I thought people already said in another thread that they didn't like
> this. :)

Some people did, but I think we need more discussion.

> Python already provides a namespacing mechanism, involving the dot notation
> (foo.browser). You're inventing your own prefix based namespace mechanism 
> here. Prefix based namespace mechanisms aren't necessary in Python and
> seeing one is a bad code smell.

True, but then too much hierarchy is considered unpythonic. <shrug>

I have reasons why I thought this was better, twice, so I won't
repeat them.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From philipp at weitershausen.de  Mon Feb 16 07:04:16 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Mon Feb 16 06:57:38 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <20040216095705.GB10775@vet.uu.nl>
References: <402F90E3.3040303@zope.com> <402FBC31.6040108@weitershausen.de>
	<20040216095705.GB10775@vet.uu.nl>
Message-ID: <4030B1C0.4060005@weitershausen.de>

Martijn Faassen wrote:
> Note that "The Python Community" has had several attempts to improve the
> packaging situation for Python (CPAN for Python projects, etc) for
> the last 6 years at least.

If you want my frank opinion, I think that's very pathetic. We're not 
even close to what Perl has...

> Eventually people realized that it was hard to
> introduce all of this at once, and they started working in steps:
> 
>  * distutils
> 
>  * simple packaging metadata
> 
>  * system on python.org (pypi) that indexes this information
> 
> As long as we realize that this won't be easy, I guess we could introduce
> new steps:
> 
>  * declarative package information used by setup.py
> 
>  * declaration for dependency structure

Yes. I really hope that it'll be possible to use the already existing 
infrastructure (distutils, metadata, pypi). I personally have my doubts 
with both the solution with respect to the infrastructure and the 
time-frame. Remember how Zope came up with its own interface definitions 
because Python didn't have them?... :)

>>We also will have to face the fact that we might not get the 
>>packaging/dependency management system until after Zope X3.0 has been 
>>released.
> 
> "Might not get" is hopefully "certainly won't have". If Zope X3.0 wants to
> be released this year we'd better not wait for a dependency management
> system to be done before it. :)

Yes, I totally agree. I should have phrased it like that.

Philipp


From philipp at weitershausen.de  Mon Feb 16 07:15:31 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Mon Feb 16 07:08:46 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <40309B19.4040000@zope.com>
References: <402FA0DB.1030406@zope.com> <402FC5A0.5020701@weitershausen.de>
	<40309B19.4040000@zope.com>
Message-ID: <4030B463.90806@weitershausen.de>

Jim Fulton wrote:
> I said a disadvantage was:
> 
>>> - More navigation, but the navigation is simple under the new
>>>   shallow organization.  For example, if I'm in foo and I want
>>>   to get to the directory with the browser code, I only have to
>>>   cd to ../foo_browser, which isn't so bad.
> 
> and you agreed:
> 
>> We need to reduce navigation, for the reason I've stated above: not to 
>> confuse and scare away people that are not familiar with that scheme.

Yes. All I'm saying is that we need to make it extemely easy to 
understand and even easier to grok the package hierarchy.

>>> So, I feel rather strongly that we should have packages like:
>>>
>>> folder
>>> folder_browser
>>> file
>>> file_browser
>>
>> I don't have a constructive competitive idea, but I firmly dislike the 
>> underscore. Could be that this is a matter of taste. I wish I had an 
>> idea of my own. All I can do right now is think aloud:
>>
>> <thinking-out-loud-mode>
>>
>> What if we had
>>
>> - zope.app   -- containing flat packages with application code
>> - zope.browser   -- containing just as flat packages with browser code
>> - zope.webdav   -- ........ with WebDAV presentation
>>
>> Hmm... What about a different top-level package?
>>
>> - zope.app  -- containing flat packages with application code
>> - zopepresent.browser  -- contains flat browser packages
>> - zopepresent.webdav  -- contains flat WebDAV packages
>>
>> Or a different top-level package for each presentation type?
>>
>> - zope.app  -- containing flat packages with application code
>> - zopebrowser  -- contains flat browser packages
>> - zopedav  -- contains flat WebDAV packages
>>
>> </thinking-out-loud-mode>
> 
> But this moves things far apart.  Now the packages relared to foo
> are in different trees.

I realize that it is less convenient for immediatedly practical 
navigation. It think it'll be easier to understand, though.

> I think foo-related-ness is at least as important
> as browser relatedness.

Too bad their two different kinds of relatednesses. We would really need 
three-dimensional directory trees.

> I *hate* looking in different trees for browser and application code
> related to a topic.

Fair enough, I can see why.

>>> and so on. Note, again, that this separation is a good bit different
>>> than what we have now. The presentation code is *close* to the 
>>> application
>>> code while still being separate.
>>
>> But it'll look as if it were on the same hierarchical 'layer',
> 
> Right. That's a good thing. I can see foo and foo_browser together
> in one place.

But they are not two of a kind. That's what I was trying to say::

>> conceptually it's not. I still think of it as a trabant, a satellite 
>> of the actual application code-containing package. An exchangeable 
>> satellite, if you want :).
> 
> Yes. I expect to find satallites close to their primary bodies, not off
> in a separate solar system.

I'm thinking more of a parallel universe :). Seriously, the relation foo 
to foo_browser is a different one than foo to bar:

zope.foo ---browser-package---> zope.foo_browser
zope.foo ---peer-package---> zope.bar

Philipp


From philipp at weitershausen.de  Mon Feb 16 07:22:22 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Mon Feb 16 07:15:39 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <40309DBB.6090605@zope.com>
References: <402FA0DB.1030406@zope.com>
	<402FC5A0.5020701@weitershausen.de>	<402FF972.6080605@weitershausen.de>
	<40309DBB.6090605@zope.com>
Message-ID: <4030B5FE.8010306@weitershausen.de>

Jim Fulton wrote:
>> I really like this one. And it'll make packaging easy, too. Don't want 
>> the Zope application server? Don't install zopeapp! Don't want browser 
>> code? Don't install zopebrowser!
> 
> It doesn't make packaging any easier, IMO.  You still have container 
> packages that you need to install things into.

Why is that a problem?

>> Using several top-level packages has the following advantages:
> 
> But that moves things that are closely related (application code for
> some topic and the presentation code for some topic) far apart.

 From a physical point of view, yes. From a hierarchy point of view, no.

>> - Browser and application packages are not in the same container 
>> package. That'll help to make the pluggability of presentation code 
>> quite clear.
> 
> At the cost of too much distance. This is what we have now, and I
> think it's a disaster.

You're right, the distance is bigger. That is a clear disadvantage of my 
idea.

>> - It'll make source code navigation pretty easy. You have zope.XYZ or 
>> zopeapp.XYZ and need to find its browser views? Well, simply look in 
>> zopebrowser.XYZ. Pretty easy to find, I think.
> 
> I think it's pretty jarring. This is what we have now.  (Well,
> what we have now is worse, because of different levels within
> the app and browser hierarchies.

Right, what we have is worse! Much worse.

With zope, zopeapp, zopebrowser, etc. There will be two levels of depth 
usually. (zope.foo, zopeapp.foo, zopebrowser.foo), and normally you'll 
always be working in level 2. The only times you would have to descent 
into level 3 would be for tests or when 'interfaces' becomes a package.

>> I see the following disadvantages:
>>
>> - The top-level package namespaces will be bloated. This danger is 
>> limited, though, since we can safely assume than other people will not 
>> make packages starting with the 'zope' prefix.
> 
> You are using the same thing you objected to before, a naming convention
> as a substiture for structure.

I objected it not for being what it is. I objected it because of taste...

>> - The "core" of Zope (whatever that is) will be spread over several 
>> top-level packages. People might consider this unaesthetic.
> 
> *everything* is separated over multiple trees. This is what we have now
> and I think most people hate it.

You can't separate and keep stuff together at the same time. What do we 
weigh more important? Do we want to

- emphasize separation OR make navigation easier?
- allow easy customization OR have compact structures?
- have a scrutable hierarchy (IOW, flat but meaningful) OR minimize 
distance?

Philipp


From philipp at weitershausen.de  Mon Feb 16 07:29:13 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Mon Feb 16 07:22:26 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <40309E4E.2040002@zope.com>
References: <402FA0DB.1030406@zope.com> <20040216095927.GC10775@vet.uu.nl>
	<40309E4E.2040002@zope.com>
Message-ID: <4030B799.2050109@weitershausen.de>

Jim Fulton wrote:
> Martijn Faassen wrote:
> 
>> Jim Fulton wrote:
>>
>>> So, I feel rather strongly that we should have packages like:
>>>
>>> folder
>>> folder_browser
>>> file
>>> file_browser
>>
>> I thought people already said in another thread that they didn't like
>> this. :)
> 
> Some people did, but I think we need more discussion.

Yes, I would like to hear what other people have to say about this. I 
admittedly belong to those who don't like the underscore solution, but I 
also realize that my idea is just thinking-out-loud (which should still 
be discussed, IMO). There must be other people with better ideas, I hope.

>> Python already provides a namespacing mechanism, involving the dot 
>> notation
>> (foo.browser). You're inventing your own prefix based namespace 
>> mechanism here. Prefix based namespace mechanisms aren't necessary in 
>> Python and
>> seeing one is a bad code smell.
> 
> True, but then too much hierarchy is considered unpythonic. <shrug>

I consider too much hierarchy very Prussian :). IOW I don't think it's 
pythonic nor unpythonic. It's a pattern you choose or not.

Philipp


From anthony at interlink.com.au  Mon Feb 16 07:32:35 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Mon Feb 16 07:33:26 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <4030B1C0.4060005@weitershausen.de>
References: <402F90E3.3040303@zope.com>
	<402FBC31.6040108@weitershausen.de>	<20040216095705.GB10775@vet.uu.nl>
	<4030B1C0.4060005@weitershausen.de>
Message-ID: <4030B863.309@interlink.com.au>

Philipp von Weitershausen wrote:
> Martijn Faassen wrote:
> 
>> Note that "The Python Community" has had several attempts to improve the
>> packaging situation for Python (CPAN for Python projects, etc) for
>> the last 6 years at least.
> 
> 
> If you want my frank opinion, I think that's very pathetic. We're not 
> even close to what Perl has...

"Send Code".

Sorry, but this stuff is hard. The people who're trying to work on it 
have to do this in their spare time - for instance, the current pypi 
system.

There's always lots of "why doesn't python have a CPAN" complaints, but 
very few people who're willing to help fix the problem.

Anthony, slightly cranky.

From philipp at weitershausen.de  Mon Feb 16 08:05:20 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Mon Feb 16 07:58:44 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <4030B863.309@interlink.com.au>
References: <402F90E3.3040303@zope.com>	<402FBC31.6040108@weitershausen.de>	<20040216095705.GB10775@vet.uu.nl>	<4030B1C0.4060005@weitershausen.de>
	<4030B863.309@interlink.com.au>
Message-ID: <4030C010.80306@weitershausen.de>

Anthony Baxter wrote:
> Philipp von Weitershausen wrote:
> 
>> Martijn Faassen wrote:
>>
>>> Note that "The Python Community" has had several attempts to improve the
>>> packaging situation for Python (CPAN for Python projects, etc) for
>>> the last 6 years at least.
>>
>> If you want my frank opinion, I think that's very pathetic. We're not 
>> even close to what Perl has...
> 
> "Send Code".

It's not that easy. People in "higher places" have their own ideas. You 
have to make proposal, they get rejected, or at least discussed for a 
long, long time. I realize that I'm accusing here without being much 
constructive, but you also have to think about what a burden 
constructiveness can mean for the average Joe Python programmer as I 
am... But let's not get into that...

Somehow I knew that this would fling back at me. I didn't intend to 
point my finger at something. I just find the situation a little 
pathetic, that's all. If OpenSource is about "contribute or die", IOW 
don't even think about opening your mouth unless you can contribute, 
then I'd rather not be a part of it... :)

Philipp


From tseaver at zope.com  Mon Feb 16 11:11:07 2004
From: tseaver at zope.com (Tres Seaver)
Date: Mon Feb 16 11:11:18 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <4030B863.309@interlink.com.au>
References: <402F90E3.3040303@zope.com>	<402FBC31.6040108@weitershausen.de>	<20040216095705.GB10775@vet.uu.nl>	<4030B1C0.4060005@weitershausen.de>
	<4030B863.309@interlink.com.au>
Message-ID: <4030EB9B.1030300@zope.com>

Anthony Baxter wrote:
> Philipp von Weitershausen wrote:
> 
>> Martijn Faassen wrote:
>>
>>> Note that "The Python Community" has had several attempts to improve the
>>> packaging situation for Python (CPAN for Python projects, etc) for
>>> the last 6 years at least.
>>
>>
>>
>> If you want my frank opinion, I think that's very pathetic. We're not 
>> even close to what Perl has...
> 
> 
> "Send Code".

PEPs *do* get rejected, even those with clear-and-present usage in the 
field (interfaces, for instance).

> Sorry, but this stuff is hard. The people who're trying to work on it 
> have to do this in their spare time - for instance, the current pypi 
> system.

Note that PyPI invested effort to add Trove metadata, which I would call 
"nice-to-have", and left out dependencies, which I would call "crucial". 
  I am not trivializing the effort required to add dependencies, either; 
  I just don't consider PyPI very useful without them.

> There's always lots of "why doesn't python have a CPAN" complaints, but 
> very few people who're willing to help fix the problem.
> 
> Anthony, slightly cranky.

The current distutils implementation makes too many assumptions about 
how Python-based solutions are to be distributed / installed;  in 
particular, its sweet spot could be described as "installing a 
standalone module / package into site-packages."  Almost *any* of the 
non-particles in that prhase can be reasonably challenged:

   'installing' -- I need to be able to *package* software for
     later installation;  distutils won't be involved in putting
     the actual bits onto the deployed system.

   'standalone' -- distutils no mechanisms for describing dependencies,
     which may be largely an artifact of how the standard library is
     organized (and the fact that the standard library is so big).

   'package / module' -- distutils is weak in its handling of
     "applications", in particular w.r.t. the "data" part.

   'site-packages' -- I almost *never* want to write into the
     Python library when I install application-related stuff.

We should adopt a mechanism for expressing explicit dependencies, and 
beat out a framework over distutils which uses it;  we will then be in a 
position to nominate that framework for inclusion in 2.5 (I would guess; 
  I don't know how close to a freeze 2.4 is today), and be able to move 
on even if, as with interfaces, Python doesn't adopt our nominee.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com


From tseaver at zope.com  Mon Feb 16 11:20:49 2004
From: tseaver at zope.com (Tres Seaver)
Date: Mon Feb 16 11:20:59 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <20040216094528.GA10775@vet.uu.nl>
References: <402D17B2.9040809@zope.com> <20040216094528.GA10775@vet.uu.nl>
Message-ID: <4030EDE1.5070801@zope.com>

Martijn Faassen wrote:
> Jim Fulton wrote:
> 
>>There seems to be a possible consensus emerging that we should
>>use a packaging system.  I suggest that we should use an existing
>>system (or systems) such as RPM or the debian system and
>>provide the ability to generate course-grained distributions
>>from these systems for those systems (e.g. windows) that either
>>don't have package systems or don't have package systems that
>>we support.
> 
> 
> Why not Python distutils and go from there? There are ways to create
> RPMs from these, and I imagine .debs as well (I use Debian but haven't
> tried yet).

I am not very happy with a couple of things about the RPM generation 
done by distutils (see my other post about the assumptions made by 
distutils).  At a minimum, we will need to extend disttils in a couple 
of places:

   - Move the metadata *out* of the setup.py file (in fact, most packages
     should *not* require an explicit setup.py file at all!);

   - Make it trivial to include "data" (e.g., page template files,
     images, ZCML, documentation) along with code (distutils is
     pathetic in its handling of "data");

   - Capture dependency information.

Note that if all this data is available in some declarative format, 
generating a .spec file (or whatever Debian's analog is called) will be 
a mechanical process for 99% of the things we need to pacakge.

If we can manage such extensions over distutils, that would be great; 
we should then nominate them for inclusion at the language level.  If we 
can't, then that is also OK;  we should be prepared to move forward 
either way.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com


From pje at telecommunity.com  Mon Feb 16 11:35:23 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon Feb 16 11:32:41 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <4030EDE1.5070801@zope.com>
References: <20040216094528.GA10775@vet.uu.nl> <402D17B2.9040809@zope.com>
	<20040216094528.GA10775@vet.uu.nl>
Message-ID: <5.1.0.14.0.20040216112913.023a2b90@mail.telecommunity.com>

At 11:20 AM 2/16/04 -0500, Tres Seaver wrote:
>If we can manage such extensions over distutils, that would be great; we 
>should then nominate them for inclusion at the language level.  If we 
>can't, then that is also OK;  we should be prepared to move forward either way.

The nice thing about distutils is that it *is* well-designed with respect 
to being able to replace its commands.

Alas, it's not always so well-factored when it comes to subclassing its 
built-in commands.  Many commands have a tendency to factor out all the 
easy parts into lots of little methods, and then do the hard parts in 
really huge methods, or a handful of midsize methods that carry a host of 
assumptions between them.  So, to do anything "interesting" with a command 
subclass you end up with lots of code duplication, copying from the 
original implementation so you can change some minor detail in the middle 
of a huge method.

What that means is that we'll probably want to see if we can get patches 
accepted that refactor the base functionality of certain commands for 
easier subclassing, in the event that the extended functionality we want is 
considered out-of-scope or something for distutils itself.


From srichter at cosmos.phy.tufts.edu  Mon Feb 16 06:45:02 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Mon Feb 16 12:52:42 2004
Subject: [Zope3-dev] Separate presentation packages
In-Reply-To: <402FA0DB.1030406@zope.com>
References: <402FA0DB.1030406@zope.com>
Message-ID: <200402160645.02867.srichter@cosmos.phy.tufts.edu>

On Sunday 15 February 2004 11:39, Jim Fulton wrote:
> So, I feel rather strongly that we should have packages like:
>
> folder
> folder_browser
> file
> file_browser
>
> and so on. Note, again, that this separation is a good bit different
> than what we have now. The presentation code is *close* to the application
> code while still being separate.

Okay, the more I look at it, the more I like it. However, the underscore is 
ugly and we should find a better notation/convention. I have no clue what 
yet.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From srichter at cosmos.phy.tufts.edu  Mon Feb 16 07:11:24 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Mon Feb 16 12:52:47 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <402FF972.6080605@weitershausen.de>
References: <402FA0DB.1030406@zope.com> <402FC5A0.5020701@weitershausen.de>
	<402FF972.6080605@weitershausen.de>
Message-ID: <200402160711.24984.srichter@cosmos.phy.tufts.edu>

On Sunday 15 February 2004 17:57, Philipp von Weitershausen wrote:
> > <thinking-out-loud-mode>
> >
> > What if we had
> >
> > - zope.app ? -- containing flat packages with application code
> > - zope.browser ? -- containing just as flat packages with browser code
> > - zope.webdav ? -- ........ with WebDAV presentation
> >
> > Hmm... What about a different top-level package?
> >
> > - zope.app ?-- containing flat packages with application code
> > - zopepresent.browser ?-- contains flat browser packages
> > - zopepresent.webdav ?-- contains flat WebDAV packages
> >
> > Or a different top-level package for each presentation type?
> >
> > - zope.app ?-- containing flat packages with application code
> > - zopebrowser ?-- contains flat browser packages
> > - zopedav ?-- contains flat WebDAV packages
> >
> > </thinking-out-loud-mode>
>
> I took this crazy idea one step further: Why not make zope.app a
> top-level package as well?
>
> Consider:
>
> - zope ? ? ?-- contains general application code, just like now
> - zopeapp ? ?-- like zope.app above (flat packages, etc.)
> - zopebrowser -- like above
> - ...

I find all these a step in the right direction. Certainly much cleaner than 
the underscore.

Regards,
Stephan
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From srichter at cosmos.phy.tufts.edu  Mon Feb 16 13:01:05 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Mon Feb 16 13:01:28 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <4030B799.2050109@weitershausen.de>
References: <402FA0DB.1030406@zope.com> <40309E4E.2040002@zope.com>
	<4030B799.2050109@weitershausen.de>
Message-ID: <200402161301.05882.srichter@cosmos.phy.tufts.edu>

On Monday 16 February 2004 07:29, Philipp von Weitershausen wrote:
> > True, but then too much hierarchy is considered unpythonic. <shrug>
>
> I consider too much hierarchy very Prussian :). IOW I don't think it's
> pythonic nor unpythonic. It's a pattern you choose or not.

Oh, that's why I like hierarchy (I really do; you should see my documents 
structure). I am from Prussia!

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From srichter at cosmos.phy.tufts.edu  Mon Feb 16 13:07:34 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Mon Feb 16 13:07:55 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <4030EB9B.1030300@zope.com>
References: <402F90E3.3040303@zope.com> <4030B863.309@interlink.com.au>
	<4030EB9B.1030300@zope.com>
Message-ID: <200402161307.34034.srichter@cosmos.phy.tufts.edu>

On Monday 16 February 2004 11:11, Tres Seaver wrote:
> We should adopt a mechanism for expressing explicit dependencies, and
> beat out a framework over distutils which uses it; ?we will then be in a
> position to nominate that framework for inclusion in 2.5 (I would guess;
> ? I don't know how close to a freeze 2.4 is today), and be able to move
> on even if, as with interfaces, Python doesn't adopt our nominee.

+1

I also liked your other mails. I think working well with distutils is a "nice 
to have", but if it makes our life miserable, then we should do our thing and 
propose it for Python later.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From faassen at infrae.com  Mon Feb 16 13:09:44 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Mon Feb 16 13:08:32 2004
Subject: [Zope3-dev] Separate presentation packages
In-Reply-To: <40309E4E.2040002@zope.com>
References: <402FA0DB.1030406@zope.com> <20040216095927.GC10775@vet.uu.nl>
	<40309E4E.2040002@zope.com>
Message-ID: <40310768.4060809@infrae.com>

Jim Fulton wrote:

> Martijn Faassen wrote:
>
>> Python already provides a namespacing mechanism, involving the dot 
>> notation (foo.browser). You're inventing your own prefix based 
>> namespace mechanism here. Prefix based namespace mechanisms aren't 
>> necessary in Python and seeing one is a bad code smell.
>
>
> True, but then too much hierarchy is considered unpythonic. <shrug>

So we need to find a way without prefixes and without too much hierarchy. :)

> I have reasons why I thought this was better, twice, so I won't
> repeat them.

Okay, I missed the first message initially.

Some observations.

In some sense, the browser package is not independent from the main 
package. If I am distributing my package to you, you'd need *two* 
packages in most cases, one browser, and one core. Of course there are 
cases where I'm distributing browser package only, and (less frequently) 
where the non-view package is being distributed separately, but the 
usual pattern is to distribute a package with its default views. Single 
package with both would make life easier for the common case.

Besides it being two packages, it also means you need to adjust your 
ZCML twice to include both browser as well as content package.

Then again, it becomes easier in ZCML to selectively disable a view 
package. Again though this is not the common case..

So by splitting it into two packages we're making the common case 
harder. Besides the namespace changes (especially invented for Zope, 
nobody else uses this, not Pythonic, etc), we're also making the common 
case more difficult.

You could say we should just improve the distribution mechanism, but 
this is a non-trivial task.

Of course, looking at a package system like debian, you do sometimes see 
a split between 'core app' and 'ui' package distributed separately. This 
is often because there's a command-like UI in the main package, or it's 
a client-server architecture, or the UI is developed by someone else, or 
there are multiple implementations of the UI already available. 
*Usually* however you only install a single package to have a functional 
UI however.

The reasons given for splitting off the UI are similar to this; we want 
the UI to be replacable, etc. But wanting and it being so are two 
different worlds, and we've already learned that structuring our app so 
we anticipate our wished-for reality doesn't necessarily lead to 
anything but extra overhead for the developers...

Regards,

Martijn


From srichter at cosmos.phy.tufts.edu  Mon Feb 16 13:21:52 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Mon Feb 16 13:22:14 2004
Subject: [Zope3-dev] Separate presentation packages
In-Reply-To: <40310768.4060809@infrae.com>
References: <402FA0DB.1030406@zope.com> <40309E4E.2040002@zope.com>
	<40310768.4060809@infrae.com>
Message-ID: <200402161321.52738.srichter@cosmos.phy.tufts.edu>

On Monday 16 February 2004 13:09, Martijn Faassen wrote:
> Besides it being two packages, it also means you need to adjust your
> ZCML twice to include both browser as well as content package.
>
> Then again, it becomes easier in ZCML to selectively disable a view
> package. Again though this is not the common case..
>
> So by splitting it into two packages we're making the common case
> harder. Besides the namespace changes (especially invented for Zope,
> nobody else uses this, not Pythonic, etc), we're also making the common
> case more difficult.

I think Martijn has a good point here. We are thinking so hard about the 5-10% 
of the time you have the uncommon case, that we forget about what people will 
usually want to do. And I bet now that it will not be common to replace the 
UI. It is just too much work to do it consistently. Look at Mozilla; there 
were only two themes (classic and modern) that were *completely* different 
and both of them were developed as part of Mozilla.

I would say that only a larger product like Plone would ever produce a second 
UI.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From Mailer-Daemon at python.org  Mon Feb 16 16:03:17 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Mon Feb 16 16:03:19 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1Asptd-0007go-BK@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1AspsZ-0007dN-8C; Mon, 16 Feb 2004 16:02:11 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [HowToContribute] what is a supporter? Any links?
Message-ID: <20040216160211EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/HowToContribute/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/HowToContribute/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/HowToContribute>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Mon, 16 Feb 2004 16:02:11 -0500
X-Spam-Status: OK (default 0.025)

??changed:
-  - Become a [Zope3Supporter].
-
-
  - Become a Zope 3 Supporter.
--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/HowToContribute

From Mailer-Daemon at python.org  Mon Feb 16 16:05:18 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Mon Feb 16 16:05:20 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1Aspva-0008Kq-E1@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1Asppl-0007Z9-4U; Mon, 16 Feb 2004 15:59:17 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [HowToContribute] 
Message-ID: <20040216155916EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/HowToContribute/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/HowToContribute/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/HowToContribute>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Mon, 16 Feb 2004 15:59:16 -0500
X-Spam-Status: OK (default 0.039)

??changed:
-  - Become a Zope3Supporter.
-
-
  - Become a [Zope3Supporter].
--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/HowToContribute

From jeremy at zope.com  Mon Feb 16 17:04:04 2004
From: jeremy at zope.com (Jeremy Hylton)
Date: Mon Feb 16 17:07:28 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <200402131816.59402.fred@zope.com>
References: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<200402131703.07139.fred@zope.com> <402D4DAF.10502@zope.com>
	<200402131816.59402.fred@zope.com>
Message-ID: <1076969043.23662.42.camel@localhost.localdomain>

On Fri, 2004-02-13 at 18:16, Fred Drake wrote:
> Dependency information is just one portion of a package's metadata.  It 
> should be included along with the other metadata related to the package 
> itself.  I'd be happy for it to live in the same place as the other package 
> metadata if we can get that to be in the right place: the package itself.
> 
> Using setup.py as a container for the package metadata has not worked well 
> as all, given how many setup.py scripts we maintain.

I haven't noticed any problems using ZODB3's setup.py to hold metadata. 
Did you have specific issues in mind?  Perhaps the metadata that is
currently in setup.py isn't that interesting -- a URL, email address,
description, and version number.

Several people have griped about having to put metadata in a Python
script.  I think they confusing policy and mechanism.  If a distutils
command needs metadata to operate, it must be passed to the setup()
call.  There's no requirement that the data passed to it be stored in a
script called setup.py or in any Python script.  You could put the
metadata in a file and write a helper routine that loads metadata to be
passed to setup.  (I'm not sure what the file format would be.  If I
have to write it by hand and my choices are Python and XML, I'll stick
with Python.)

Jeremy



From jeremy at zope.com  Mon Feb 16 17:05:03 2004
From: jeremy at zope.com (Jeremy Hylton)
Date: Mon Feb 16 17:08:28 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <4030EDE1.5070801@zope.com>
References: <402D17B2.9040809@zope.com> <20040216094528.GA10775@vet.uu.nl>
	<4030EDE1.5070801@zope.com>
Message-ID: <1076969103.23662.44.camel@localhost.localdomain>

On Mon, 2004-02-16 at 11:20, Tres Seaver wrote:
>    - Make it trivial to include "data" (e.g., page template files,
>      images, ZCML, documentation) along with code (distutils is
>      pathetic in its handling of "data");

There's widespread agreement on this point.  I think it would be fairly
straightforward to write a patch for distutils for 2.4 to make it handle
data usefully.

Jeremy



From pje at telecommunity.com  Mon Feb 16 18:13:13 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon Feb 16 18:10:47 2004
Subject: [Zope3-dev] PEAK 0.5a3 released
Message-ID: <5.1.0.14.0.20040216171628.026173e0@mail.telecommunity.com>

After several months of feature creep, the third alpha release of PEAK 0.5 
is now available for download at:

    http://peak.telecommunity.com/dist/

Some highlights of the changes since 0.5a2 include:

* A simplified and consolidated binding API: there are now only four kinds 
of bindings (Make, Obtain, Require, and Delegate) that provide a wider 
variety of functionality than the old API.  You can also now create your 
own IRecipe or IComponentKey implementations for use with Make and Obtain.

* The 'n2' (namespace navigator) tool provides a handy, extensible shell 
(with completion and history) for exploring PEAK naming systems and SQL 
connections.

* A greatly enhanced configuration file parser, with lots of new 
convenience features such as [Import on Demand], [Named Services], and 
[Component Factories] sections, based on its new extensible parsing 
framework.  You can define new section types of your own, even from inside 
an .ini file.

* New configuration key features, such as multi-keys (similar to some of 
Zope X3's "adaptergeddon" features), the ability to iterate over defined 
keys in a hierarchy (useful for finding/registering various kinds of 
"plugins"), new convenience features for defining wildcard property rules,

* A new 'peak.events' framework that supports event sources, listeners, 
subscriptions, generator-based pseudothreads ("tasks"), scheduling, and I/O 
events.  Using 'peak.events', you can write event-driven code in a more 
natural, sequential, "untwisted" style, but without giving up access to 
Twisted's many great features.  'peak.events' can use PEAK's built-in event 
loop, or adapt a Twisted reactor for use as an event loop.  You can also 
use Twisted's "Deferred" objects as event sources, which means you can use 
them in your Tasks (pseudothreads).

* A new 'peak.ddt' "document-driven testing" framework, similar in form and 
function to the FIT ( http://fit.c2.com/ ) framework, but in Python and 
well-integrated with the rest of PEAK.  'peak.ddt' lets you write test data 
as tables in HTML documents (created with Word, Open Office, Mozilla, or 
virtually any other tool), and then view the results in your 
browser.  Correct results are highlighted in green, incorrect answers are 
highlighted in red, and errors are highlighted in yellow, with a small-font 
traceback added to the table cell.  It's a great way to do data-driven 
acceptance testing, or to manage a project's progress using example data as 
part of a requirements document.

* Many, many more features, both large and small, like a pre-forking 
multiprocess supervisor for FastCGI and other forking servers.  Quick 
access to documentation via the 'peak help' command, which uses pydoc to 
display reference documentation.  Early versions of the 'peak.security' 
(access control), 'peak.web' (Zope X3-based web publishing), and 
'peak.query' (declarative relational and conceptual queries w/SQL 
generation) packages.  The 'whenImported()' function that lets you call a 
hook when a named module is first used.  "Mock" DBAPI and socket 
implementations for testing.  Hooks for "thunking" database-specific SQL 
and functions.  And many, many more examples of unbelievably blatant 
feature creep!

There is also now a nice "Hello World" introduction to PEAK available at:

http://peak.telecommunity.com/DevCenter/IntroToPeak

that presents a guided tour of some of PEAK's "vertical" frameworks, like 
command-line application support, database access, and so on.

For more information about PEAK, and access to community resources 
including documentation, the Wiki, mailing list archives, IRC channel logs, 
CVS access, and more, please visit:

http://peak.telecommunity.com/


From richard at commonground.com.au  Mon Feb 16 18:11:25 2004
From: richard at commonground.com.au (Richard Jones)
Date: Mon Feb 16 18:11:23 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <4030EB9B.1030300@zope.com>
References: <402F90E3.3040303@zope.com>	<402FBC31.6040108@weitershausen.de>	<20040216095705.GB10775@vet.uu.nl>	<4030B1C0.4060005@weitershausen.de>
	<4030B863.309@interlink.com.au> <4030EB9B.1030300@zope.com>
Message-ID: <713B58C7-60D5-11D8-88D8-000A95ABA188@commonground.com.au>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/02/2004, at 3:11 AM, Tres Seaver wrote:
> Anthony Baxter wrote:
>> Sorry, but this stuff is hard. The people who're trying to work on it 
>> have to do this in their spare time - for instance, the current pypi 
>> system.
>
> Note that PyPI invested effort to add Trove metadata, which I would 
> call "nice-to-have", and left out dependencies, which I would call 
> "crucial".  I am not trivializing the effort required to add 
> dependencies, either;  I just don't consider PyPI very useful without 
> them.

This is getting off-topic now, but I think it's important to reiterate 
Anthony's comment. Send Code. Distutils and PyPI are open to further 
development. Some people at some stage had some spare time to put in 
the effort to get something implemented. In my case, I knew I had to 
explicitly narrow the scope of PyPI or I'd never finish, and 
dependencies didn't make the cut. I always intended that they be added 
some time later. Possibly by myself, but most likely by someone else.

Distutils and PyPI are open code.

If you think PyPI's currently "pathetic" or not "very useful", then 
feel free to fix it when you have the spare time. Otherwise, stop the 
name-calling. It just makes those who have put in the effort feel like 
shit.

I'll note that PyPI is actually quite popular though. So I guess it's 
useful to some people.


      Richard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAMU4grGisBEHG6TARAummAJ0aQxwYv6S6oWcMolrkmd/mhmY2tACdEoaA
mQCxcJfOhJpxK07YFfTStIg=
=D9NK
-----END PGP SIGNATURE-----


From richard at commonground.com.au  Mon Feb 16 20:28:26 2004
From: richard at commonground.com.au (Richard Jones)
Date: Mon Feb 16 20:28:19 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <1076969103.23662.44.camel@localhost.localdomain>
References: <402D17B2.9040809@zope.com> <20040216094528.GA10775@vet.uu.nl>
	<4030EDE1.5070801@zope.com>
	<1076969103.23662.44.camel@localhost.localdomain>
Message-ID: <95B22C9C-60E8-11D8-88D8-000A95ABA188@commonground.com.au>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/02/2004, at 9:05 AM, Jeremy Hylton wrote:
> On Mon, 2004-02-16 at 11:20, Tres Seaver wrote:
>>    - Make it trivial to include "data" (e.g., page template files,
>>      images, ZCML, documentation) along with code (distutils is
>>      pathetic in its handling of "data");
>
> There's widespread agreement on this point.  I think it would be fairly
> straightforward to write a patch for distutils for 2.4 to make it 
> handle
> data usefully.

It has a data_files option (see section 3.5 of the distutils manual) 
which lists data files to install in subdirs of the install prefix. So 
in Roundup, I specify things like:

     ('share/roundup/cgi-bin', ['cgi-bin/roundup.cgi'])

and

     ('man/man1', ['doc/roundup-admin.1',
             'doc/roundup-mailgw.1', 'doc/roundup-server.1'])

Or were you thinking of something else?


      Richard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAMW46rGisBEHG6TARAo0HAJ9kF8UGNy/0zWaf2/GRpCC+bIfT+QCeLpKu
QkIAxdCNhU+M9oH9VEC47qo=
=hFCY
-----END PGP SIGNATURE-----


From garrett at mojave-corp.com  Mon Feb 16 20:37:21 2004
From: garrett at mojave-corp.com (Garrett Smith)
Date: Mon Feb 16 20:33:28 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <402F90E3.3040303@zope.com>
References: <402F90E3.3040303@zope.com>
Message-ID: <c0rr12$2qa$1@sea.gmane.org>

Jim Fulton wrote:
> I've collected some goals and other notes in the form of a preproposal
> on packaging:
> 
>   http://dev.zope.org/Zope3/Zope3PackagingProposal
> 
> Comments, here and in the wiki are appreciated.  I'd like to agree
> on goals that form a basis for additional work
> 
> Jim

Jim, how do you see this fitting into the 1.0 release of X3?

My general feedback is that this is a very ambitious vision. My vote 
would be to stay clear of anything fancy (i.e. mods to distutils, etc.) 
until we have seen X3 in the field and can solve some more concrete 
problems. For X3 1.0, I think we should create standard distributions 
(RPM, Debian, source/distutils, etc.) that are as simple as possible.

  -- Garrett



From garrett at mojave-corp.com  Mon Feb 16 21:10:37 2004
From: garrett at mojave-corp.com (Garrett Smith)
Date: Mon Feb 16 21:06:43 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <402FA0DB.1030406@zope.com>
References: <402FA0DB.1030406@zope.com>
Message-ID: <c0rsve$5jr$1@sea.gmane.org>

Summary: I really, really hope folder_browser doesn't win. :-)

More painful exposition follows...

Jim Fulton wrote:

> 
> I sent this earlier in response in another thread, but didn't
> get any response.  I'd be happy to assume no one disagrees
> and accept silence as assent, but, I thought this would be more
> controversal and a terser version got -1's before, so, here it is
> again.  :)
> 
> I think that continueing to separate presentations has a number
> of advantages:
> 
> - It *does* make iteasier for people who just want to modify
>   presentations to find them.

I'm not sure that looking for packages ending in "_browser" is any 
easier than looking for packages named "browser".

> - It makes it clearer that presentatations are pluggable and how

How? What is the recommended best practice for plugging new UI into:

   foo/bar/folder
   foo/bar/folder_browser

If I'm maintaining "foo/bar", I suppose I could add:

   foo/bar/folder_browser2

Of course, I could just as easily add:

   foo/bar/folder/browser2

If I'm not the maintainer of "foo/bar", I'd probably do something like this:

   mystuff/folder_browser

But I'd opt for:

   mystuff/folder/browser

or just

   mystuff/folder

if mystuff is strictly a pluggable UI.

> - It enforces the separation of presentation and application code

So does:

   folder/folder.py
   folder/browser.py

among lots of other configurations. Why is folder/folder_browser any better?

I know...shallower hierarchy. What stops us from flattening everything 
into underscored packages?

> - If we don't separate presentation into separate packages, some
>   will create presentation-specific subpackages anyway.

I don't follow this as an argument in favor of "folder_browser" over 
"folder.browser".

> The disadvantages of separate subpackages are:
> 
> - More packages, some of which are very small
> 
> - More navigation, but the navigation is simple under the new
>   shallow organization.  For example, if I'm in foo and I want
>   to get to the directory with the browser code, I only have to
>   cd to ../foo_browser, which isn't so bad.

Not to beat a dead horse, how is typing:

   cd ../foo_browser

faster than:

   cd ../foo/browser

> I think that the advantages of separating the presentation code far 
> outweigh
> the disadvantages.
> 
> Note that we won't separate interface code except in the case of 
> "framework"
> packages that define pluggable frameworks with interfaces where there
> are expected to be multiple implemantations.
> 
> So, I feel rather strongly that we should have packages like:
> 
> folder
> folder_browser
> file
> file_browser

-1 (if you hadn't guessed :-)

I'm certainly in favor of separating presentation from 
interface/implementation, but using the underscore pattern would be a 
very, very bad thing, IMO.

I'd like to see modular functionality (hand waving) organized as follows:

   modfoo
   --------------------
   modfoo/interfaces.py
   modfoo/modfoo.py or modfoo/_modfoo.py
   modfoo/__init__.py + imports of modfoo.py/_modfoo.py (optional)
   modfoo/browser.py or modfoo/browser/ depending on UI complexity
   modfoo/*.py (other implementation modules)

  -- Garrett



From jeremy at zope.com  Mon Feb 16 22:01:28 2004
From: jeremy at zope.com (Jeremy Hylton)
Date: Mon Feb 16 22:04:56 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <95B22C9C-60E8-11D8-88D8-000A95ABA188@commonground.com.au>
References: <402D17B2.9040809@zope.com> <20040216094528.GA10775@vet.uu.nl>
	<4030EDE1.5070801@zope.com>
	<1076969103.23662.44.camel@localhost.localdomain>
	<95B22C9C-60E8-11D8-88D8-000A95ABA188@commonground.com.au>
Message-ID: <1076986888.23662.56.camel@localhost.localdomain>

On Mon, 2004-02-16 at 20:28, Richard Jones wrote:
> It has a data_files option (see section 3.5 of the distutils manual) 
> which lists data files to install in subdirs of the install prefix. So 
> in Roundup, I specify things like:
> 
>      ('share/roundup/cgi-bin', ['cgi-bin/roundup.cgi'])
> 
> and
> 
>      ('man/man1', ['doc/roundup-admin.1',
>              'doc/roundup-mailgw.1', 'doc/roundup-server.1'])
> 
> Or were you thinking of something else?

I was thinking of something else.  Zope makes widespread use of data
files stored in Python packages.  It is probably the most convenient way
to associate a data file with code; you can access it by computing paths
relative to __file__ or __path__.  The recursive-include directive from
ZODB's MANIFEST.in should illustrate the point:
    recursive-include src *.h *.c *.xml *.txt *.sh *.conf *.bat

The first two are C extension source, of course.  The rest are various
kinds of data and scripts that are supposed to be installed with the
rest of the package in site-packages (or wherever else you choose to
install the code).  It takes at least 30 or 40 lines of code in a
setup.py to get those files installed where they belong.

The problem is easy to solve.  We just need some way to specify data
files that are associated with packages.  For Zope's use, I expect a
list of extensions that should be installed would suffice.

Jeremy



From pje at telecommunity.com  Mon Feb 16 22:29:51 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon Feb 16 22:27:32 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <95B22C9C-60E8-11D8-88D8-000A95ABA188@commonground.com.au>
References: <1076969103.23662.44.camel@localhost.localdomain>
	<402D17B2.9040809@zope.com> <20040216094528.GA10775@vet.uu.nl>
	<4030EDE1.5070801@zope.com>
	<1076969103.23662.44.camel@localhost.localdomain>
Message-ID: <5.1.0.14.0.20040216222127.0213acf0@mail.telecommunity.com>

At 12:28 PM 2/17/04 +1100, Richard Jones wrote:
>On 17/02/2004, at 9:05 AM, Jeremy Hylton wrote:
>>On Mon, 2004-02-16 at 11:20, Tres Seaver wrote:
>>>    - Make it trivial to include "data" (e.g., page template files,
>>>      images, ZCML, documentation) along with code (distutils is
>>>      pathetic in its handling of "data");
>>
>>There's widespread agreement on this point.  I think it would be fairly
>>straightforward to write a patch for distutils for 2.4 to make it handle
>>data usefully.
>
>It has a data_files option (see section 3.5 of the distutils manual) which 
>lists data files to install in subdirs of the install prefix. So in 
>Roundup, I specify things like:
>
>     ('share/roundup/cgi-bin', ['cgi-bin/roundup.cgi'])
>
>and
>
>     ('man/man1', ['doc/roundup-admin.1',
>             'doc/roundup-mailgw.1', 'doc/roundup-server.1'])
>
>Or were you thinking of something else?

Data files that need to be installed *in* the package directory, ala 
ZConfig 'component.xml' files.

Personally, I use the following subclass of install_data:


class install_data(install_data):

     """Variant of 'install_data' that installs data to module directories"""

     def finalize_options (self):
         self.set_undefined_options('install',
                                    ('install_lib', 'install_dir'),
                                    ('root', 'root'),
                                    ('force', 'force'),
                                   )


This causes the data files to be installed relative to site_packages, which 
is a bit easier to manage.  There is no way that I know of to use an 
unmodified distutils and still specify platform-independent paths to data 
files for installation.

There probably needs to be a different way to address this than the one I'm 
using, though, because changing install_data to do what I do would clearly 
break yours and other people's code who are using install_data to install 
non-package files.

One possible way to address it would be a function that would generate the 
data that the current install_data command expects, but in a way that's 
sensitive to the directory layout of the platform.  Or, maybe install_data 
could handle interpolation in the target paths, e.g.:

('$LIBDIR/some/package', ['src/some/package/somedata.xml'])

or the more Pythonic:

('%(LIBDIR)s/some/package', ['src/some/package/somedata.xml'])


From LBerezhny at DevIS.com  Mon Feb 16 23:27:16 2004
From: LBerezhny at DevIS.com (Lex Berezhny)
Date: Mon Feb 16 23:27:24 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <4030B5FE.8010306@weitershausen.de>
References: <402FA0DB.1030406@zope.com> <402FC5A0.5020701@weitershausen.de>
	<402FF972.6080605@weitershausen.de> <40309DBB.6090605@zope.com>
	<4030B5FE.8010306@weitershausen.de>
Message-ID: <1076992035.4099.56.camel@localhost.localdomain>

On Mon, 2004-02-16 at 06:22, Philipp von Weitershausen wrote:
> You can't separate and keep stuff together at the same time. What do we 
> weigh more important? Do we want to
> 
> - emphasize separation OR make navigation easier?

+1 navigation

> - allow easy customization OR have compact structures?

+1 compact structure

> - have a scrutable hierarchy (IOW, flat but meaningful) OR minimize 
> distance?

+1 minimize distance


  Someone pointed this out earlier, but it's important to consider that
most projects are not going to have multiple UIs. Maybe a lot will, but
most won't.

  I think the hierarchy should be left the way it is:

On Mon, 2004-02-16 at 20:10, Garrett Smith wrote:
>    modfoo
>    --------------------
>    modfoo/interfaces.py
>    modfoo/modfoo.py or modfoo/_modfoo.py
>    modfoo/__init__.py + imports of modfoo.py/_modfoo.py (optional)
>    modfoo/browser.py or modfoo/browser/ depending on UI complexity
>    modfoo/*.py (other implementation modules)


  This way most projects can have a succinct layout. Once the majority
is satisfied a more elaborate system/scheme can be devised to meet the
needs of those projects that need some framework to manage the multiple
UIs.

  I am going on a limb here, but my impression is that Zope3 is more of
an application server than (Zope2) a content management system. As an
application server I think most people will be building apps that have
only one skin.

  At least that has been my experience with Zope2 business applications
vs. Zope2 content applications. Most custom business apps (budgeting,
project management, process management, employee/people/customer
management) only have one skin which comes as part of building the
custom app.

  We have only one application at work (ezro.devis.com - in the process
of being released as Open Source once the Dept. of Labor approves it)
which uses many skins (i think we have about a dozen or more right now).
The rest of our applications only have one skin.

  I guess the point I want to make is that from my experience you
usually either have one skin and that's it or you have a dozen skins or
more which would benefit from some skin management framework anyways.

thanks for listening,

 lex


From request at global-submit.com  Tue Feb 17 01:09:40 2004
From: request at global-submit.com (request@global-submit.com)
Date: Tue Feb 17 01:09:45 2004
Subject: [Zope3-dev] Regarding: mail.zope.org/pipermail/zope3-dev/
Message-ID: <200402170609.BAA24499@sg5.global-submit.com>

Hello,

This e-mail has been sent to inform you that your 
web site URL has been submitted to our search engine
database. This is the URL that will be added.

    URL : mail.zope.org/pipermail/zope3-dev/
   DATE : 02/17/2004 1:9:40
IP ADDR : Unknown IP. User had used an automated software for url submission

In order to complete this request we require that you 
click on the web site link below. This will confirm
that you do wish to be added to our search engine.

http://www.global-submit.com/confirm.cgi?T887458R569975

If you feel that you received this message in error
or you did not have your web site submitted to our
search engine, please click on the link below. We 
will make every effort to make sure that you are 
no longer bothered by this automated system. 

http://www.global-submit.com/clipout.cgi?T887458R569975

Thank you and please have a nice day

Global-Submit.com tech Staff
www.global-submit.com
1 819 571 4943






From dev at projekt01.ch  Tue Feb 17 04:13:00 2004
From: dev at projekt01.ch (Roger ineichen)
Date: Tue Feb 17 04:14:28 2004
Subject: AW: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <c0rsve$5jr$1@sea.gmane.org>
Message-ID: <000701c3f536$3ebf4f30$1e63a8c0@projekt01.local>

Garret wrote:
> I'd like to see modular functionality (hand waving) organized 
> as follows:
> 
>    modfoo
>    --------------------
>    modfoo/interfaces.py
I agree, it's clear what's inside the file

>    modfoo/modfoo.py or modfoo/_modfoo.py
I agree, give meaningful filenames inside a packeage and
     the "_" can be used for to show that from this file
     should not import directly.

>    modfoo/__init__.py + imports of modfoo.py/_modfoo.py (optional)
I agree, support a clear api and give us meaningful and short imports

>    modfoo/browser.py or modfoo/browser/ depending on UI complexity
I agree, separates UI stuff and can be used for modfoo/otherprotocol
I think browser is OK for the http protocol.

>    modfoo/*.py (other implementation modules)

I agree, this is what we used to do in the last couple month in zope3
and that was not bad to me.

I have nothing against other ideas, its just important to use a clear
concept which is easy to communicate to other people. 

For me is more important to fix a concept who all can live with and
and make shure everybody is working with. This give use more clear
structure and it's easier to browse the code. 
 

>   -- Garrett
> 

Regards 
Roger Ineichen

> 
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org http://mail.zope.org/mailman/listinfo/zope3-dev
> 


From jim at zope.com  Tue Feb 17 04:34:35 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 17 04:35:16 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <4030B463.90806@weitershausen.de>
References: <402FA0DB.1030406@zope.com> <402FC5A0.5020701@weitershausen.de>
	<40309B19.4040000@zope.com> <4030B463.90806@weitershausen.de>
Message-ID: <4031E02B.3060703@zope.com>

Philipp von Weitershausen wrote:
> Jim Fulton wrote:
> 
>> I said a disadvantage was:
>>
>>>> - More navigation, but the navigation is simple under the new
>>>>   shallow organization.  For example, if I'm in foo and I want
>>>>   to get to the directory with the browser code, I only have to
>>>>   cd to ../foo_browser, which isn't so bad.
>>
>>
>> and you agreed:
>>
>>> We need to reduce navigation, for the reason I've stated above: not 
>>> to confuse and scare away people that are not familiar with that scheme.
> 
> 
> Yes. All I'm saying is that we need to make it extemely easy to 
> understand and even easier to grok the package hierarchy.

Yes, but I think it's even more important to make it easier to use.
Most people can figure out the current scheme, but it's still very painful.
You end up looking in three places for things, or, at least having
to work in three places.

These is especially painful for people who don't use emacs. :)
I just spent a week with a room full of vi users doing Zope 3
coding.  They spend way too much time cd-ing,


...


>> But this moves things far apart.  Now the packages relared to foo
>> are in different trees.
> 
> 
> I realize that it is less convenient for immediatedly practical 
> navigation. It think it'll be easier to understand, though.

It's not just navigation. It's also visual searching and context
switching.  I didn't realize how much this bugged me until we
began talking about getting rid of it. :)


>> I think foo-related-ness is at least as important
>> as browser relatedness.
> 
> 
> Too bad their two different kinds of relatednesses. We would really need 
> three-dimensional directory trees.

:) This is an inherient limitation of hierarchies.

Perhaps this is why Guido likes to limit use of hierarchies.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Tue Feb 17 04:42:45 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 17 04:43:22 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <4030B5FE.8010306@weitershausen.de>
References: <402FA0DB.1030406@zope.com>	<402FC5A0.5020701@weitershausen.de>	<402FF972.6080605@weitershausen.de>	<40309DBB.6090605@zope.com>
	<4030B5FE.8010306@weitershausen.de>
Message-ID: <4031E215.3080703@zope.com>

Philipp von Weitershausen wrote:
> Jim Fulton wrote:
> 
>>> I really like this one. And it'll make packaging easy, too. Don't 
>>> want the Zope application server? Don't install zopeapp! Don't want 
>>> browser code? Don't install zopebrowser!
>>
>>
>> It doesn't make packaging any easier, IMO.  You still have container 
>> packages that you need to install things into.
> 
> 
> Why is that a problem?

Maybe I should have asked you why you thought your ideas might make
packaging easier. :)

The problem is that, AFAIK, distutils doesn;t support installing
subpackages.

>>> Using several top-level packages has the following advantages:
>>
>>
>> But that moves things that are closely related (application code for
>> some topic and the presentation code for some topic) far apart.
> 
> 
>  From a physical point of view, yes. From a hierarchy point of view, no.

No, they are far apart in the hierarchy too.

...

>> *everything* is separated over multiple trees. This is what we have now
>> and I think most people hate it.
> 
> 
> You can't separate and keep stuff together at the same time. What do we 
> weigh more important? Do we want to
> 
> - emphasize separation OR make navigation easier?

I want both.  Hierarchies are too inflexible.

> - allow easy customization OR have compact structures?

I want both.  Hierarchies are too inflexible. :)

> - have a scrutable hierarchy (IOW, flat but meaningful) OR minimize 
> distance?

Minimize distance.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Tue Feb 17 04:46:04 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 17 04:46:44 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <4030B799.2050109@weitershausen.de>
References: <402FA0DB.1030406@zope.com> <20040216095927.GC10775@vet.uu.nl>
	<40309E4E.2040002@zope.com> <4030B799.2050109@weitershausen.de>
Message-ID: <4031E2DC.4080102@zope.com>

Philipp von Weitershausen wrote:
> Jim Fulton wrote:
> 

...

>> True, but then too much hierarchy is considered unpythonic. <shrug>
> 
> 
> I consider too much hierarchy very Prussian :). IOW I don't think it's 
> pythonic nor unpythonic. It's a pattern you choose or not.

Perhaps I should have said unGuidonic, but, I'd say that Guidocity
and Pythonicity are closely related. ;)

Guido hates deep hierarchies.  I wouldn't normally go as far as he would,
but I find that the experince with coming up with a package structure
for Zope 3 tends to support his point of view.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Tue Feb 17 04:51:13 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 17 04:51:56 2004
Subject: [Zope3-dev] Separate presentation packages
In-Reply-To: <200402161321.52738.srichter@cosmos.phy.tufts.edu>
References: <402FA0DB.1030406@zope.com>
	<40309E4E.2040002@zope.com>	<40310768.4060809@infrae.com>
	<200402161321.52738.srichter@cosmos.phy.tufts.edu>
Message-ID: <4031E411.9010401@zope.com>

Stephan Richter wrote:
> On Monday 16 February 2004 13:09, Martijn Faassen wrote:
> 
>>Besides it being two packages, it also means you need to adjust your
>>ZCML twice to include both browser as well as content package.
>>
>>Then again, it becomes easier in ZCML to selectively disable a view
>>package. Again though this is not the common case..
>>
>>So by splitting it into two packages we're making the common case
>>harder. Besides the namespace changes (especially invented for Zope,
>>nobody else uses this, not Pythonic, etc), we're also making the common
>>case more difficult.
> 
> 
> I think Martijn has a good point here. We are thinking so hard about the 5-10% 
> of the time you have the uncommon case, that we forget about what people will 
> usually want to do. And I bet now that it will not be common to replace the 
> UI. It is just too much work to do it consistently.

I don't agree. This was huge complaint about Z2.  It was a motivation
for CMF skins.  People don't necessarily create multiple presentations
for applications, but they often want to replace the presentation of
products they get to make them consistent with their application
presentations.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From faassen at infrae.com  Tue Feb 17 04:59:16 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Tue Feb 17 04:59:21 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <713B58C7-60D5-11D8-88D8-000A95ABA188@commonground.com.au>
References: <402F90E3.3040303@zope.com>	<402FBC31.6040108@weitershausen.de>	<20040216095705.GB10775@vet.uu.nl>	<4030B1C0.4060005@weitershausen.de>	<4030B863.309@interlink.com.au>
	<4030EB9B.1030300@zope.com>
	<713B58C7-60D5-11D8-88D8-000A95ABA188@commonground.com.au>
Message-ID: <4031E5F4.9040408@infrae.com>

Richard Jones wrote:

> This is getting off-topic now, but I think it's important to reiterate 
> Anthony's comment. Send Code. Distutils and PyPI are open to further 
> development. Some people at some stage had some spare time to put in 
> the effort to get something implemented. In my case, I knew I had to 
> explicitly narrow the scope of PyPI or I'd never finish, and 
> dependencies didn't make the cut.

To make things absolutely clear: my intent with the original mail 
describing it is taking a while for Python to come up with a CPAN 
equivalent was not to indicate that this is pathetic but that it's a 
hard nut to crack. Not so much technologically but organisationally for 
two reasons:

  * it's hard to make people adopt any solution.

  * it's not a high priority for most people, so harder to find volunteers.

And again, the action that was taken was step-by-step, over the years, 
and I suggested some follow-on steps.

I still think they stand:

  * enable configuration information besides Python code in setup.py, so 
that it becomes declarative. As described by Jeremy Hylton, distutils 
doesn't enforce this information to be in Python.

  * work out a system for dependency tracking.

I think Tres makes good points about distutils having some missing 
abilities which are necessary when distributing applications. Adding 
these could be another step.

I would encourage us to build this on top of distutils if at all 
possible, as doing it completely by ourselves will either result in 6 
more years, or only us using it, or nothing ever happening. None of 
these is desirable.

Regards,

Martijn


From jim at zope.com  Tue Feb 17 05:08:32 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 17 05:09:16 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <1076969043.23662.42.camel@localhost.localdomain>
References: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>	<200402131703.07139.fred@zope.com>
	<402D4DAF.10502@zope.com>	<200402131816.59402.fred@zope.com>
	<1076969043.23662.42.camel@localhost.localdomain>
Message-ID: <4031E820.9000302@zope.com>

Jeremy Hylton wrote:
> On Fri, 2004-02-13 at 18:16, Fred Drake wrote:
> 
>>Dependency information is just one portion of a package's metadata.  It 
>>should be included along with the other metadata related to the package 
>>itself.  I'd be happy for it to live in the same place as the other package 
>>metadata if we can get that to be in the right place: the package itself.
>>
>>Using setup.py as a container for the package metadata has not worked well 
>>as all, given how many setup.py scripts we maintain.
> 
> 
> I haven't noticed any problems using ZODB3's setup.py to hold metadata. 
> Did you have specific issues in mind?  Perhaps the metadata that is
> currently in setup.py isn't that interesting -- a URL, email address,
> description, and version number.

Somehow, Z3's setup.py is evidence of problems with distutils.
I wish we had separate setup.py scripts for the separate major
components of Zope 3, but somehow, this has been too hard. Instead,
we have this rather complicated monolithic setup.py. Worse, we have
three big monolithic setup.py scripts, for Zope 2, for Zope 3, and for
ZODB that duplicate a good bit of code.

We should have separate setup.py scripts and a controller script that
invokes the separate scripts.  It should, IMO, be possible for the central
script to invoke the others as modules.  This doesn't seem to be possible,
given the way things setup.py scripts are typically written.  It wouldn't
be that big a deal to devise a different *style* of writing setup scripts
so that they could be used by other setup scripts.


> Several people have griped about having to put metadata in a Python
> script.  I think they confusing policy and mechanism.  If a distutils
> command needs metadata to operate, it must be passed to the setup()
> call.  There's no requirement that the data passed to it be stored in a
> script called setup.py or in any Python script.  You could put the
> metadata in a file and write a helper routine that loads metadata to be
> passed to setup.  (I'm not sure what the file format would be.  If I
> have to write it by hand and my choices are Python and XML, I'll stick
> with Python.)

A major problem I have with distutils is that I have to write rather
complex scripts to do somewhat simple things.  I don't
necessarily have a problem with capturing this meta data in Python.

A major problem with the way meta data are captured in setup.py
scripts now, is that the data are expressed as keyword argumments.
As a result, they aren;t accessable.  As mentioned above, some different
conventions for writing setup scripts could go a long way.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Tue Feb 17 05:12:50 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 17 05:13:28 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <c0rr12$2qa$1@sea.gmane.org>
References: <402F90E3.3040303@zope.com> <c0rr12$2qa$1@sea.gmane.org>
Message-ID: <4031E922.9060706@zope.com>

Garrett Smith wrote:
> Jim Fulton wrote:
> 
>> I've collected some goals and other notes in the form of a preproposal
>> on packaging:
>>
>>   http://dev.zope.org/Zope3/Zope3PackagingProposal
>>
>> Comments, here and in the wiki are appreciated.  I'd like to agree
>> on goals that form a basis for additional work
>>
>> Jim
> 
> 
> Jim, how do you see this fitting into the 1.0 release of X3?

I don't know yet.  We are still talking about what "this" is. :)

> My general feedback is that this is a very ambitious vision. My vote 
> would be to stay clear of anything fancy (i.e. mods to distutils, etc.) 
> until we have seen X3 in the field and can solve some more concrete 
> problems. For X3 1.0, I think we should create standard distributions 
> (RPM, Debian, source/distutils, etc.) that are as simple as possible.

I assume we can do an X3.0 release without solving the packaging problem,
but I think we want this sooner rather than later.  My motivation for wanting
to talk about this now is, in part that software layout debate. In particular,
I don't want to use the CVS repository layout as my packaging tool.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From faassen at infrae.com  Tue Feb 17 05:18:25 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Tue Feb 17 05:18:29 2004
Subject: [Zope3-dev] Separate presentation packages
In-Reply-To: <4031E411.9010401@zope.com>
References: <402FA0DB.1030406@zope.com>	<40309E4E.2040002@zope.com>	<40310768.4060809@infrae.com>	<200402161321.52738.srichter@cosmos.phy.tufts.edu>
	<4031E411.9010401@zope.com>
Message-ID: <4031EA71.1040208@infrae.com>

Jim Fulton wrote:

> Stephan Richter wrote:
>
>> I think Martijn has a good point here. We are thinking so hard about 
>> the 5-10% of the time you have the uncommon case, that we forget 
>> about what people will usually want to do. And I bet now that it will 
>> not be common to replace the UI. It is just too much work to do it 
>> consistently.
>
>
> I don't agree. This was huge complaint about Z2.  It was a motivation
> for CMF skins.  People don't necessarily create multiple presentations
> for applications, but they often want to replace the presentation of
> products they get to make them consistent with their application
> presentations.


It is still not the common case. While people indeed want the ability to 
override presentation, *most the time* this doesn't happen, because it's 
too much work and isn't necessary. The point is not whether people want 
to do it, but whether people will do it for most packages, and whether a 
browser_foo setup will support/encourage any of this better than the 
alternatives, and whether going that way won't make some other things 
harder.

I think we all agree that we shouldn't separate views from presentation 
too distantly; we've learned our lesson there. We also noticed nobody 
was exploiting our separation. So now while we're going to put them 
together we're still hoping some unconventional structure will magically 
be more supportive of this than the alternative, which is simply putting 
them in the same package. The only way we're going to encourage people 
to split separation from content is by making that very easy to do. I 
thought we've figured that pacakage-structural encouragement was only of 
minimal use.

Regards,

Martijn


From jim at zope.com  Tue Feb 17 05:28:31 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 17 05:29:09 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <c0rsve$5jr$1@sea.gmane.org>
References: <402FA0DB.1030406@zope.com> <c0rsve$5jr$1@sea.gmane.org>
Message-ID: <4031ECCF.1020104@zope.com>

Garrett Smith wrote:

...

> I'm not sure that looking for packages ending in "_browser" is any 
> easier than looking for packages named "browser".

I am.  I can look at a single directory listing and immediately
see all of the presentation packages.  To find subpackages named
browser, I need to use find. But maybe subpackages aren't used,
maybe there are browser.py modules.

>> - It makes it clearer that presentatations are pluggable and how
> 
> 
> How? What is the recommended best practice for plugging new UI into:
> 
>   foo/bar/folder
>   foo/bar/folder_browser

foo/bar is a bit too abstract.

> If I'm maintaining "foo/bar", I suppose I could add:
> 
>   foo/bar/folder_browser2

I think it would be unlikely for the maintainer of
zope.app.folder and zope.app.folder_browser to create a second
browser UI.  A third-party developer will likely create an
alternative presentation somehere else, like zc.folder_browser.
They could start by just copying zope.app.folder_browser.

>> - It enforces the separation of presentation and application code
> 
> 
> So does:
> 
>   folder/folder.py
>   folder/browser.py
> 
> among lots of other configurations. Why is folder/folder_browser any 
> better?

Because it is a separate package, with it's own configuration file.

> I know...shallower hierarchy. What stops us from flattening everything 
> into underscored packages?

Nothing. :)

>> - If we don't separate presentation into separate packages, some
>>   will create presentation-specific subpackages anyway.
> 
> 
> I don't follow this as an argument in favor of "folder_browser" over 
> "folder.browser".

It's not. But a disadvantage of folder_browser is that it will often cause
us to create extra packages. My point was that we'd often create extra
packages anyway.


>> The disadvantages of separate subpackages are:
>>
>> - More packages, some of which are very small
>>
>> - More navigation, but the navigation is simple under the new
>>   shallow organization.  For example, if I'm in foo and I want
>>   to get to the directory with the browser code, I only have to
>>   cd to ../foo_browser, which isn't so bad.
> 
> 
> Not to beat a dead horse, how is typing:
> 
>   cd ../foo_browser
> 
> faster than:
> 
>   cd ../foo/browser

If you are already in foo, you wouldn't type cd ../foo/browser,
you'd type cd browser. but If there wasn't a separate browser package,
then you wouldn't have to cd at all.

...

> I'm certainly in favor of separating presentation from 
> interface/implementation, but using the underscore pattern would be a 
> very, very bad thing, IMO.
> 
> I'd like to see modular functionality (hand waving) organized as follows:
> 
>   modfoo
>   --------------------
>   modfoo/interfaces.py
>   modfoo/modfoo.py or modfoo/_modfoo.py
>   modfoo/__init__.py + imports of modfoo.py/_modfoo.py (optional)

yes

>   modfoo/browser.py or modfoo/browser/ depending on UI complexity
>   modfoo/*.py (other implementation modules)

plus:

    modfoo/*.pt (template modules)
    modfoo/*.jpg (images)
    configure.zcml

And I think that this provides less separation than we should have.

People who *just* want to focus on presentation need to sort it
out from the other code.  People who just want the application code
have all this extra browser code.
Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Tue Feb 17 05:32:04 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 17 05:32:41 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <1076992035.4099.56.camel@localhost.localdomain>
References: <402FA0DB.1030406@zope.com>
	<402FC5A0.5020701@weitershausen.de>	<402FF972.6080605@weitershausen.de>
	<40309DBB.6090605@zope.com>	<4030B5FE.8010306@weitershausen.de>
	<1076992035.4099.56.camel@localhost.localdomain>
Message-ID: <4031EDA4.2080707@zope.com>

Lex Berezhny wrote:
> On Mon, 2004-02-16 at 06:22, Philipp von Weitershausen wrote:
> 
...


>   Someone pointed this out earlier, but it's important to consider that
> most projects are not going to have multiple UIs. Maybe a lot will, but
> most won't.

I don't think most applications will have multple UIs. But,
when you get a product from someone else, you are often going to
want to change it's UI to make it consistent with the app you are
plugging it into.

>   I think the hierarchy should be left the way it is:

The way it is today?  Have you actually worked with it?

...

>   I am going on a limb here, but my impression is that Zope3 is more of
> an application server than (Zope2) a content management system. As an
> application server I think most people will be building apps that have
> only one skin.
> 
>   At least that has been my experience with Zope2 business applications
> vs. Zope2 content applications. Most custom business apps (budgeting,
> project management, process management, employee/people/customer
> management) only have one skin which comes as part of building the
> custom app.
> 
>   We have only one application at work (ezro.devis.com - in the process
> of being released as Open Source once the Dept. of Labor approves it)
> which uses many skins (i think we have about a dozen or more right now).
> The rest of our applications only have one skin.
> 
>   I guess the point I want to make is that from my experience you
> usually either have one skin and that's it or you have a dozen skins or
> more which would benefit from some skin management framework anyways.

But, as I said above, you will often want to reuse someone
elses product and you will need to make the product's UI consistent
with you app's UI.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Tue Feb 17 05:35:07 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 17 05:35:28 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <4031E5F4.9040408@infrae.com>
References: <402F90E3.3040303@zope.com>	<402FBC31.6040108@weitershausen.de>	<20040216095705.GB10775@vet.uu.nl>	<4030B1C0.4060005@weitershausen.de>	<4030B863.309@interlink.com.au>	<4030EB9B.1030300@zope.com>	<713B58C7-60D5-11D8-88D8-000A95ABA188@commonground.com.au>
	<4031E5F4.9040408@infrae.com>
Message-ID: <4031EE5B.8070604@zope.com>

Martijn Faassen wrote:
> Richard Jones wrote:
> 
...

> I would encourage us to build this on top of distutils if at all 
> possible, as doing it completely by ourselves will either result in 6 
> more years, or only us using it, or nothing ever happening. None of 
> these is desirable.

Yup.

And worse, coming up with out own system would make it harder to use
Zope software outside of Zope and harder to to use non-Zope software
in Zope.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Tue Feb 17 05:50:54 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 17 05:51:35 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <713B58C7-60D5-11D8-88D8-000A95ABA188@commonground.com.au>
References: <402F90E3.3040303@zope.com>	<402FBC31.6040108@weitershausen.de>	<20040216095705.GB10775@vet.uu.nl>	<4030B1C0.4060005@weitershausen.de>	<4030B863.309@interlink.com.au>
	<4030EB9B.1030300@zope.com>
	<713B58C7-60D5-11D8-88D8-000A95ABA188@commonground.com.au>
Message-ID: <4031F20E.3040700@zope.com>

Richard Jones wrote:

...

> This is getting off-topic now,

Not exactly.  A major aspect of this discussion has been whether
we (the Zope community) have the luxury of taking the time to improve
distutils.

 > but I think it's important to reiterate
> Anthony's comment. Send Code.

Of course.

I don't think that anyone meant to disparage the people who have
already sent code.  It certainly *is* pathetic that we are
so far behind perl in this area. I see nothing wrong with admitting
that.  Similarly, if we are going to make distutils better, we have
to first analyze its weaknesses.  Clearly people have put a lot of
effort into distutils and other packaging related systems. They are
part of the solution, not part of the problem. They should feel
great about their contributions.

(Having said all of that, I also appreciate how frustrating it can
  be to bust your ass working on something and get a lot of criticism
  for it.  In that respect, open source can really suck.)

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From faassen at infrae.com  Tue Feb 17 06:11:12 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Tue Feb 17 06:10:02 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <4031E922.9060706@zope.com>
References: <402F90E3.3040303@zope.com> <c0rr12$2qa$1@sea.gmane.org>
	<4031E922.9060706@zope.com>
Message-ID: <4031F6D0.60303@infrae.com>

Jim Fulton wrote:

> I assume we can do an X3.0 release without solving the packaging 
> problem, but I think we want this sooner rather than later.  My 
> motivation for wanting to talk about this now is, in part that 
> software layout debate. In particular, I don't want to use the CVS 
> repository layout as my packaging tool.


This is an important point: The CVS repository layout *is* the packaging 
system *for developers*.

So please realize that making foo_browser a standard means that if I'm 
an independent product developer, in my own repository away from Zope 3, 
I need to check out *two* modules to work on my package; foo and 
foo_browser. This will make tagging and branching a lot harder.

Regards,

Martijn


From philipp at weitershausen.de  Tue Feb 17 06:25:38 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Tue Feb 17 06:18:59 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <4031F6D0.60303@infrae.com>
References: <402F90E3.3040303@zope.com>
	<c0rr12$2qa$1@sea.gmane.org>	<4031E922.9060706@zope.com>
	<4031F6D0.60303@infrae.com>
Message-ID: <4031FA32.9060301@weitershausen.de>

Martijn Faassen wrote:
> Jim Fulton wrote:
> 
>> I assume we can do an X3.0 release without solving the packaging 
>> problem, but I think we want this sooner rather than later.  My 
>> motivation for wanting to talk about this now is, in part that 
>> software layout debate. In particular, I don't want to use the CVS 
>> repository layout as my packaging tool.
> 
> This is an important point: The CVS repository layout *is* the packaging 
> system *for developers*.

For developers of Zope3, not necessarily for 3rd party developers.

> So please realize that making foo_browser a standard means that if I'm 
> an independent product developer, in my own repository away from Zope 3, 
> I need to check out *two* modules to work on my package;

Or apt-get install it... After all, you're not developing those modules 
themselves but developing *with* them, right?

> This will make tagging and branching a lot harder.

I don't see why you would want to tag/branch Zope3 sources when not 
developing Zope3 itself but your own repository stuff.

Philipp


P.S.: Though I don't really understand what you're saying, I *do* know 
that it wouldn't be easier right now :)


From srichter at cosmos.phy.tufts.edu  Tue Feb 17 06:46:27 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Tue Feb 17 06:46:54 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <4031E215.3080703@zope.com>
References: <402FA0DB.1030406@zope.com> <4030B5FE.8010306@weitershausen.de>
	<4031E215.3080703@zope.com>
Message-ID: <200402170646.28203.srichter@cosmos.phy.tufts.edu>

On Tuesday 17 February 2004 04:42, Jim Fulton wrote:
> > Why is that a problem?
>
> Maybe I should have asked you why you thought your ideas might make
> packaging easier. :)
>
> The problem is that, AFAIK, distutils doesn;t support installing
> subpackages.

I think we should not worry about distutils limitations at this point.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From srichter at cosmos.phy.tufts.edu  Tue Feb 17 07:09:46 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Tue Feb 17 07:10:14 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <4031F6D0.60303@infrae.com>
References: <402F90E3.3040303@zope.com> <4031E922.9060706@zope.com>
	<4031F6D0.60303@infrae.com>
Message-ID: <200402170709.46424.srichter@cosmos.phy.tufts.edu>

HI,

I am not quoting anyone here, because I want to take the discussion one step 
back.

The reason we suggested folder and folder_web in the first place was to make 
it easier to develop new UIs. And this in turn was born from the problem that 
it was not easy for us to deactivate the browser ZCML in a package. 
Therefore, I would really like to go back to

folder
folder/browser
...

and provide a ZCML way of saying

<disable>
  <include package="folder.browser" />
</disable>

This way, if you you develop a new UI you can just declare

<disable>
  <include package="folder.browser" />
</disable>
<include package="srichter.folder.browser" />

In my opinion this is much more sane than anything that we have discussed 
concerning this branch of the debate.

The rest of the packaging ideas, like factoring out components from zope.app 
and creating smaller confined packages with good dependency information and 
so on I really like.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From srichter at cosmos.phy.tufts.edu  Tue Feb 17 07:23:38 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Tue Feb 17 07:24:04 2004
Subject: [Zope3-dev] Separate presentation packages
In-Reply-To: <4031E411.9010401@zope.com>
References: <402FA0DB.1030406@zope.com>
	<200402161321.52738.srichter@cosmos.phy.tufts.edu>
	<4031E411.9010401@zope.com>
Message-ID: <200402170723.38414.srichter@cosmos.phy.tufts.edu>

On Tuesday 17 February 2004 04:51, Jim Fulton wrote:
> > I think Martijn has a good point here. We are thinking so hard about the
> > 5-10% of the time you have the uncommon case, that we forget about what
> > people will usually want to do. And I bet now that it will not be common
> > to replace the UI. It is just too much work to do it consistently.
>
> I don't agree. This was huge complaint about Z2. ?It was a motivation
> for CMF skins. ?People don't necessarily create multiple presentations
> for applications, but they often want to replace the presentation of
> products they get to make them consistent with their application
> presentations.

Well, people want to replace bits and pieces. That's fine, but people will not 
develop entire UIs. So instead of aiming at people that replace entire UIs, 
we should aim at people that change bits and pieces for which I think that 
the  solution in my previous is much more workable and sensible.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From Mailer-Daemon at python.org  Tue Feb 17 07:50:10 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Tue Feb 17 07:50:12 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1At4fy-0006nA-Uy@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1At4fA-0006lv-BY; Tue, 17 Feb 2004 07:49:20 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [BasicUnitTests] (new) first draft (generated from LaTeX file)
Message-ID: <20040217074920EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/BasicUnitTests/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/BasicUnitTests/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/BasicUnitTests>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Tue, 17 Feb 2004 07:49:20 -0500
X-Spam-Status: OK (default 0.000)

Writing Basic Unit Tests

  Status

    IsDraft

  Authors

    StephanRichter

  Difficulty

    Newcomer Level  

  Skills

    - All you need to know is some Python.  


  Problem/Task

    As you know by now, Zope 3 gains its incredible stability from
    testing any code in great detail. The currently most common method is to
    write unit tests. This chapter introduces unit tests - which are Zope 3
    independent - and introduces some of the subtleties.  


  Recipe

    
  Implementing the Sample Class


    Before we can write tests, we have to have something to test. Here,
    we will implement a simple class called 'Sample' with a public
    attribute 'title' and description that is accessed via 'getDescription()' 
    and mutated using 'setDescription()' . Further, the description must
    be either a regular or a unicode string.

    Since this code will not depend on Zope, open a file named 'test' 
    anywhere and add the following class::

      01 Sample(object):
      02     """A trivial Sample object."""
      04     title = None
      06     def __init__(self):
      07         """Initialize object."""
      08         self._description = ''
      10     def setDescription(self, value):
      11         """Change the value of the description."""
      12         assert isinstance(value, (str, unicode)) 
      13         self._description = value
      15     def getDescription(self):
      16         """Change the value of the description."""
      17         return self._description

    o Line 4: The 'title' is just publicly declared and a value of 'None' 
      is given. Therefore this is just a regular attribute.

    o Line 8: The actual description string will be stored in '_' .

    o Line 12: Make sure that the description is only a regular or
      unicode string, like it was stated in the requirements.  


    If you wish you can now manually test the class with the interactive
    Python shell. Just start Python by entering 'python' in you shell
    prompt. Note that you should be in the directory in which 'test' is
    located when starting Python (an alternative is of course to specify the
    directory in your 'PYTHONPATH' .)::

      01 >>> from test_sample import Sample
      02 >>> sample = Sample()
      03 >>> print sample.title
      04 None
      05 >>> sample.title = 'Title'
      06 >>> print sample.title
      07 Title
      08 >>> print sample.getDescription()
      10 >>> sample.setDescription('Hello World')
      11 >>> print sample.getDescription()
      12 Hello World
      13 >>> sample.setDescription(None)
      14 Traceback (most recent call last):
      15   File "<stdin>", line 1, in ?
      16   File "test_sample.py", line 31, in setDescription
      17     assert isinstance(value, (str, unicode)) 
      18 AssertionError

    As you can see in the last test, non-string object types are not
    allowed as descriptions and an 'AssertionError' is raised.

    
  Writing the Unit Tests


    The goal of writing the unit tests is to convert the informal,
    manual, and interactive tests into a formal test class. Python provides
    already a module called 'unittest' which is a port of the Java-based
    unit testing product, JUnit, by Kent Beck and Erich Gamma. There are
    three levels to the testing framework (these derivate a bit from the
    original definitions as found in the Python library documentation. 'http://www.python.org/doc/current/lib/module-unittest.html' 
).

    The smallest unit is obviously the "test", which is a single method
    in a 'TestCase' class that tests the behavior of a small piece of
    code or a particular aspect of an implementation. The "test case" is then
    a collection tests that share the same setup/inputs. On top of all of
    this sits the "test suite" which is a collection of test cases and/or
    other test suites. Test suites combine tests that should be executed
    together. With the correct setup (as shown in the example below), you can
    then execute test suites. For large projects like Zope 3, it is useful to
    know that there is also the concept of a test runner, which manages the
    test run of all or a set of tests. The runner provides useful feedback to
    the application, so that various user interaces can be developed for it.

    But enough about the theory. In th following example, which you can
    simply put into the same file as your code above, you will see a test in
    common Zope 3 style.::

      01 import unittest
      03 class TestSample(unittest.TestCase):
      04     """Test the Sample class"""
      06     def test_title(self):
      07         sample = Sample()
      08         self.assertEqual(sample.title, None)
      09         sample.title = 'Sample Title'
      10         self.assertEqual(sample.title, 'Sample Title')
      12     def test_getDescription(self):
      13         sample = Sample()
      14         self.assertEqual(sample.getDescription(), '')
      15         sample._description = "Description"
      16         self.assertEqual(sample.getDescription(), 'Description')
      18     def test_setDescription(self):
      19         sample = Sample()
      20         self.assertEqual(sample._description, '')
      21         sample.setDescription('Description')
      22         self.assertEqual(sample._description, 'Description')
      23         sample.setDescription(u'Description2')
      24         self.assertEqual(sample._description, u'Description2')
      25         self.assertRaises(AssertionError, sample.setDescription, None)
      28 def test_suite():
      29     return unittest.TestSuite((
      30         unittest.makeSuite(TestSample),
      31         ))
      33 if __name__ == '__main__':
      34     unittest.main()

    o Line 3-4: We usually develop test classes, which must inherit
      from 'TestCase' . While often not done, it is a good idea to
      give the class a menaingful doc string that describes the purpose of
      the tests it includes.

    o Line 6, 12 & 18: When a test case is run, a method called 'runTests()' 
      is executed. While it is possible to overwrite this method to run tests
      differently, the default option is very sensible and is used everywhere
      in Zope 3. The method will look for any method whose name starts with 'test' 
      and execute it as a single test. This way we can create a "test method"
      for each aspect, method, function or property of the code to be tested.

      Note that there is no doc string for test methods. This is
      intentional. If a doc string is specified, it is used instead of the
      method name to identify the test. When specifying doc string, we have
      noticed that it is very difficult to identify the test later; therefore
      the method name is a much better choice.

    o Line 8, 10, 14,  
: The 'TestCase' class implements a handful of methods that do the
      testing for you. Here are some of the most frequently used ones. For a
      complete list see the standard Python documentation referenced above.

      -'assertEqual(first, second[, msg])' 
Checks whether the 'first' and 'second' value are equal. If the test
        fails, the 'msg' or 'None' is returned.

      -'assertNotEqual(first, second[, msg])' 
This is simply the opposite to 'assertEqual()' by checking for
        non-equality.

      -'assertRaises(exception, callable, ...)' 
You expect the 'callable' to raise 'exception' when executed. After
        the 'callable' you can specify any amount of positional and
        keyword arguments for the 'callable' . If you expect a group
        of exceptions from the execution, you can make 'exception' a
        tuple of possible exceptions.

      -'assert' 
Assert checks whether the specified expression executes correctly.
        If not, the test fails and 'msg' or 'None' is returned.

      -'failUnlessEqual()' 
This testing method is equivalent to 'assertEqual()' .

      -'failUnless(expr[, msg])' 
Equivalent to 'assert' .

      -'failif()' 
This is the opposite to 'failUnless()' .

      -'fail([msg])' 
Fails the running test without any evaluation. This is commonly use
        when testing various possible execution paths at once and you would
        like to signify a failure if an improper path was taken.  

    o Line 6-10: This method tests the 'title' attribute of the 'Sample' 
      class. The first test should be of course that the attribute exists and
      has the expected initial value (line 8). Then the title attribute is
      changed and we check whether the value was really stored. This might
      seem like overkill, but later you might change the title in a way that
      it uses properties instead. Then it becomes very important to check
      whether this test still passes.

    o Line 12-16: First we simply check that 'getDescription()' 
      returns the correct default value. Since we do not want to use other
      API calls like 'setDescription()' we set a new value of the
      description via the implementation-internal '_' attribute (line
      15). This is okay! Tests can make use of implementation-specific
      attributes and methods. Finally we just check that the correct value is
      returned.

    o Line 18-25: On line 21-24 it is checked that both regular and
      unicode strings are set correctly. In the last line of the test we make
      sure that no other type of objects can be set as a description and that
      an error is raised.

    o 28-31: This method returns a test suite that includes all test
      cases created in this module. It is used by the Zope 3 test runner when
      it picks up all available tests. You would basically add the line 'unittest.makeSuite(TestCaseClass)' 
      for each additional test case.

    o 33-34: In order to make the test module runnable by itself, you
      can execute 'unittest.main()' when the module is run.  


    
  Running the Tests


    You can run the test by simply calling 'python unittests.py' from
    the directory you saved the file in. When using the default Zope 3 test
    runner, tests will be picked up as long as they follow some conventions.
     

    - The tests must either be in a package or module called 'tests' .

    - If 'tests' is a package, then all test modules inside must also
      have a name starting with 'test' , as it is the case with our
      name 'test' .

    - The test module must be somewhere in the Zope 3 source tree,
      since the test runner looks only for files there.  


    You you can use the test runner to run only the sample tests as
    follows::

      python -vp test.py module.path.to.tests.test_sample
        The '-v' option stands for verbose mode, so that detailed
    information about a test failure is provided. The '-p' option
    enables a progress bar that tells you how many tests out of all have been
    completed. There are many more options that can be specified. You can get
    a full list of them with the option '-h' : 'python test.py -h' .


  Exercises

    - Exercise 1: It is not very common to do the setup - in our case
      'sample = Sample()' - in every test method. Instead there exists
      a method called 'setUp()' and its counterpart 'tearDown' that
      are run before and after each test, respectively. Change the test code
      above, so that it uses the 'setUp()' method. In later chapters
      and the rest of the book we will frequently use this method of setting
      up tests.

    - Exercise 2: Currently the 'test' test only verifies that None is
      not allowed as input value.

      - Improve the test, so that all other builtin types are tested
        as well.

      - Also, make sure that any objects inheriting from 'str' or 'unicode' 
        pass as valid values.  

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/BasicUnitTests

From Mailer-Daemon at python.org  Tue Feb 17 07:51:36 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Tue Feb 17 07:51:38 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1At4hM-0007Fp-NA@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1At4ge-0007E8-D5; Tue, 17 Feb 2004 07:50:52 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [DocTests] (new) first draft (generated from LaTeX file)
Message-ID: <20040217075052EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DocTests/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DocTests/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DocTests>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Tue, 17 Feb 2004 07:50:52 -0500
X-Spam-Status: OK (default 0.000)

Doctests: Example-driven Unit Tests

  Status

    IsDraft

  Authors

    StephanRichter

  Difficulty

    Newcomer Level  

  Skills

    - You should have read the previous recipe on unit tests, since
      this recipe heavily depends on it.  


  Problem/Task

    Unit tests are nice, but they are not the best implementation of
    what eXtreme Programming expects of testing. Testing should also serve as
    documentation, a requirement that the conventional unit test module
    pattern does not provide. This recipe will show you an alternative way of
    writing unit tests that can also serve well as documentation.  


  Recipe

    
  Introduction


    Python already provides doc strings for classes and methods, which
    serve - like the name suggests - as documentation for the object. If you
    would be able to write tests in the doc strings of classes and methods
    and execute them during test runs, all requirements are fulfilled. Even
    better, the tests would automatically become part of the documentation.
    This way the documentation reader would always see a working example of
    the code. Since most people learn by example, this will also speed up the
    learning process of the technology.

    The solution to this problem are doc tests, which have exactely the
    described behavior. If you embed Python-prompt-like sample code in the
    doc strings of a class and register the contained module as one having
    doc tests, then the Python code in the doc strings is executed for
    testing. Each doc string will be counted as a single test.

    
  Integrating the Doc Test


    So how does our example change from the previous recipe? First of
    all, you can completely get rid of the 'TestSample' class. Next, add
    the following lines to the doc string of the 'Sample' class::

      01   Examples::
      03     >>> sample = Sample()
      05     Here you can see how the 'title' attribute works.
      07     >>> print sample.title
      08     None
      09     >>> sample.title = 'Title'
      10     >>> print sample.title
      11     Title
      13     The description is implemented using a accessor and mutator method
      15     >>> sample.getDescription()
      16     ''
      17     >>> sample.setDescription('Hello World')
      18     >>> sample.getDescription()
      19     'Hello World'
      20     >>> sample.setDescription(u'Hello World')
      21     >>> sample.getDescription()
      22     u'Hello World'
      24     'setDescription()' only accepts regular and unicode strings
      26     >>> sample.setDescription(None)
      27     Traceback (most recent call last):
      28       File "<stdin>", line 1, in ?
      29       File "test_sample.py", line 31, in setDescription
      30         assert isinstance(value, (str, unicode)) 
      31     AssertionError

    o Line 1: The double colon at this line is not mistake. In Zope
      3's documentation tools we assume that all doc strings are written in
      structured text, a plain text format that allows to insert some markup
      without destroying the readability of the text. The double colon simply
      signifies the beginning of a code segment.

    o Line 5, 13 & 24: It is even possible to insert additional
      comments for better documentation.  


    Before we can run the tests, we have to change the way the tests are
    executed. The last two lines should now read::

      01 if __name__ == '__main__':
      02     unittest.main(defaultTest='test_suite')

    You can now execute the test as before using 'Python test' . As you
    can see doc tests are a much more natural way to test your code. However,
    there are a couple of issues that one should be aware of when using doc
    tests.

    
  Shortcomings


    The most obvious problem is that if you like to test attributes and
    properties, there is no doc string to place the tests. This problem is
    usually solved by testing attributes implicitely in context of other
    tests and/or place their tests in the class' doc string. This solution is
    actually good, since attributes by themselves usually do not have much
    functionality, but are used in combination with methods to provide
    functionality.

    Next, it is not easy for certain outputs. The prime example here is
    'None' , since it has no representation. The easy way around this is
    to make the testing statement a condition. So the statement 'methodReturningNone()' 
    which should return 'None' is converted to 'methodReturningNone() is None' 
    which should return 'True' . There are also some issues when testing
    statements that return output whose representation is longer than a line,
    since the doc string checker is not smart enough the remove the
    indentation white space. A good example of such objects are lists and
    tuples. The easy solution is to save the list and only test some chunks
    at a time.

    Over time I have noticed that using doc tests makes me write sloppy
    tests. Since I think of the tests as examples to show how the class is
    supposed to work, I often neglect to test for all aspects and possible
    situation a piece of code could come into. This problem can be solved by
    either writing some additional classic unit tests or create a special
    testing module that contains further doc tests.

    While doc tests cover  98%of all test situations well, there are
    some tests that require heavy programming. A good example of that is a
    test in the internationalization support that makes sure that all XML
    locale files can be parsed and some of the most important data is
    correctly evaluated. I found that it is totally okay to use regular unit
    tests for these scenarios.

    Overall I think doc tests are the way to go!  


  Exercises

    - Exercise 1: As a matter of taste, some people like it better
      when each method is tested in the method doc string. Therefore, move
      the 'getDescription' and 'setDescription' tests to the methods
      doc string and make sure that all three tests pass.

    - Exercise 2: Once you have split up the tests, you always have to
      setup the 'sample' object over and over again. Here doc tests
      also provide a way to specify a 'setUp()' and 'tearDown()' 
      method. They can be passed in as the second and third argument of the 'DocTestSuite' 
      , respectively. Change the tests in a way that they use a 'setUp()' 
      method for creating the 'Sample' instance.

    - Exercise 3: (Equivalent to excercise 2 in the previous recipe)
      Currently the 'test' test only verifies that None is not allowed
      as input value.

      - Improve the test, so that all other builtin types are tested
        as well.

      - Also, make sure that any objects inheriting from 'str' or 'unicode' 
        pass as valid values.  

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DocTests

From Mailer-Daemon at python.org  Tue Feb 17 07:54:41 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Tue Feb 17 07:54:43 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1At4kL-0007gS-Pf@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1At4jf-0007dB-KX; Tue, 17 Feb 2004 07:53:59 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [VocabulariesAndFields] (new) first draft (generated from LaTeX file)
Message-ID: <20040217075359EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/VocabulariesAndFields/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/VocabulariesAndFields/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/VocabulariesAndFields>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Tue, 17 Feb 2004 07:53:59 -0500
X-Spam-Status: OK (default 0.000)

Vocabularies and their Fields

  Status

    IsDraft

  Authors

    StephanRichter

  Difficulty

    Sprinter Level  

  Skills

    - Be familiar with the 'schema' package, including widgets.  


  Problem/Task

    You will agree that schemas in combination with widgets and forms
    are pretty cool. The times of writing boring HTML forms and data
    verification are over. However, the standard fields make it hard (if not
    impossible) to create a dynamic list of possible values to choose from.
    To solve this problem, the vocabulary, vocabulary field and corresponding
    widgets were developed. In this recipe we will demonstrate one of the
    common usages of vocabularies in Zope 3.  


  Recipe

    
  Introduction


    A common user interface pattern is to provide the user with a list
    of available or possible values from which one or more might be selected.
    This is done to reduce the amount of errors the user could possibly make.
    Often the list of choices is static, meaning they do not change over time
    or are dependent on a particular situations. On the other hand, you
    commonly have choices for a field that depend strongly on the situation
    you are presented with.

    Standard enumerated fields do not have a mechanism to allow for
    dynamic choices. It would also be hard for them to create dynamic
    choices, since they are not aware of the context in which they are used.
    To address this problem, vocabularies were created, which are able to
    provide dynamic lists. The developer can then use a 'VocabularyField' 
    in her/his schema that specifies a specific vocabulary that should be
    used.

    Vocabularies in itself are a pretty complex subject, since
    implementations can range from providing the values of a simple list to
    backend SQL queries. For large data sets vocabularies also have a simple
    query support, so that we can build a sane user interface for the data.
    Generally, there are two ways to use vocabularies in Zope 3, the ones
    that do not and others that do need a place to generate the data.
    Vocabularies that do not need a place can be created as singeltons and
    would be useful when data is retrieved from a file, RDB or any other
    Zope-external data source. In this recipe, however, we are going to
    implement a vocabulary that provides a list of all the items of a
    container (or any other 'IReadMapping' object), so that the location
    matters.

    Vocabularies that need a location, cannot exist as singletons, but
    the location must be passed into the constructor. Zope 3 provides a
    vocabulary registry with which one can register vocabulary factories
    (which are usually just the classes) by name. The ZCML looks like this::

      01 <vocabulary
      02    name="VocabularyName"
      03    factory=".vocab.Vocabulary" />

    You can then use the vocabulary in a schema by declaring a
    vocabulary field::

      01 field = VocabularyField(
      02     title=u"...",
      03     description=u"...",
      04     vocabulary="VocabularyName")

    If the 'vocabulary' argument value is a string, then it is used as a
    vocabulary name, and the vocabulary is created with a context whenever
    needed. But the argument also accepts 'IVocabulary' instances, which
    are directly used.

    Okay, I wrote already too much. Let's see how we can achieve our
    task using vocabularies.

    
  The Vocabulary and its Terms


    A vocabulary has a very simple interface. It is almost like a simple
    mapping objects with some additional functionality. The main idea is that
    a vocabulary provides 'ITerm' objects. A term has simply a 'value' 
    that can be any Python object. However, for Web forms (and other user
    interfaces) this minimalistic interface does not suffice, since we have
    now way of reliably specifiying a unique id (a string) for a term, which
    we need to do to create any HTML input element with the terms. To solve
    this problem, the 'ITokenizedTerm' was developed, which provides a 'token' 
    attribute that must be a string identifying the term.

    However, since our vocabulary deals with folder item names, our 'ITerm''value' 
    is equal to the 'token' . Therefore, we only need a minimal
    implementation of 'ITokenizedTerm' as seen below.::

      01 from zope.interface import implements
      02 from zope.schema.interfaces import ITokenizedTerm
      03 from zope.interface.common.mapping import IEnumerableMapping
      05 class ItemTerm(object):
      06     """A simple term implementation for items."""
      07     implements(ITokenizedTerm)
      08     def __init__(self, value):
      09         self.value = self.token = value

    Create a new product called 'itemvocabulary' in 'ZOPE3/src/zope/products/demo' 
    . Place the above code in the '_' file.

    Next we need to implement the vocabulary. Since the context of the
    vocabulary is an 'IReadMapping' object, the implementation is
    straightforward::

      01 from zope.schema.interfaces import IVocabulary, IVocabularyTokenized
      02 from zope.interface.common.mapping import IEnumerableMapping
      04 class ItemVocabulary(object):
      05     """A vocabulary that provides the keys of any IEnumerableMapping object.
      07     Every dictionary will qualify for this vocabulary."""
      08     implements(IVocabulary, IVocabularyTokenized)
      09     __used_for__ = IEnumerableMapping
      11     def __init__(self, context):
      12         self.context = context
      14     def __iter__(self):
      15         """See zope.schema.interfaces.IIterableVocabulary"""
      16         return iter([ItemTerm(key) for key in self.context.keys()])
      18     def __len__(self):
      19         """See zope.schema.interfaces.IIterableVocabulary"""
      20         return len(self.context)
      22     def __contains__(self, value):
      23         """See zope.schema.interfaces.IBaseVocabulary"""
      24         return value in self.context.keys()
      26     def getQuery(self):
      27         """See zope.schema.interfaces.IBaseVocabulary"""
      28         return None
      30     def getTerm(self, value):
      31         """See zope.schema.interfaces.IBaseVocabulary"""
      32         if value not in self.context.keys():
      33             raise LookupError, value
      34         return ItemTerm(value)
      36     def getTermByToken(self, token):
      37         """See zope.schema.interfaces.IVocabularyTokenized"""
      38         return self.getTerm(token)

    o Line 8: Make sure that you implement both, 'IVocabulary' and 'IVocabularyTokenized' 
      , so that the widget mechanism will work correctly later.

    o Line 14-16: Make sure that the values of the iterator are 'ITerm' 
      objects and not simple strings.

    o Line 26-28: We do not support queries in this implementation.
      The interface specifies that vocabularies not supporting queries must
      return 'None' .

    o Line 30-34: We must be careful here and not just create an 'ItemToken' 
      from the value, since the interface specifies that if the value is not
      available in the vocabulary, a 'LookupError' should be raised.

    o Line 36-38: Since the 'token' and the 'value' are equal, we can
      just forward the request to 'getTerm()' .  


    Since the vocabulary requires a context for initiation, we need to
    register it with the vocabulary registry. The vocabulary is also used in
    untrusted environments, so that we have to make security assertions for
    it and the term. Place the ZCML directives below in the 'configure.zcml' 
    of the package.::

      01 <configure
      02     xmlns="http://namespaces.zope.org/zope"
      03     i18n_domain="itemvocabulary">
      05 <vocabulary
      06     name="Items"
      07     factory=".ItemVocabulary" />
      09 <content class=".ItemVocabulary">
      10   <allow interface="zope.schema.interfaces.IVocabulary"/>
      11   <allow interface="zope.schema.interfaces.IVocabularyTokenized"/>
      12 </content>
      14 <content class=".ItemTerm">
      15   <allow interface="zope.schema.interfaces.ITokenizedTerm"/>
      16   <allow attributes="title"/>
      17 </content>
      19 </configure>

    o Line 5-7: Register the vocabulary under the name "Items". The
      vocabulary directive is available in the default "zope" namespace.

    o Line 9-16: We simply open up all of the interfaces to the
      public, since the objects that provide the data are protected
      themselves.  


    That was easy, right? Now, let's write some quick tests for this
    code.

    
  Testing the Vocabulary


    The tests are as straightforward as the code itself. We are going to
    only test the vocabulary, since it uses the trivial term. In the doc
    string of the 'ItemVocabulary' class add the following example and
    test code::

      01 """
      02 Example::
      04   >>> data = {'a': 'Anton', 'b': 'Berta', 'c': 'Charlie'}
      05   >>> vocab = ItemVocabulary(data)
      06   >>> iterator = iter(vocab)
      07   >>> iterator.next().token
      08   'a'
      09   >>> len(vocab)
      10   3
      11   >>> 'c' in vocab
      12   True
      13   >>> vocab.getQuery() is None
      14   True
      15   >>> vocab.getTerm('b').value
      16   'b'
      17   >>> vocab.getTerm('d')
      18   Traceback (most recent call last):
      19   ...
      20   LookupError: d
      21   >>> vocab.getTermByToken('b').token
      22   'b'
      23   >>> vocab.getTermByToken('d')
      24   Traceback (most recent call last):
      25   ...
      26   LookupError: d
      27 """

    The tests are activated via a doc test that is initialized in 'tests.py' 
    with the following code::

      01 import unittest
      02 from zope.testing.doctestunit import DocTestSuite
      04 def test_suite():
      05     return unittest.TestSuite((
      06         DocTestSuite('zope.products.demo.itemvocabulary'),
      07         ))
      09 if __name__ == '__main__':
      10     unittest.main(defaultTest='test_suite')

    You can execute the tests as usual via the Zope 3 test runner or
    call the test file directly after you have set the correct Python path.

    
  The Default Item Folder


    To see the vocabulary working, we will develop a derived Folder,
    which simply keeps track of a default item (whatever "default" may mean).
    Since the folder is part of a browser demonstration, we write the folder
    interface and implementation in 'browser.py'::

      01 from zope.interface import implements, Interface
      02 from zope.schema.vocabulary import VocabularyField
      03 from zope.app.content.folder import Folder
      05 class IDefaultItem(Interface):
      07     default = VocabularyField(
      08         title=u"Default Item Key",
      09         description=u"Key of the default item in the folder.",
      10         vocabulary="Items")
      12 class DefaultItemFolder(Folder):
      13     implements(IDefaultItem)
      15     default = None

    o Line 7-10: The 'VocabularyField' is like any other field, except
      that you can specify a vocabulary. The 'vocabulary' argument can
      either be the vocabulary name or a vocabulary instance, as pointed out
      earlier in this recipe.

    o Line 12-15: A trivial content component implementation that
      combines 'IFolder' and 'IDefaultItem' .  


    Now we only have we just have to register the new content component,
    make some security assertions and create an edit form for the 'default' 
    value. All of this can be done with the following three ZCML directives::

      01 <content class=".browser.DefaultItemFolder">
      02   <require like_class="zope.app.content.folder.Folder"/>    
      04   <require
      05       permission="zope.View"
      06       interface=".browser.IDefaultItem" />
      08   <require
      09       permission="zope.ManageContent"
      10       set_schema=".browser.IDefaultItem" />
      11 </content>
      13 <browser:addMenuItem
      14     class=".browser.DefaultItemFolder"
      15     title="Default Item Folder"
      16     permission="zope.ManageContent" />
      18 <browser:editform
      19     schema=".browser.IDefaultItem"
      20     for=".browser.IDefaultItem"
      21     label="Change Default Item"
      22     name="defaultItem.html"
      23     permission="zope.ManageContent"
      24     menu="zmi_views" title="Default Item" />

    Don't forget to register the 'browser' namespace in the 'configure' 
    tag::

      xmlns:browser="http://namespaces.zope.org/browser"
        You are now ready to go. Restart Zope 3. Once you refresh the
    ZMI, you will see that you can now add a "Default Item Folder". Create
    such a folder and add a couple other components to it, like images and
    files. If you now click on the "Default Item" tab, you will see a
    selection box with the names of all contained objects. Select one and
    submit the form. You now stored the name of the object that will be
    considered the "default". As you can see, there exist widgets that know
    how to display a vocabulary field. See exercise 1 for changing the used
    widget.  


  Exercises

    - Exercise 1: Change the 'defaultItem.html' of the 'DefaultItemFolder' 
      so that it uses radio buttons instead of a drop-down menu. (Hint: You
      need to create a Python view class for the 'editform' directive
      and add a custom widget.)  

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/VocabulariesAndFields

From Mailer-Daemon at python.org  Tue Feb 17 07:55:45 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Tue Feb 17 07:55:50 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1At4lN-0007y9-K1@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1At4kg-0007oR-Ub; Tue, 17 Feb 2004 07:55:02 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [NewWebDAVNamespace] (new) first draft (generated from LaTeX file)
Message-ID: <20040217075503EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NewWebDAVNamespace/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NewWebDAVNamespace/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NewWebDAVNamespace>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Tue, 17 Feb 2004 07:55:03 -0500
X-Spam-Status: OK (default 0.000)

Registering new WebDAV Namespaces

  Status

    IsDraft

  Authors

    StephanRichter

  Difficulty

    Sprinter Level  

  Skills

    - You should know Zope 3's component architecture.

    - Be familiar with the WebDAV standard as proposed in RFC 2518.  


  Problem/Task

    WebDAV, as an advanced application of HTTP and XML, supports an
    unlimited amount metadata to be associated with any resource. This, of
    course, is non-sense for Zope related applications and could potentially
    make Zope vulnerable to DoS attacks, since someone could try to add huge
    amounts of meta-data to a resource. A namespace registry was created that
    manages the list of all available namespaces per content type
    (interface). This recipe will show you how to enable a new namespace
    called 'photo' for an 'IImage' object.  


  Recipe

    
  Introduction


    As mentioned above, WebDAV's unlimited support for XML namespaces
    make WebDAV very powerful but also provide an easy target for malicous
    attacks if not properly controlled. Therefore we would like to control,
    an object's WebDAV namespaces as well as the permissions required to
    access and modify the the namespace's attributes. Furthermore, there was
    a desire to integrate the namespace data and handling into Zope 3 as much
    as possible, so that other components could easily reuse the information.

    First of all we noticed that namespaces with attributes are really
    just schemas, so that we were able to describe a namespace using the Zope
    3 'schema' package. Now we were even able to write WebDAV widgets
    for the schema field types. Adapters could be used to connect a namespace
    to a content type or any other object. Finally, we needed a way to tell
    WebDAV which schema would be available under WebDAV and what namespace
    name it would be associated with. This was solved by a simple registry,
    which mapped a schema to a namespace name and vice versa. If an adapter
    from a given object/resource to a registered schema is available, then
    the object is considered to be able to provide the associated namespace.

    If one wants to provide a new namespace for a given object, the main
    task for the developer consists of creating a schema for the namespace
    and to provide an adapter from the object to the schema. The goal of this
    recipe will be to provide some additional metadata information about
    images that have been taken by digital cameras - images that are photos.

    Let's start a new product. Create a new package called 'photodavns' 
    in '<ZOPE3>/src/zope' .

    
  Creating the Namespace Schema


    The schema of the photo should contain some information that are
    usually provided by the camera. To implement the schema, open a new file
    'interfaces.py' and add the following code.::

      01 from zope.interface import Interface
      02 from zope.schema import Text, TextLine, Int, Float
      04 photodavns = "http://namespaces.zope.org/dav/photo/1.0"
      06 class IPhoto(Interface):
      07     """A WebDAV namespace to store photo-related meta data.
      09     The 'IPhoto' schema/namespace can be used in WebDAV clients to determine
      10     information about a particular picture. Obviously, this namespace makes
      11     only sense on Image objects.
      12     """
      14     height = Int(
      15         title=u"Height",
      16         description=u"Specifies the height in pixels.",
      17         min=1)
      19     width = Int(
      20         title=u"Width",
      21         description=u"Specifies the width in pixels.",
      22         min=1)
      24     equivalent35mm = TextLine(
      25         title=u"35mm equivalent",
      26         description=u"The photo's size in 35mm is equivalent to this amount")
      28     aperture = TextLine(
      29         title=u"Aperture",
      30         description=u"Size of the aperture.")
      32     exposureTime = Float(
      33         title=u"Exposure Time",
      34         description=u"Specifies the exposure time in seconds.")

    o Line 4: The name of the namespace is also part of the interface,
      so declare it here. The name must be a valid URL, otherwise the
      configuration directive that registers the namespace will fail.  


    There is nothing more of interest in this code; at this time you
    should be very comfortable with interfaces and schemas. If not, please
    read the recipes on interfaces and schemas.

    
  Implementing the  'IPhoto' to  'IImage' Adapter


    Next we need to implement the adapter, which will use annotations to
    store the attribute data. That means that the 'IImage' object must
    also implement 'IAttributeAnnotable' . With the knowledge of the
    annotations recipe, the following implementation should seem simple.::

      01 from zope.interface import implements
      02 from persistence.dict import PersistentDict
      03 from zope.app import zapi
      04 from zope.app.interfaces.annotation import IAnnotations
      05 from zope.app.interfaces.content.image import IImage
      06 from zope.schema import getFieldNames
      07 from interfaces import IPhoto, photodavns
      09 class ImagePhotoNamespace(object):
      10     """Implement IPhoto namespace for IImage."""
      12     implements(IPhoto)
      13     __used_for__ = IImage
      15     def __init__(self, context):
      16         self.context = context
      17         self._annotations = zapi.getAdapter(context, IAnnotations)
      18         if not self._annotations.get(photodavns):
      19             self._annotations[photodavns] = PersistentDict()
      21     def __getattr__(self, name):
      22         if not name in getFieldNames(IPhoto):
      23             return super(ImagePhotoNamespace, self).__getattribute__(name)
      24         return self._annotations[photodavns].get(name, None)
      26     def __setattr__(self, name, value):
      27         if not name in getFieldNames(IPhoto):
      28             return super(ImagePhotoNamespace, self).__setattr__(name, value)
      29         field = IPhoto[name]
      30         field.validate(value)
      31         self._annotations[photodavns][name] = value

    o Line 15-19: During initialization, get the annotations for the 'IImage' 
      object and create a dictionary where all the attribute values will be
      stored. Make sure that the dictionary is a 'PersistentDict' 
      instance, since otherwise the data will not be stored permanently in
      the ZODB.

    o Line 21-24: If the name of the requested attribute corresponds
      to a field in 'IPhoto' then we get the value from the
      annotations otherwise use the usual way. Note that I had to use '_' 
      for the normal case, since 'object' does not provide '_' 
      publically.

    o Line 26-31: We want to set attributes differently, if they are
      fields in the 'IPhoto' schema. If the name is a field, then the
      first task is to get the field which is then used to validate the
      value. This way we can enforce all specifications provided for the
      fields in the schema. If the validation passes, then store the value in
      the annotations.  


    
  Unit-Testing and Configuration


    For the unit tests of the adapter, we use doc tests. So we extend
    the adapter's class doc string to become::

      01 """Implement IPhoto namespace for IImage.
      03 Examples::
      05   >>> from zope.app.content.image import Image
      06   >>> image = Image()
      07   >>> photo = zapi.getAdapter(image, IPhoto)
      09   >>> photo.height is None
      10   True
      11   >>> photo.height = 768
      12   >>> photo.height
      13   768
      14   >>> photo.height = u'100'
      15   Traceback (most recent call last):
      16   ...
      17   ValidationError: (u'Wrong type', u'100', (<type 'int'>, <type 'long'>))
      19   >>> photo.width is None
      20   True
      21   >>> photo.width = 1024
      22   >>> photo.width
      23   1024
      25   >>> photo.equivalent35mm is None
      26   True
      27   >>> photo.equivalent35mm = u'41 mm'
      28   >>> photo.equivalent35mm
      29   u'41 mm'
      31   >>> photo.aperture is None
      32   True
      33   >>> photo.aperture = u'f/2.8'
      34   >>> photo.aperture
      35   u'f/2.8'
      37   >>> photo.exposureTime is None
      38   True
      39   >>> photo.exposureTime = 0.031
      40   >>> photo.exposureTime
      41   0.031
      43   >>> photo.occasion
      44   Traceback (most recent call last):
      45   ...
      46   AttributeError: 'ImagePhotoNamespace' object has no attribute 'occasion'
      47 """

    You can see that the example code covers pretty much every possible
    situation.  

    o Line 5-7: Use the standard 'Image' content component as context
      for the adapter. Then we use the component architecture to get the
      adapter. This already tests whether the constructor - which is not
      trivial in this case - does not cause an exception.

    o Line 14-17: Test that the validation of the field's values works
      correctly.

    o Line 43-46: We also need to make sure that no non-existing
      attributes can be assigned a value.  


    To make the tests runnable, add a file named 'tests.py' and add the
    following test code.::

      01 import unittest
      02 from zope.app.tests import ztapi
      03 from zope.app.tests.placelesssetup import setUp, tearDown 
      04 from zope.app.attributeannotations import AttributeAnnotations
      05 from zope.app.content.image import Image
      06 from zope.app.interfaces.annotation import IAnnotations
      07 from zope.app.interfaces.annotation import IAttributeAnnotatable
      08 from zope.app.interfaces.content.image import IImage
      09 from zope.interface import classImplements
      10 from zope.products.photodavns.interfaces import IPhoto
      11 from zope.products.photodavns import ImagePhotoNamespace
      12 from zope.testing.doctestunit import DocTestSuite
      14 def customSetUp():
      15     setUp()
      16     ztapi.provideAdapter(IImage, IPhoto, ImagePhotoNamespace)
      17     ztapi.provideAdapter(IAttributeAnnotatable, IAnnotations,
      18                          AttributeAnnotations)
      19     classImplements(Image, IAttributeAnnotatable)
      21 def test_suite():
      22     return unittest.TestSuite((
      23         DocTestSuite('zope.products.photodavns', customSetUp, tearDown),
      24         ))
      26 if __name__ == '__main__':
      27     unittest.main(defaultTest='test_suite')

    o Line 14-19: We need to setup some additional adapters to make
      the tests work. First, of course, we need to register our adapter. Then
      we also need to provide the 'AttributeAdapter' , so that the 'ImagePhotoNamespace' 
      will find the annotations for the image. Finally, since 'Image' 
      does not implement 'IAttributeAnnotable' directly (it is usually
      done in a ZCML directive), we need to declare it manually here.

    o 21-24: The 'setUp()' and 'tearDown()' methods for a doc test can
      be passed as arguments to the 'DocTestSuite' constructor.  


    From the Zope 3 root directory, you can now execute the tests using::

      python test.py -vp zope.products.photodavns
        
  Functional Testing


    Now let's see our new namespace in action. Unfortunately, I am not
    aware of any WebDAV tools that can handle genericly any namespace. For
    this reason we will use functional tests for confirming the correct
    behavior.

    In the first step we will test whether 'PROPFIND' will (a)
    understand the namespace and (b) return the right values from the
    annotation of the image. Here is the complete code for the functional
    test, which you should place in a file called 'ftests.py' .::

      01 import unittest
      02 from transaction import get_transaction
      03 from xml.dom.minidom import parseString as parseXML
      04 from zope.app import zapi
      05 from zope.app.content.image import Image
      06 from zope.app.dav.ftests.dav import DAVTestCase
      07 from zope.component import getAdapter
      08 from zope.products.photodavns.interfaces import IPhoto
      09 from zope.products.photodavns import ImagePhotoNamespace
      11 property_request = '''\
      12 <?xml version="1.0" encoding="utf-8" ?>
      13 <propfind xmlns="DAV:">
      14   <prop xmlns:photo="http://namespaces.zope.org/dav/photo/1.0">
      15     <photo:height />
      16     <photo:width />
      17     <photo:equivalent35mm />
      18     <photo:aperture />
      19     <photo:exposureTime />
      20   </prop>
      21 </propfind>
      22 '''
      24 data = {'height': 768, 'width': 1024, 'equivalent35mm': u'41 mm',
      25         'aperture': u'f/2.8', 'exposureTime': 0.031}
      27 class IPhotoNamespaceTests(DAVTestCase):
      29     def createImage(self):
      30         img = Image()
      31         photo = ImagePhotoNamespace(img)
      32         for name, value in data.items():
      33             setattr(photo, name, value)
      34         root = self.getRootFolder()
      35         root['img.jpg'] = img
      36         get_transaction().commit()
      38     def test_propfind_fields(self):
      39         self.createImage()
      40         response = self.publish(
      41             '/img.jpg/',
      42             env={'REQUEST_METHOD':'PROPFIND',
      43                  'HTTP_Content_Type': 'text/xml'},
      44             request_body=property_request)
      45         self.assertEqual(response.getStatus(), 207)
      46         xml = parseXML(response.getBody())
      47         node = xml.documentElement.getElementsByTagName('prop')[0]
      49         for name, value in data.items():
      50             attr_node = node.getElementsByTagName(name)[0]
      51             self.assertEqual(attr_node.firstChild.data, unicode(value))
      53 def test_suite():
      54     return unittest.TestSuite((
      55         unittest.makeSuite(IPhotoNamespaceTests),
      56         ))
      58 if __name__ == '__main__':
      59     unittest.main(defaultTest='test_suite')

    o Line 11-22: This is the XML request that will be sent to the
      Zope 3 WebDAV server. Note that we need to make sure that The first
      line starts at the beginning of the string, since otherwise the XML
      parser causes a failure. In the string, we simply request explicitely
      all attributes of the 'photo' namespace.

    o Line 24-25: Here is the data that is being setup in the
      annotation and that we expect to receive from the 'PROPFIND' 
      request.

    o Line 29-36: This helper method creates an image and sets the
      photo data on the image, so that we can access it. Note that we have to
      commit a transaction at this point, otherwise the image will not be
      found in the ZODB.

    o 38-51: First we create the image so that it will be available.
      Then we just publish our request with a carefully constructed
      environment. To make the request a 'PROPFIND' call, you need to
      create a environment variable named 'REQUEST' . Since we send
      XML as the body of the request, we need to set the content type to
      "text/xml", which is done with a 'HTTP' environment entry.

      The answer we receive from the server should be 207, which
      signalizes that the 'PROPFIND' call was successful and the data
      is enclosed in the body. We then parse the XML body simply using
      Python's built-in 'xml.dom.minidom' package. The rest of the
      test code simply uses DOM to ensure that all of the requested
      attributes were returned and the data is correct.  


    Once you are done with the functional test, you can run it using the
    usual method::

      python test.py -vpf zope.products.photodavns
        The '-f' option executes only functional tests. Functional tests
    are recognized by their module name, which must be 'ftests' in
    comparison to 'tests' for regular unit tests.  


  Exercises

    - Exercise 1: Implement 'height' and 'width' in a way that it uses
      the 'IImage' 's 'getImageSize()' method to get the values.

    - Exercise 2: JPEG files support EXIF metadata tags that often
      already contain the data provided by the 'IPhoto' interface, so
      change the adapter in a way that it first tries to retrieve the data
      from the image before using annotation data. See 'http://topo.math.u-psud.fr/' 
      for a Python implementation of a EXIF tag retriever.  

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NewWebDAVNamespace

From Mailer-Daemon at python.org  Tue Feb 17 07:56:05 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Tue Feb 17 07:56:08 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1At4lh-00089b-Ni@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1At4iI-0007VT-Kx; Tue, 17 Feb 2004 07:52:34 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [FunctionalTests] (new) first draft (generated from LaTeX file)
Message-ID: <20040217075234EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FunctionalTests/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FunctionalTests/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FunctionalTests>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Tue, 17 Feb 2004 07:52:34 -0500
X-Spam-Status: OK (default 0.000)

Writing Functional Tests

  Status

    IsDraft

  Authors

    StephanRichter

  Difficulty

    Newcomer Level  

  Skills

    - It would be nice to knwo how Zope 3 generated forms work.
      Optional.  


  Problem/Task

    Unit tests cover a large part of the testing requirements listed in
    the eXtreme Programming literature, but are not everything. There are
    also regression and functional tests. While regression tests can be
    handled with unit and doc tests, functional tests can't. For this reason
    the Zope 3 community members developed an extension to 'unittest' 
    that handle functional tests. This package is introduced in this recipe.
     


  Recipe

    
  Introduction


    Unit tests are very good for testing the functionality of a
    particular object in absence of the environment it will eventually live
    in. Regression tests build on this by testing the behavior of an object
    in a limited environment. Then functional tests should test the behavior
    of an object in a fully running system. Therefore functional tests often
    check the user interface behavior and it is not surprising that they are
    often found in the browser code of Zope. In fact, in Zope 3's
    implementation of functional tests there exists a base test case class
    for each view type, such as 'zope.testing.functional.BrowserTestCase' 
    or 'zope.app.dav.ftests.dav.DAVTestCase' .

    Each custom functional test case class provides some valuable
    methods that help you write the tests fast and efficiently. Here are the
    methods that the 'BrowserTestCase' provides.

    -'getRootFolder()' 
Returns the root folder of the database. This method is available in
      every functional test case class.

    -'makeRequest(path='', basic=None, form=None, env=' 
This class creates a new 'BrowserRequest' instance that can be used
      for publishing.  

      -'path' - This is the absolute path of the URL (i.e. the URL
        minus the protocol, server and port).

      -'basic' - It provides the authentication information of the
        format '"<login>:<password>"' . When Zope 3 is brought up
        for functional testing, a user with the login "mgr" and the password
        "mgrpw" is automatically created having the role "zope.Manager"
        assigned to it. So usually you will use '"mgr:mgrpw"' as
        your basic argument.

      -'form' - The argument is a dictionary that contains all
        fields that would be provided by an HTML form. Note that you should
        have covnerted the data already to their native Python format; be
        sure to only use unicode for strings.

      -'env' - This variable is also a dicationary where you can
        specify further environment variables, like HTTP headers. For
        example, the header 'X-Header: value' would be an entry of
        the form ''HTTP' in the dictionary.

      -'outstream' - Optionally you can define the the stream to
        which the outputted HTML is sent. If you do not specify one, one will
        be created for you.  


      However, one would often not use this method directly, since it
      does not actually publish the request. Use the 'publish()' 
      method described below.

    -'publish(self, path, basic=None, form=None, env=' 
The method creates a request, that is then published in a completely
      functional Zope 3 and finally returns a regular response object that is
      enhanced by a couple of methods:

      -'getOutput()' - Returns all of the text that was pushed to
        the outstream.

      -'getBody()' - Only returns all of the HTML of the response.
        It therefore excludes HTTP headers.

      -'getPath()' - Returns the path that was passed to the
        request.


      The 'path' , 'basic' , 'form' and 'env' have the same semantics
      as the equally-named arguments to 'makeRequest()' . If 'handle' 
      is 'False' , then occuring exceptions are not caught. If 'True' 
      , the default view of an exception is used and a nice formatted HTML
      page will be returned.

    -'checkForBrokenLinks(body, path, basic=None)' 
Given an output body and a published path, check whether the contained
      HTML contains any links and check that these links work. Since the
      availability of pages and therefore links depends on the permissions of
      the user, one might want to specify a login/password pair in basic. For
      example, if you have published a request as a manager, it will be very
      likely that the returned HTML contains links that require the manager
      role.


    
  Testing "Templated Page" Views


    Okay, now that we know how the 'BrowserTestCase' extends the normal
    'unittest.TestCase' , we can use it to write some functional tests
    for the "add", "edit" and "index" view of the "Templated Page" content
    type.

    Anywhere, create a file called 'test' and add the following
    functional testing code::

      01 import time
      02 import unittest
      04 from transaction import get_transaction
      05 from zope.testing.functional import BrowserTestCase
      06 from zope.app.content.zpt import ZPTPage
      08 class TemplatedPageTests(BrowserTestCase):
      09     """Funcional tests for Templated Page."""
      11     template = u'''
      12     <html>
      13       <body>
      14         <h1 tal:content="modules/time/asctime" />
      15       </body>
      16     </html>'''
      18     template2 = u'''
      19     <html>
      20       <body>
      21         <h1 tal:content="modules/time/asctime">time</h1>
      22       </body>
      23     </html>'''
      25     def createPage(self):
      26         root = self.getRootFolder()
      27         root['zptpage'] = ZPTPage()
      28         root['zptpage'].setSource(self.template, 'text/html')
      29         get_transaction().commit()
      31     def test_add(self):
      32         response = self.publish(
      33             "/+/zope.app.content.zpt.ZPTPage=",
      34             basic='mgr:mgrpw', 
      35             form={'add_input_name' : u'newzptpage',
      36                   'field.expand.used' : u'',
      37                   'field.source' : self.template,
      38                   'field.evaluateInlineCode.used' : u'',
      39                   'field.evaluateInlineCode' : u'on',
      40                   'UPDATE_SUBMIT' : 'Add'})
      42         self.assertEqual(response.getStatus(), 302)
      43         self.assertEqual(response.getHeader('Location'),
      44                          'http://localhost/@@contents.html')
      46         zpt = self.getRootFolder()['newzptpage']
      47         self.assertEqual(zpt.getSource(), self.template)
      48         self.assertEqual(zpt.evaluateInlineCode, True)
      50     def test_editCode(self):
      51         self.createPage()
      52         response = self.publish(
      53             "/zptpage/@@edit.html",
      54             basic='mgr:mgrpw', 
      55             form={'add_input_name' : u'zptpage',
      56                   'field.expand.used' : u'',
      57                   'field.source' : self.template2,
      58                   'UPDATE_SUBMIT' : 'Change'})
      59         self.assertEqual(response.getStatus(), 200)
      60         self.assert_(response.getBody().find('asctime">time</h1>') != -1)
      61         self.checkForBrokenLinks(response.getBody(), response.getPath(),
      62                                  'mgr:mgrpw')
      64     def test_index(self):
      65         self.createPage()
      66         t = time.asctime()
      67         response = self.publish("/zptpage", basic='mgr:mgrpw')
      68         self.assertEqual(response.getStatus(), 200)
      69         self.assert_(response.getBody().find(self.template2) != -1)
      70         self.checkForBrokenLinks(response.getBody(), response.getPath(),
      71                                  'mgr:mgrpw')
      73 def test_suite():
      74     return unittest.TestSuite((
      75         unittest.makeSuite(TemplatedPageTests),
      76         ))
      78 if __name__=='__main__':
      79     unittest.main(defaultTest='test_suite')

    o Line 25-29: This is the perfect example of a helper method. It
      creates a "Templated Page" content object called 'zptpage' . To
      write the new object to the ZODB, you have to commit the transaction
      using 'get' .

    o Line 31-48: To understand this test completely, it is surely
      helpful to be familiar with the way Zope 3 adds new objects and how the
      widgets create an HTML form. The "+"-sign in the URL is the adding view
      for a folder. The path that follows is simply the factory id of the
      content type (line 33).

      The form dictionary is another piece of information that must be
      carefully constructed. First of all, the 'field.expand.used' and
      'field.evaluateInlineCode.used' are required, whether you want
      to activate 'expand' and 'evaluateInlineCode' or not. It is
      required by the corresponding widgets. The 'add' key maps to the
      name the content object will recieve and 'UPDATE' just tells the
      form generator that the form was actually submitted and action should
      be taken. To make it easier on myself, I just created a "Templated
      Page" on the browser parallel to writing the functional test to get all
      of the above information.

      On line 42, we check whether the request was successful. Code
      302 signalizes a redirect and on line 43 we check that we are
      redirected to the correct page.

      Now, it is time to check in the ZODB whether the object has
      really been created and that all data was set correctly. On line 46 we
      retrieve the object itself and consequently we check that the source is
      set correctly and the 'evaluateInlineCode' flag was turned as
      request in the form (line 39).

    o Line 50-62: Before we can test whether the data of a "Templated
      Page" can be edited correctly, we have to create one. Here the 'createPage()' 
      method comes in handy, which quickly creates a page that we can use.
      Having done previous test already, the contents of the 'form' 
      dictionary should be obvious.

      Since the edit page returns itself, the status of the response
      should be 200. We also inspect the body of the response to make sure
      that the temlpate was stored correctly.

      One extremly useful feautre of the 'BrowserTestCase' is the
      check for broken links in the returned page. I would suggest that you
      do this test whenever a HTML page is returned by the response.

    o Line 64-71: Here we simply test the default view of the
      "Templated Page". No complicated forms or environments are needed. We
      just need to make sure that the template is executed correctly.


    
  Running Functional Tests


    The testing code directly depends on the Zope 3 source tree, so make
    sure to have it in you Python path. In Un*x/Linux you can do this using::

      export PYTHONPATH=$PYTHONPATH:<ZOPE3>/src 
        where '<ZOPE3>' is the path to you Zope 3 installation.
    Furthermore, functional tests depend on finding a file called 'ftesting.zcml' 
    , which is used to bring up the Zope 3 application server. Therefore it
    is best to just go to the directory '<ZOPE3>' , since there exists
    such a file. You can now execute our new funtional tests using::

      python path/to/ftest/test_templatedpage.py
        
    You will notice that these tests will take a couple seconds (5-10 seconds)
    to run. This is okay, since the functional tests have to bring up the
    entire Zope 3 system, which by itself will take about 4 seconds.  

  Exercises

    - Exercise 1: Add another functional test that checks the
      "Preview" and "Inline Code" screen.  

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FunctionalTests

From Mailer-Daemon at python.org  Tue Feb 17 07:57:49 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Tue Feb 17 07:57:53 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1At4nN-0000Q6-8t@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1At4mC-0008LH-KC; Tue, 17 Feb 2004 07:56:36 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [UsingTALES] (new) first draft (generated from LaTeX file)
Message-ID: <20040217075636EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/UsingTALES/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/UsingTALES/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/UsingTALES>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Tue, 17 Feb 2004 07:56:36 -0500
X-Spam-Status: OK (default 0.000)

Registering new WebDAV Namespaces

  Status

    IsDraft

  Authors

    StephanRichter

  Difficulty

    Sprinter Level  

  Skills

    - You should know Zope 3's component architecture.

    - Be familiar with the WebDAV standard as proposed in RFC 2518.  


  Problem/Task

    WebDAV, as an advanced application of HTTP and XML, supports an
    unlimited amount metadata to be associated with any resource. This, of
    course, is non-sense for Zope related applications and could potentially
    make Zope vulnerable to DoS attacks, since someone could try to add huge
    amounts of meta-data to a resource. A namespace registry was created that
    manages the list of all available namespaces per content type
    (interface). This recipe will show you how to enable a new namespace
    called 'photo' for an 'IImage' object.  


  Recipe

    
  Introduction


    As mentioned above, WebDAV's unlimited support for XML namespaces
    make WebDAV very powerful but also provide an easy target for malicous
    attacks if not properly controlled. Therefore we would like to control,
    an object's WebDAV namespaces as well as the permissions required to
    access and modify the the namespace's attributes. Furthermore, there was
    a desire to integrate the namespace data and handling into Zope 3 as much
    as possible, so that other components could easily reuse the information.

    First of all we noticed that namespaces with attributes are really
    just schemas, so that we were able to describe a namespace using the Zope
    3 'schema' package. Now we were even able to write WebDAV widgets
    for the schema field types. Adapters could be used to connect a namespace
    to a content type or any other object. Finally, we needed a way to tell
    WebDAV which schema would be available under WebDAV and what namespace
    name it would be associated with. This was solved by a simple registry,
    which mapped a schema to a namespace name and vice versa. If an adapter
    from a given object/resource to a registered schema is available, then
    the object is considered to be able to provide the associated namespace.

    If one wants to provide a new namespace for a given object, the main
    task for the developer consists of creating a schema for the namespace
    and to provide an adapter from the object to the schema. The goal of this
    recipe will be to provide some additional metadata information about
    images that have been taken by digital cameras - images that are photos.

    Let's start a new product. Create a new package called 'photodavns' 
    in '<ZOPE3>/src/zope' .

    
  Creating the Namespace Schema


    The schema of the photo should contain some information that are
    usually provided by the camera. To implement the schema, open a new file
    'interfaces.py' and add the following code.::

      01 from zope.interface import Interface
      02 from zope.schema import Text, TextLine, Int, Float
      04 photodavns = "http://namespaces.zope.org/dav/photo/1.0"
      06 class IPhoto(Interface):
      07     """A WebDAV namespace to store photo-related meta data.
      09     The 'IPhoto' schema/namespace can be used in WebDAV clients to determine
      10     information about a particular picture. Obviously, this namespace makes
      11     only sense on Image objects.
      12     """
      14     height = Int(
      15         title=u"Height",
      16         description=u"Specifies the height in pixels.",
      17         min=1)
      19     width = Int(
      20         title=u"Width",
      21         description=u"Specifies the width in pixels.",
      22         min=1)
      24     equivalent35mm = TextLine(
      25         title=u"35mm equivalent",
      26         description=u"The photo's size in 35mm is equivalent to this amount")
      28     aperture = TextLine(
      29         title=u"Aperture",
      30         description=u"Size of the aperture.")
      32     exposureTime = Float(
      33         title=u"Exposure Time",
      34         description=u"Specifies the exposure time in seconds.")

    o Line 4: The name of the namespace is also part of the interface,
      so declare it here. The name must be a valid URL, otherwise the
      configuration directive that registers the namespace will fail.  


    There is nothing more of interest in this code; at this time you
    should be very comfortable with interfaces and schemas. If not, please
    read the recipes on interfaces and schemas.

    
  Implementing the  'IPhoto' to  'IImage' Adapter


    Next we need to implement the adapter, which will use annotations to
    store the attribute data. That means that the 'IImage' object must
    also implement 'IAttributeAnnotable' . With the knowledge of the
    annotations recipe, the following implementation should seem simple.::

      01 from zope.interface import implements
      02 from persistence.dict import PersistentDict
      03 from zope.app import zapi
      04 from zope.app.interfaces.annotation import IAnnotations
      05 from zope.app.interfaces.content.image import IImage
      06 from zope.schema import getFieldNames
      07 from interfaces import IPhoto, photodavns
      09 class ImagePhotoNamespace(object):
      10     """Implement IPhoto namespace for IImage."""
      12     implements(IPhoto)
      13     __used_for__ = IImage
      15     def __init__(self, context):
      16         self.context = context
      17         self._annotations = zapi.getAdapter(context, IAnnotations)
      18         if not self._annotations.get(photodavns):
      19             self._annotations[photodavns] = PersistentDict()
      21     def __getattr__(self, name):
      22         if not name in getFieldNames(IPhoto):
      23             return super(ImagePhotoNamespace, self).__getattribute__(name)
      24         return self._annotations[photodavns].get(name, None)
      26     def __setattr__(self, name, value):
      27         if not name in getFieldNames(IPhoto):
      28             return super(ImagePhotoNamespace, self).__setattr__(name, value)
      29         field = IPhoto[name]
      30         field.validate(value)
      31         self._annotations[photodavns][name] = value

    o Line 15-19: During initialization, get the annotations for the 'IImage' 
      object and create a dictionary where all the attribute values will be
      stored. Make sure that the dictionary is a 'PersistentDict' 
      instance, since otherwise the data will not be stored permanently in
      the ZODB.

    o Line 21-24: If the name of the requested attribute corresponds
      to a field in 'IPhoto' then we get the value from the
      annotations otherwise use the usual way. Note that I had to use '_' 
      for the normal case, since 'object' does not provide '_' 
      publically.

    o Line 26-31: We want to set attributes differently, if they are
      fields in the 'IPhoto' schema. If the name is a field, then the
      first task is to get the field which is then used to validate the
      value. This way we can enforce all specifications provided for the
      fields in the schema. If the validation passes, then store the value in
      the annotations.  


    
  Unit-Testing and Configuration


    For the unit tests of the adapter, we use doc tests. So we extend
    the adapter's class doc string to become::

      01 """Implement IPhoto namespace for IImage.
      03 Examples::
      05   >>> from zope.app.content.image import Image
      06   >>> image = Image()
      07   >>> photo = zapi.getAdapter(image, IPhoto)
      09   >>> photo.height is None
      10   True
      11   >>> photo.height = 768
      12   >>> photo.height
      13   768
      14   >>> photo.height = u'100'
      15   Traceback (most recent call last):
      16   ...
      17   ValidationError: (u'Wrong type', u'100', (<type 'int'>, <type 'long'>))
      19   >>> photo.width is None
      20   True
      21   >>> photo.width = 1024
      22   >>> photo.width
      23   1024
      25   >>> photo.equivalent35mm is None
      26   True
      27   >>> photo.equivalent35mm = u'41 mm'
      28   >>> photo.equivalent35mm
      29   u'41 mm'
      31   >>> photo.aperture is None
      32   True
      33   >>> photo.aperture = u'f/2.8'
      34   >>> photo.aperture
      35   u'f/2.8'
      37   >>> photo.exposureTime is None
      38   True
      39   >>> photo.exposureTime = 0.031
      40   >>> photo.exposureTime
      41   0.031
      43   >>> photo.occasion
      44   Traceback (most recent call last):
      45   ...
      46   AttributeError: 'ImagePhotoNamespace' object has no attribute 'occasion'
      47 """

    You can see that the example code covers pretty much every possible
    situation.  

    o Line 5-7: Use the standard 'Image' content component as context
      for the adapter. Then we use the component architecture to get the
      adapter. This already tests whether the constructor - which is not
      trivial in this case - does not cause an exception.

    o Line 14-17: Test that the validation of the field's values works
      correctly.

    o Line 43-46: We also need to make sure that no non-existing
      attributes can be assigned a value.  


    To make the tests runnable, add a file named 'tests.py' and add the
    following test code.::

      01 import unittest
      02 from zope.app.tests import ztapi
      03 from zope.app.tests.placelesssetup import setUp, tearDown 
      04 from zope.app.attributeannotations import AttributeAnnotations
      05 from zope.app.content.image import Image
      06 from zope.app.interfaces.annotation import IAnnotations
      07 from zope.app.interfaces.annotation import IAttributeAnnotatable
      08 from zope.app.interfaces.content.image import IImage
      09 from zope.interface import classImplements
      10 from zope.products.photodavns.interfaces import IPhoto
      11 from zope.products.photodavns import ImagePhotoNamespace
      12 from zope.testing.doctestunit import DocTestSuite
      14 def customSetUp():
      15     setUp()
      16     ztapi.provideAdapter(IImage, IPhoto, ImagePhotoNamespace)
      17     ztapi.provideAdapter(IAttributeAnnotatable, IAnnotations,
      18                          AttributeAnnotations)
      19     classImplements(Image, IAttributeAnnotatable)
      21 def test_suite():
      22     return unittest.TestSuite((
      23         DocTestSuite('zope.products.photodavns', customSetUp, tearDown),
      24         ))
      26 if __name__ == '__main__':
      27     unittest.main(defaultTest='test_suite')

    o Line 14-19: We need to setup some additional adapters to make
      the tests work. First, of course, we need to register our adapter. Then
      we also need to provide the 'AttributeAdapter' , so that the 'ImagePhotoNamespace' 
      will find the annotations for the image. Finally, since 'Image' 
      does not implement 'IAttributeAnnotable' directly (it is usually
      done in a ZCML directive), we need to declare it manually here.

    o 21-24: The 'setUp()' and 'tearDown()' methods for a doc test can
      be passed as arguments to the 'DocTestSuite' constructor.  


    From the Zope 3 root directory, you can now execute the tests using::

      python test.py -vp zope.products.photodavns
        
  Functional Testing


    Now let's see our new namespace in action. Unfortunately, I am not
    aware of any WebDAV tools that can handle genericly any namespace. For
    this reason we will use functional tests for confirming the correct
    behavior.

    In the first step we will test whether 'PROPFIND' will (a)
    understand the namespace and (b) return the right values from the
    annotation of the image. Here is the complete code for the functional
    test, which you should place in a file called 'ftests.py' .::

      01 import unittest
      02 from transaction import get_transaction
      03 from xml.dom.minidom import parseString as parseXML
      04 from zope.app import zapi
      05 from zope.app.content.image import Image
      06 from zope.app.dav.ftests.dav import DAVTestCase
      07 from zope.component import getAdapter
      08 from zope.products.photodavns.interfaces import IPhoto
      09 from zope.products.photodavns import ImagePhotoNamespace
      11 property_request = '''\
      12 <?xml version="1.0" encoding="utf-8" ?>
      13 <propfind xmlns="DAV:">
      14   <prop xmlns:photo="http://namespaces.zope.org/dav/photo/1.0">
      15     <photo:height />
      16     <photo:width />
      17     <photo:equivalent35mm />
      18     <photo:aperture />
      19     <photo:exposureTime />
      20   </prop>
      21 </propfind>
      22 '''
      24 data = {'height': 768, 'width': 1024, 'equivalent35mm': u'41 mm',
      25         'aperture': u'f/2.8', 'exposureTime': 0.031}
      27 class IPhotoNamespaceTests(DAVTestCase):
      29     def createImage(self):
      30         img = Image()
      31         photo = ImagePhotoNamespace(img)
      32         for name, value in data.items():
      33             setattr(photo, name, value)
      34         root = self.getRootFolder()
      35         root['img.jpg'] = img
      36         get_transaction().commit()
      38     def test_propfind_fields(self):
      39         self.createImage()
      40         response = self.publish(
      41             '/img.jpg/',
      42             env={'REQUEST_METHOD':'PROPFIND',
      43                  'HTTP_Content_Type': 'text/xml'},
      44             request_body=property_request)
      45         self.assertEqual(response.getStatus(), 207)
      46         xml = parseXML(response.getBody())
      47         node = xml.documentElement.getElementsByTagName('prop')[0]
      49         for name, value in data.items():
      50             attr_node = node.getElementsByTagName(name)[0]
      51             self.assertEqual(attr_node.firstChild.data, unicode(value))
      53 def test_suite():
      54     return unittest.TestSuite((
      55         unittest.makeSuite(IPhotoNamespaceTests),
      56         ))
      58 if __name__ == '__main__':
      59     unittest.main(defaultTest='test_suite')

    o Line 11-22: This is the XML request that will be sent to the
      Zope 3 WebDAV server. Note that we need to make sure that The first
      line starts at the beginning of the string, since otherwise the XML
      parser causes a failure. In the string, we simply request explicitely
      all attributes of the 'photo' namespace.

    o Line 24-25: Here is the data that is being setup in the
      annotation and that we expect to receive from the 'PROPFIND' 
      request.

    o Line 29-36: This helper method creates an image and sets the
      photo data on the image, so that we can access it. Note that we have to
      commit a transaction at this point, otherwise the image will not be
      found in the ZODB.

    o 38-51: First we create the image so that it will be available.
      Then we just publish our request with a carefully constructed
      environment. To make the request a 'PROPFIND' call, you need to
      create a environment variable named 'REQUEST' . Since we send
      XML as the body of the request, we need to set the content type to
      "text/xml", which is done with a 'HTTP' environment entry.

      The answer we receive from the server should be 207, which
      signalizes that the 'PROPFIND' call was successful and the data
      is enclosed in the body. We then parse the XML body simply using
      Python's built-in 'xml.dom.minidom' package. The rest of the
      test code simply uses DOM to ensure that all of the requested
      attributes were returned and the data is correct.  


    Once you are done with the functional test, you can run it using the
    usual method::

      python test.py -vpf zope.products.photodavns
        The '-f' option executes only functional tests. Functional tests
    are recognized by their module name, which must be 'ftests' in
    comparison to 'tests' for regular unit tests.  


  Exercises

    - Exercise 1: Implement 'height' and 'width' in a way that it uses
      the 'IImage' 's 'getImageSize()' method to get the values.

    - Exercise 2: JPEG files support EXIF metadata tags that often
      already contain the data provided by the 'IPhoto' interface, so
      change the adapter in a way that it first tries to retrieve the data
      from the image before using annotation data. See 'http://topo.math.u-psud.fr/' 
      for a Python implementation of a EXIF tag retriever.  

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/UsingTALES

From Mailer-Daemon at python.org  Tue Feb 17 07:58:06 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Tue Feb 17 07:58:08 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1At4ne-0000Tz-JE@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1At4my-00007m-5E; Tue, 17 Feb 2004 07:57:24 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [LifeOfRequest] (new) first draft (generated from LaTeX file)
Message-ID: <20040217075724EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/LifeOfRequest/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/LifeOfRequest/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/LifeOfRequest>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Tue, 17 Feb 2004 07:57:24 -0500
X-Spam-Status: OK (default 0.000)

The Life of a Request

  Status

    IsDraft

  Authors

    StephanRichter

  Difficulty

    Contributor Level  

  Skills

    - You should be well-familiar with the Zope 3 framework.

    - Having a general idea of internet server design is also very
      helpful.  


  Problem/Task

    When developing Zope 3 applications, the coder is commonly dealing
    with the 'request' object to create views without thinking much
    about the details on how the request gets into the view and what happens
    with the response that is constructed in it. And this is fine, since it
    is often not necessary to know. But sometimes one needs to write a custom
    server or change the behavior of the publisher. In these cases it is good
    to know the general design of the Zope servers and publishers. This
    recipe takes you on the journey through the life of a request using the
    browser (special HTTP) request as an example.  


  Recipe

    
  What is a Request


    The term "request" appears often when talking about Zope 3. But what
    is a request? In technically concrete situations we usually refer to
    objects that implement 'IRequest' . These objects are responsible to
    embed protocol-specific details and represent the protocol semantics to
    provide them for usage by presentation components.

    It is not enough to only think of request objects. For me, anything
    that the client sends to the server after connection negotiations is
    considered a request. So on the very lowest level, when the user agent
    (in this case the classic Web browser) sends the HTTP string::

    GET /index.html HTTP/1.1
        it could be considered a request (raw) as well.

    
  Finding the Origin of the Request


    Now that we have an idea what the request is, let's take a more
    technical approach and find out how connections are handled technically
    and how a request is born in the midst of much redirection and many
    confusing abstraction layers.

    When a server starts up, it binds a socket to an address on the
    local machine 'bind(address)' ) and then starts to listen for
    connections by calling 'listen(backlog)' . When an incoming
    connection is detected, the 'accept()' method is called, which
    returns a connection object and the address of the computer to which the
    connection was made. All of this is part of the standard Python 'socket' 
    library and is documented in 'zope.server.interfaces.ISocket' 
    interface.

    The server, which is mainly an 'IDispatcher' implementation, has a
    simple interface to handle the specific events, by calling its
    corresponding 'handle' method. A complete list of all events that
    are managed this way is given in the 'IDisplatcherEventHandler' 
    interface. So when a connection comes in, 'handle' is called, which
    is overridden in the 'zope.server.serverbase.ServerBase' class
    around line 130. This method tries to get the connection by calling 'accept()' 
    (see previous paragraph). If the connection was successfully created, it
    is used to create a 'ServerChannel' , which is the next level of
    abstraction. Most of the other dispatcher functionality is provided by
    the standard 'async.dispatcher' , which fully implements 'IDispatcher' 
    .

    At this stage the channel is taking over, which is just another
    dispatcher. So the channel starts to collect the incoming data (see 'received(data)' 
    ) and sends it right away to the request parser, which is an instance of
    a class specified as 'parser' . Obviously, this class will be
    different for every server implementation. The way the parser functions
    is not that important. All we have to know is that it implements 'IStreamConsumer' 
    , which has a way of saying when it has completed parsing a request. Once
    all of the data is received, the 'IServerChannel' method 'receivedCompleteRequest(req)' 
    is called, whose goal is to schedule the request to be executed. But only
    one request of the channel can be running at a time. So if the cahnnel is
    busy, then we need to queue the request, until the running task is
    completed.

    Whenever the channel becomes available (see 'end' , the next request
    from the queue is taken and convered to an 'ITask' object. The task
    is then immediately sent to the server for execution using 'IServer.addTask(task)' 
    . There it is added to a task dispatcher (see 'ITaskDispatcher' ),
    which schedules the task for execution. But why all this redirection
    through a task and a task dispatcher? Until now, all the code ran on a
    single thread. But in order to scale the servers better and to support
    long-running requests without blocking the entire server, it is necessary
    to be able to start several threads to handle the requests. It is now up
    to the 'ITaskDispatcher' implementation to decide how to spread the
    requests. Theoretically, it could even consult other computers to execute
    a task. By default, we use the 'zope.server.taskthreads.ThreadedTaskDispatcher' 
    though. Using its 'setThreadCount(count)' method, the Zope startup
    code is able specify the maximum amount of threads running at a time.

    Once, it is the task's turn to be serviced, the task dispatcher
    calls 'ITask.service()' which should finally execute the request.
    Specifically, when the 'HTTPTask' is serviced, the method 'executeRequest(task)' 
    of the 'HTTPServer' is called. The 'zope.server.http.publisherhttpserver.PublisherHTTPServer' 
    , which is the one used for Zope 3, creates a 'IHTTPRequest' object
    from the task and publishes the request with 'zope.publisher.publish(request)' 
    . The server has an attribute 'request' in which the request class
    that is used to create the request is stored.

    So what did the system accomplish so far? We have taken an incoming
    connection, read all the incoming data and parsed it, scheduled it for
    execution and finally created a request that was published with the Zope
    3 publisher. Except for the last step, there was nothing Zope-specific
    about this code, so that all of this could be replaced by any other Web
    server, like Twisted.

    ** Diagram of interactions and sequence diagram. **

    
  The Request and the Publisher


    With the birth of the request and its start to walk the path of a
    request's life by entering the publisher using 'zope.publisher.publish.publish()' 
    , it also enters a Zope-pure domain. In fact, Zope does not really care
    how a request was created, as long as it implements 'IRequest' . For
    example, when functional tests are executed, they create the request
    purely from fictional data and pass it through the publisher to analyze
    the response afterwards.

    From a high-level point of view, the publisher's 'publish()' method
    is responsible of interpreting the request's information and case the
    correct actions. It starts out by traversing the given object path to an
    actual object, then call the desired method and finally writing the
    result in the response. Everything else in this method is about handling
    errors and exceptions as well as providing enough hooks for other
    components to step in.

    The 'publish()' method is so central to the entire Zope 3 framework,
    that we will now go through it very carefully trying to understand each
    step's purpose. Whereever necessary we will take a rest and examine side
    paths closer. It might be of advantage to open the 'zope.publisher.publish' 
    module at this point, so that it is easier to follow the text.

    The work of the 'publish()' method starts with a infinite
    while-loop. The first step inside the loop is to get the publication.

    The publication provides the publisher with hooks to accomplish
    application-specific tasks, related to data storages, transactions and
    security. The default implementation is 'DefaultPublication' , which
    is located in 'zope.publisher.base' and can be used by software that
    do not make use of the entire Zope framework. For Zope 3, however, there
    is a specific Zope implementation in 'zope.app.publication.zopepublication' 
    .

    Now, wrapped inside three 'try/except' statements, we tell the
    request to look at its data and process what every needs to be processed.
    In the case of a browser request, like the one we use as example, the 'processInputs()' 
    tries to parse all HTML form data that might have been sent by the
    browser and convert it to Python objects.

    The next step is to convert the request's object path to an object,
    a process known as traversal. Besides calling all the event-hooks, the
    first step of the traversal processs is to determine the application or,
    in other words, the object root. For a common Zope 3 installation, the
    application is of course the root of the ZODB. Then we use the request's
    'traverse(object)' method to get to the desired object. Let's have a
    closer look at this method for the 'BrowserRequest' .

    First of all we notice that the 'BrowserRequest' 's traverse method
    does not do any of the heavy lifting, but only covers a few
    browser-specific corner cases, like picking a default view and using the
    HTML form data (by inspecting form variable names for the suffix
    ":method") for possible additional traversal steps. It turns out that the
    'BaseRequest' 's traverse method does all the work. At the beginning
    of the method there are several private attributes that are being pulled
    into the local namespace and setup.

    -'publication' : It is simply the 'publication' object from
      before, which gives us access to the application-specific
      functionality.

    -'_' : A simple stack (i.e. list) of names that must be traversed.
      These names came from the parsed path of the URL. For example
      "/path/to/foo/bar/index.html" would be parsed to '['path', 'to', 'foo', 'bar', 'index.html]' 
      .

    -'_' : This is a list of names that have been already successfully
      traversed. The names are simply the entries coming from '_' .

    -'_' : This variable keeps track of the last object that was found
      in the traversal process.  


    Now we just work through the traversal stack until it has been
    completely emptied. The intersting call here is the 'publication.traverseName(request, object, name' 
    ) which tries to determine the next object using the name from the
    traversal stack and the request. The 'traverseName()' method can be
    very complex. The Zope 3 application version, found in 'zope.app.publication.publicationtraverse.PublicationTraverse' 
    , must be able to handle namespaces ("++namespace++"), views ("@@") and
    pluggable traverser lookups, so that objects can implement their own
    traversers. To discuss the details of this method be beyond the goal of
    this recipe.

    If everything goes well, and no exception was raised, meaning that
    the object specified in the path was found, the 'traverse()' method
    returns the found object and we are back in the publisher's 'publish()' 
    function. The next step is to execute the object.

    Calling the object assumes that the object is callable in the first
    place. Therefore, the traversal process should always end in a view or a
    method on a view. But since all common content objects have
    browser-specific default views, we are guaranteed that the object is
    callable. For other presentation types, similar default options exist.
    Even though the object is formally executed by calling 'publication.callObject(request, object)' 
    , eventually 'mapply()' is called, which is defined in the 'zope.publisher.publish' 
    module. 'mapply()' does not just call the object, but takes great
    care of determining the argument and finding values for them.

    When an object is called, it can either write the result directly to
    the request's response object or return a result object. In the latter
    case, the 'publish()' method adds the result to the body of the
    response. Here it is assumed that the result object is a unicode string.
    For the Zope application the 'afterCall(request)' execution is of
    importance, since it commits the transaction to the ZODB. This process
    can can cause a failure, so it is very important that we do not return
    any data to the server until the transaction is committed.

    When all this has successfully finished, we call 'outputBody()' on
    the response, which sends the data out to the world going through the
    tsak, channel and eventually through the socket to the connected machine.
    Note that the 'output(data)' method, which is called from 'outputBody' 
    , is responsible for converting the internally kept unicode strings to
    valid ASCII using an encoding. If no encoding was specified, "UTF-8" is
    used by default.

    Once the response has sent out its data, the request is closed by
    calling 'close()' on itself, which releases all locks on resources.
    This will also finish the running task, close the channel and eventually
    disconnect the socket. This marks the end of the request.

    Let's now look at some of the possible failure scenarios. The most
    common failure is a ZODB write conflict, in which case we simply want to
    rollback the transaction and retry the request again. But where does the
    'Retry' error come from, when the ZODB raises a 'ConflictError' ? A
    quick look in the publication's 'handleException()' method reveals,
    that if a write conflict error is detected, it is logged and afterwards a
    'Retry' exception is raised, so that the next exception handler is
    used. Here we simply reset the request and the response and allow the
    pulishing process to start all over again (remember, we have an
    everlasting while loop over all of this code).

    In general, though, exceptions are handled by the 'handleException()' 
    method, which logs the error and even allows them to be formatted in the
    appropriate output format using a view. See the recipe on "Changing
    Standard Exception Views" for details on how to define your own views on
    exceptions.

    ** Diagram of interactions and sequence diagram. **

    This concludes our journey through the life of a request. Sometimes
    I intentionally ignored details to stay focused and not confuse the
    reader. The interested reader will find that the interfaces of the
    various involved components serve well as further documentation,
    especially for the publisher.  

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/LifeOfRequest

From philipp at weitershausen.de  Tue Feb 17 08:08:38 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Tue Feb 17 08:02:01 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <200402170709.46424.srichter@cosmos.phy.tufts.edu>
References: <402F90E3.3040303@zope.com>
	<4031E922.9060706@zope.com>	<4031F6D0.60303@infrae.com>
	<200402170709.46424.srichter@cosmos.phy.tufts.edu>
Message-ID: <40321256.4000509@weitershausen.de>

Stephan Richter wrote:
> The reason we suggested folder and folder_web in the first place was to make 
> it easier to develop new UIs. And this in turn was born from the problem that 
> it was not easy for us to deactivate the browser ZCML in a package. 
> Therefore, I would really like to go back to
> 
> folder
> folder/browser

It is what we have now and we have said more than once that we don't 
like it, because:

a) It would making browser code optional harder. When you install 
'folder', you get the browser junk with it, no matter whether you want 
it or not.

b) It doesn't emphasize separation of application and browser code enough.

c) It does not flatten the hierarchy enough. We will end up with browser 
subpackages again.

What we really want is something like "separate but close". Being 
increasingly sceptical of my own suggestion, I think Jim's concept is 
the closest one to that doctrine, even though I still dislike the usage 
of the underscore and not being able to make proper use of Python 
namespaces. In that respect, I have great sympathy for Garret's and 
Roger's opinion. I draw a different conclusion, though.

> and provide a ZCML way of saying
> 
 > <disable>
 >   <include package="folder.browser" />
 > </disable>
> 
> This way, if you you develop a new UI you can just declare
> 
 > <disable>
 >   <include package="folder.browser" />
 > </disable>
 > <include package="srichter.folder.browser" />

I think that is not nearly as clear as simply adding or removing a line 
from products.zcml or whereever the numerous packages in zope.app will 
be configured from.

Where would this stanza of ZCML you're suggesting be? In the global 
config file (e.g. products.zcml)? Or in the 
srichter.folder/configure.zcml? Neither place looks "right"... :)

Philipp


From mgedmin at b4net.lt  Tue Feb 17 08:05:04 2004
From: mgedmin at b4net.lt (Marius Gedminas)
Date: Tue Feb 17 08:06:34 2004
Subject: [Zope3-dev] Separate presentation packages
In-Reply-To: <200402160645.02867.srichter@cosmos.phy.tufts.edu>
References: <402FA0DB.1030406@zope.com>
	<200402160645.02867.srichter@cosmos.phy.tufts.edu>
Message-ID: <20040217130504.GE32253@perlas>

On Mon, Feb 16, 2004 at 06:45:02AM -0500, Stephan Richter wrote:
> On Sunday 15 February 2004 11:39, Jim Fulton wrote:
> > So, I feel rather strongly that we should have packages like:
> >
> > folder
> > folder_browser
> > file
> > file_browser
> >
> > and so on. Note, again, that this separation is a good bit different
> > than what we have now. The presentation code is *close* to the application
> > code while still being separate.
> 
> Okay, the more I look at it, the more I like it. However, the underscore is 
> ugly and we should find a better notation/convention. I have no clue what 
> yet.

'folderbrowser' and 'filebrowser' look much more Pythonic to me than
'folder_browser' and 'file_browser'.  Underscores in package names feel
just too yucky for some reason.

Marius Gedminas
-- 
For Sale: Parachute.  Only used once, never opened, small stain.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20040217/f77e60ec/attachment.bin
From dominik.huber at projekt01.ch  Tue Feb 17 08:22:30 2004
From: dominik.huber at projekt01.ch (Dominik Huber)
Date: Tue Feb 17 08:24:40 2004
Subject: [Zope3-dev] Re: Separate presentation packages
Message-ID: <MLEHIMEMKLLFBGGPMEAHIEMPGLAA.dominik.huber@projekt01.ch>

Jim Fulton wrote:
>> - Browser and application packages are not in the same container 
>> package. That'll help to make the pluggability of presentation code 
>> quite clear.
>
>At the cost of too much distance. This is what we have now, and I
>think it's a disaster.

IMO the disaster originate from an ambiguous hierarchy. The code hierarchy isn't hierarchically layered into .core (model) and .browser (view) packages etc. like...

exp. package zope.app with module foo and subpackage/module bar.bar

zope.app.core.foo 
zope.app.core.bar.bar
zope.app.browser.foo 
zope.app.browser.bar.bar

... but it's more hierarchically shift-layered into . (model) and .browser (view) etc.:

zope.app.foo
zope.app.bar.bar
zope.app.browser.foo
zope.app.browser.bar.bar

Given the fact that we split up all our code in such a hierachically shift-layered way into a huge package (exp. zope.app), we end up in babel because we are mixing differnt kind of logical hierarchies on one physical context:

- thematical packages -> products (like dublincore, content)
- core packages
- presentation packages -> browser, xmplrpc, webdav
- ...

In one level of our *logical* hierarchy we don't provide a clear mental discriminator. That generates an extra portion of needless complexity (selection/decision). We have an additional mental navigation problem, too.

IMO an unambiguous (exp. hierarchacally layered) code hierarchy and attempt for smaller packages solves most of the disaster whitout abandon the adavantages of the logical established way of information encapsulation by dot's.

>Jim Fulton wrote:
>These is especially painful for people who don't use emacs. :)
>I just spent a week with a room full of vi users doing Zope 3
>coding.  They spend way too much time cd-ing,

IMO the physical navigation problem should we solve with better tool support and it's not legitimation for a crucial naming work-around ;)

>Jim Fulton wrote:
>Guido hates deep hierarchies.  I wouldn't normally go as far as he would,
>but I find that the experince with coming up with a package structure
>for Zope 3 tends to support his point of view.

There is only a problem with ambiguous hierarchies because of there missleading behavior (probability of decision selectivity -> babel effect).

regards,
dominik
From anthony at interlink.com.au  Tue Feb 17 08:36:40 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Tue Feb 17 08:39:37 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <4031E820.9000302@zope.com>
References: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>	<200402131703.07139.fred@zope.com>	<402D4DAF.10502@zope.com>	<200402131816.59402.fred@zope.com>	<1076969043.23662.42.camel@localhost.localdomain>
	<4031E820.9000302@zope.com>
Message-ID: <403218E8.5040104@interlink.com.au>

Jim Fulton wrote:
> 
> A major problem I have with distutils is that I have to write rather
> complex scripts to do somewhat simple things.  I don't
> necessarily have a problem with capturing this meta data in Python.

Ok, then, as a step forward - perhaps someone who's familiar with the
current Z3 setup.py could do a first cut of what their new setup.py
would look like, assuming the backend magically appears. This at least 
allows those of us with some knowledge of distutils innards (my eyes, my 
eyes!) to get an idea of what the solution might entail.

I'm not saying "come up with the perfect answer" but instead saying "if 
distutils was implemented in a way that your current needs were met, 
what would the setup.py say?"

I know, for instance, that in my perfect world, there wouldn't be little
dinky text files (or xml crud) required - this stuff _can_ be expressed 
in Python, and I'd prefer that it is.

Anthony

-- 
Anthony Baxter     <anthony@interlink.com.au>
It's never too late to have a happy childhood.

From philipp at weitershausen.de  Tue Feb 17 08:56:07 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Tue Feb 17 08:49:27 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <MLEHIMEMKLLFBGGPMEAHIEMPGLAA.dominik.huber@projekt01.ch>
References: <MLEHIMEMKLLFBGGPMEAHIEMPGLAA.dominik.huber@projekt01.ch>
Message-ID: <40321D77.5070803@weitershausen.de>

Dominik Huber wrote:
> Jim Fulton wrote:
> 
>>>- Browser and application packages are not in the same container 
>>>package. That'll help to make the pluggability of presentation code 
>>>quite clear.
>>
>>At the cost of too much distance. This is what we have now, and I
>>think it's a disaster.
> 
> IMO the disaster originate from an ambiguous hierarchy. The code
> hierarchy isn't hierarchically layered into .core (model) and .browser
> (view) packages etc. like...
> 
> exp. package zope.app with module foo and subpackage/module bar.bar
> 
> zope.app.core.foo 
> zope.app.core.bar.bar
> zope.app.browser.foo 
> zope.app.browser.bar.bar

It is not core vs. browser. 'core' is the wrong word. It is application 
  vs. presentation. Whether something is part of Zope core, optional, or 
somethine else, is not part of this discussion. We want packages to be 
able to change their status with respect to coreness or option.

Back to your hierarchy mockup:

- You are putting packages in a deeper hierarchy. That means:

   * The package hierarchy will not be flattened. Paths and import 
statements will be very long

   * In order to get from zope.app.core.foo to its browser package, you 
need to navigate a lot.

   Bottom line: It will be just as confusing as it is now

- I hope that we won't have packages such as 'zope.app.core.bar.bar', or 
even 'zope.app.bar.bar'. One more layer below zope.app should be enough 
in most cases. Exceptions are test packages which are hopefully being 
replaced by test modules where appropriate.

> Given the fact that we split up all our code in such a hierachically
> shift-layered way into a huge package (exp. zope.app), we end up in
> babel because we are mixing differnt kind of logical hierarchies on one
> physical context:
> 
> - thematical packages -> products (like dublincore, content)
> - core packages
> - presentation packages -> browser, xmplrpc, webdav
> - ...
> 
> In one level of our *logical* hierarchy we don't provide a clear
> mental discriminator. That generates an extra portion of needless
> complexity (selection/decision). We have an additional mental navigation
> problem, too.
> 
> IMO an unambiguous (exp. hierarchacally layered) code hierarchy and
> attempt for smaller packages solves most of the disaster whitout abandon
> the adavantages of the logical established way of information
> encapsulation by dot's.

I agree with you that hierarchy is a good way to solve ambiguity. I 
don't think that ambiguity is our main problem, if it is one at all. I'm 
not going to repeat our goals again. Jim has listed them at the 
beginning of the thread.

The bottom line is that we want application and presentation packages 
"separate but close". That cannot be solved by deep hierarchy. Since 
Python does not leave us with much else, a naming convention seems like 
the only solution. Believe me, I don't like underscores in package names 
either and I'd be happier if I knew a better solution.

>>Jim Fulton wrote:
>>These is especially painful for people who don't use emacs. :)
>>I just spent a week with a room full of vi users doing Zope 3
>>coding.  They spend way too much time cd-ing,
> 
> IMO the physical navigation problem should we solve with better tool
> support and it's not legitimation for a crucial naming work-around ;)

What do you mean with better tool support?

Philipp


From Mailer-Daemon at python.org  Tue Feb 17 08:57:57 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Tue Feb 17 08:57:59 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1At5jZ-0005wG-NX@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1At5iJ-0004ZB-OF; Tue, 17 Feb 2004 08:56:39 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [DevelCookbook] adjust table of content to the same I have for the TeX version
Message-ID: <20040217085639EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Tue, 17 Feb 2004 08:56:39 -0500
X-Spam-Status: OK (default 0.000)

++added:
       01. "Building and Storing Annotations":AnnotationsForMetaData -
           Since it is desirable to leave an object as untouched as possible,
           we developed a mechanism of attaching meta data to an object
           without the object knowing about it. (12 pages)


??changed:
-       06. Vocabularies and their Fields (VocabulariesAndFields) - Vocabularies 
       06. "Vocabularies and their Fields":VocabulariesAndFields - Vocabularies 

++added: 02. "Displaying User errors":DisplayUserErrors - For Zope 3,
Exceptions are simply objects, which can have Views that make them
representable on the output medium (usually the Browser). Every
Exception has a standard view, but for a professional Web site you
will need better screens. (3 pages)

++added:

       03. "Writing new ZCML Directives":NewZCMLDirectives - Discusses how new
           directives can be added to a ZCML namespace using meta-directives
           and/or how to create a new namespace from scratch. (5 pages)

??changed: - 03. Registering new WebDAV Namespaces
(NewWebDAVNamespace) - WebDAV is 04. "Changing Traversal
Behavior":ChangingTraversalBehavior - Similar to Zope 2, one can
change the object traversal (lookup) behavior for an object, except
that this functionality is much more flexible in Zope 3. (8 pages)

       03. "Registering new WebDAV Namespaces":NewWebDAVNamespace - WebDAV is

??changed: - WebDAV namespaces. (4 pages) - - 04. Using TALES outside
of Page Templates (UsingTALES) - TALES is a WebDAV namespaces. (9
pages)

       04. "Using TALES outside of Page Templates":UsingTALES - TALES is a

??changed: - TALES into your own properties and scripts. (3 pages)
TALES into your own properties and scripts. (5 pages)

++added: 05. Debugging Python and Zope Code (DebuggingPythonAndZope) -
This recipe teaches the reader how to interpret error messages and
tracebacks, and how to use the Zope Error Reporting service and the
Python debugger as well as an XML validator to detect bugs in ZCML and
page templates. (7 pages)


??changed:
-           it best descibes the approach of the new security model, which will
           it best describes the approach of the new security model, which will

??changed: - 07. The life of a Request (LifeOfRequest) - This recipe
will show the 07. "The life of a Request":LifeOfRequest - This recipe
will show the

??changed: - the debugger and the interactive Python prompt. (8 pages)
- the debugger and the interactive Python prompt. (6 pages)

--removed: - H. Things Good to Know - - This section contains
generally useful information. While the first - couple of recipes are
relatively easy, you might want to read them - right away, but other
recipes here will not make much sense until you - have read recipes in
the other sections of the book. - - 01. Using annotations to store
meta data (AnnotationsForMetaData) - - Since it is desirable to leave
an object as untouched as possible, - we developed a mechanism of
attaching meta data to an object - without the object knowing about
it. (3 pages) - - 02. "Displaying User errors":DisplayUserErrors - For
Zope 3, Exceptions - are simply objects, which can have Views that
make them - representable on the output medium (usually the Browser).
Every - Exception has a standard view, but for a professional Web site
you - will need better screens. (3 pages) - - 03. "Writing new ZCML
Directives":NewZCMLDirectives - Discusses how new -[14 more lines...]

??changed: - - Appendix B: API Reference - - I imagine this API
reference to be a little bit different to the ones the - Introspector
has to offer. While it is nice to see the methods of a - particular
interface and an interface hierarchy, it is by itself not very -
helpful. It is very important that also connections between all these
- interfaces' implementations are covered, which can be done by
documenting - all the adapters in the core. I would also like to
categorize the - interfaces in a more easily digestible manner and not
necessarily - following the directory hierarchy. (40 pages?) - - -
Credits Appendix B: Credits

??changed: - - - License Appendix C: Creative Commons License

??changed: - 1.0. The example code is maintained in the Zope CVS under
the 1.0.

  Appendix D: Zope Public License 2.0

    The example code is maintained in the Zope CVS under the

--removed: -

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook

From chrism at plope.com  Tue Feb 17 08:59:20 2004
From: chrism at plope.com (Chris McDonough)
Date: Tue Feb 17 08:59:29 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <4031F6D0.60303@infrae.com>
References: <402F90E3.3040303@zope.com> <c0rr12$2qa$1@sea.gmane.org>
	<4031E922.9060706@zope.com>  <4031F6D0.60303@infrae.com>
Message-ID: <1077026360.1886.10.camel@athlon>

On Tue, 2004-02-17 at 06:11, Martijn Faassen wrote:
> Jim Fulton wrote:
> 
> > I assume we can do an X3.0 release without solving the packaging 
> > problem, but I think we want this sooner rather than later.  My 
> > motivation for wanting to talk about this now is, in part that 
> > software layout debate. In particular, I don't want to use the CVS 
> > repository layout as my packaging tool.
> 
> 
> This is an important point: The CVS repository layout *is* the packaging 
> system *for developers*.

It needn't be.  I think it would be reasonable to ask developers to run
an install script just like end users.  Maybe in the case of developers
it creates symlinks instead of copying.



From Mailer-Daemon at python.org  Tue Feb 17 09:03:28 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Tue Feb 17 09:03:30 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1At5ou-0007bP-Bs@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1At5nx-0007Nm-Lb; Tue, 17 Feb 2004 09:02:29 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [NewPrincipalSourcePlugins] first draft (generated from LaTeX file)
Message-ID: <20040217090229EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NewPrincipalSourcePlugins/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NewPrincipalSourcePlugins/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NewPrincipalSourcePlugins>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Tue, 17 Feb 2004 09:02:29 -0500
X-Spam-Status: OK (default 0.000)

++added:
  

??changed: - IsWorkInProgress - mainly an outline - - Author IsDraft

  Authors

??changed: - Difficulty - - SprinterLevel - - Skills - - - Basic
understanding of the Zope 3 Component Architecture - - - Understand
the purpose and differences between permissions, roles and -
principals. - - - Basic knowledge about the Authentication Service.
Optional. Difficulty

    Sprinter Level  

  Skills

    - You should have a basic understanding of the Zope 3 component
      architecture.

    - It is necessary to understand the purpose and differences
      between permissions, roles and principals.

    - Basic knowledge about the Authentication Service. Optional.  


??changed:
-    Many systems provide their own mechanisms for authentication. Examples
-    include /etc/passwd, NIS, Radius and relational databases. For a generic
-    platform like Zope it is therefore critically necessary to provide
-    facilities to connect to these external authentication sources. 
        Many systems provide their own mechanisms for authentication.
    Examples include '/etc/passwd' , NIS, Radius and relational
    databases. For a generic platform like Zope it is critically necessary to
    provide facilities to connect to these external authentication sources.

??changed: - register it with the Authentication Service. register it
with the Authentication Service .


??changed:
-    - while one can become very fancy in implementing a feature-rich principal
-      source implementation, we are concentrating here on the most simple
-      case. The exercises point out many of the improvements that can be done
-      later.
-
-    - It will be our goal to create a file-based principal source, so that it
-      could read a /etc/passwd-like file (it will not be able to read passwd
-      files, since we do not know whether everyone has the crypt module
-      installed on her/his machine)
-
-    - therefore, component should be able to read and parse files of the
-      format (users are seperated by a newline character)::
-
-        login:password:title:other_stuff
-
-    - An 'IPrincipalSource' component promises to implement three simple
-      methods:
-
-      o getPrincipal(id) - This method gets a particular principal by its id,
-[388 more lines...]
    While one can become very fancy in implementing a feature-rich
    principal source implementation, we are concentrating on the most simple
    case here. The exercises point out many of the improvements that can be
    done during later development.

    The goal of this recipe is to create a file-based principal source,
    so that it could read a '/etc/passwd' -like file (it will not
    actually be able to read passwd files, since we do not know whether
    everyone has the 'crypt' module installed on her/his machine). The
    format of the file that we want to be able to read and parse is (users
    are seperated by a newline character)::

      login:password:title:other_stuff
        Let's now turn to the principal source. A component implementing
    'IPrincipalSource' promises to provide three simple methods:  

    -'getPrincipal(id)' - This method gets a particular principal by
      its id, which is unique for this particular source. If no principal
      with the supplied id is found, a 'NotFoundError' is raised.

    -'getPrincipals(name)' - This method returns a list of principals
      whose login somehow contain the substring specified in 'name' .
      If 'name' is an empty string, all principals of this source are
      returned.

    -'authenticate(login, password)' - This method is required by the
      'ILoginPasswordPrincipalSource' interface and provides
      authentication for the provided principal. There are other ways to
      implement authentication for these principals, but they add unnecessary
      complexity. 'None' is returned, if no match is made.  


    The next step is to provide an implementation of 'IPrincipalSource' 
    for password files. Create a new sub-package called 'passwdauth' in
    the 'zope.products.demo' package. Now the first step is to define
    the interfaces, as usual.

    
  Defining the interface


    "What interface do we need?", you might wonder. In order for a
    file-based principle source plugin to provide principals, we need to know
    the file that contains the data and knowing about this file is certainly
    part of the API for this plugin. So we want to create a specific
    interface that contains a filename. If we make this attribute a schema
    field, we can even use the interface/schema to create autogenerated add
    and edit forms.

    In the 'passwdauth' directory add a 'interfaces.py' file and add the
    following contents::

      01 from zope.schema import TextLine
      02 from zope.app.i18n import ZopeMessageIDFactory as _
      04 from zope.app.interfaces.services.pluggableauth import IPrincipalSource
      06 class IFileBasedPrincipalSource(IPrincipalSource):
      07     """Describes file-based principal sources."""
      09     filename = TextLine(
      10         title = _(u'File Name'),
      11         description=_(u'File name of the data file.'),
      12         default = u'/etc/passwd')

    o Line 1: Usual imports of the TextLine field for the filename
      property.

    o Line 2: This is the typical I18n boilerplate (not much though);
      all text strings wrapped by the underscore function will be
      internationalized, or in other terms localizable.

    o Line 4-5: Our file-based principal source is still of type 'IPrincipalSource' 
      , so let's make it the base interface.

    o Line 10-14: Typical internationalized text line field
      declaration, making '/etc/passwd' the default value (even though
      the product will not work with this file due to the crypt issue). You
      might want to add a different default, also based on the operating
      system you are on.  


    
  Writing the tests


    The next step is to write some unit tests that assure that the file
    parser does its job right. But first we need to develop a small data file
    with which we can test the plugin with. Create a file called 'passwd.sample' 
    and add the following two principal entries::

      01 foo1:bar1:Foo Bar 1
      02 foo2:bar2:Foo Bar 2

    Now we have a user with login 'foo1' and one known as 'foo2' ,
    having 'bar1' and 'bar2' as passwords, respectively.

    In the following test code We will only test the aforementioned
    three methods of the principal source. The file reading code is not
    seperately checked, sinde it will be well tested through the other tests.

    Create a 'tests.py' file and add the code below.::

      01 import os
      02 from zope.products.demo import passwdauth
      03 from zope.exceptions import NotFoundError
      04 from unittest import TestCase, TestSuite, main, makeSuite
      06 class PasswdPrincipalSourceTest(TestCase):
      08     def setUp(self):
      09         dir = os.path.split(passwdauth.__file__)[0]
      10         self.source = passwdauth.PasswdPrincipalSource(
      11             os.path.join(dir, 'passwd.sample'))
      13     def test_getPrincipal(self):
      14         self.assertEqual(self.source.getPrincipal('\t\tfoo1').password, 'bar1')
      15         self.assertEqual(self.source.getPrincipal('\t\tfoo2').password, 'bar2')
      16         self.assertRaises(NotFoundError, self.source.getPrincipal, '\t\tfoo')
      18     def test_getPrincipals(self):
      19         self.assertEqual(len(self.source.getPrincipals('foo')), 2)
      20         self.assertEqual(len(self.source.getPrincipals('')), 2)
      21         self.assertEqual(len(self.source.getPrincipals('2')), 1)
      23     def test_authenticate(self):
      24         self.assertEqual(self.source.authenticate('foo1', 'bar1').id, 'foo1')
      25         self.assertEqual(self.source.authenticate('foo1', 'bar'), None)
      26         self.assertEqual(self.source.authenticate('foo', 'bar'), None)
      28 def test_suite():
      29     return TestSuite((
      30         makeSuite(PasswdPrincipalSourceTest),
      31         ))
      33 if __name__=='__main__':
      34     main(defaultTest='test_suite')

    o Line 1, 2, 9-11: The reason we imported 'os' and the 'tests' 
      package itself, was to be able to get to the directory of the code as
      seen in line 9. Once we have the directory it is easy to build up the
      data file path and initialize the principal source (line 10-11).

    o Line 13-16: Test the 'getPrincipal(id)' method. The last test
      checks that the correct error is thrown in case of a failure.

    o Line 18-21: The test for 'getPrincipals(name)' mainly tests that
      the resulting user list is correctly filtered based on the 'name' 
      parameter value.

    o Line 23-26: The authentication test concentrates on checking
      that really only a valid login name and password pair receives a
      positive authentication by returning the principal object.

    o Line 28-34: This is the usual test boiler plate.  


    You can now run the tests either using Zope's 'test.py' test runner
    or by executing the script directly; the latter method requires the
    Python path to be set correctly to 'ZOPE3/src' .

    
  Implementing the plugin


    The implementation of the plugin should be straight forward and bear
    no surprises. The tests already express all the necessary semantics. We
    only have not discussed the data structure of the principal itself yet.
    For it we can reuse the 'SimplePrincipal' , which is a basic 'IUser' 
    implementation that contains all the data fields 'IUserSchemafied' )
    relevant to a principal: id, login (username), password, title and
    description.

    Note that in Zope 3 the principal knows absolutely nothing about its
    roles, permissions or anything else about security. This information is
    handled by other components of the system and is subject to policy
    settings. Now we are ready to realize the principal source. In the '_' 
    file of the 'passwdauth' package we add the following
    implementation::

      01 import os
      02 from persistence import Persistent
      03 from zope.app.container.contained import Contained
      04 from zope.app.interfaces.services.pluggableauth import \
      05      ILoginPasswordPrincipalSource
      06 from zope.app.location import locate
      07 from zope.app.services.pluggableauth import SimplePrincipal
      08 from zope.exceptions import NotFoundError
      09 from zope.interface import implements
      10 from interfaces import IFileBasedPrincipalSource
      12 class PasswdPrincipalSource(Contained, Persistent):
      13     """A Principal Source for /etc/passwd-like files."""
      15     implements(ILoginPasswordPrincipalSource, 
      16                IFileBasedPrincipalSource)
      18     def __init__(self, filename=''):
      19         self.filename = filename
      21     def readPrincipals(self):
      22         if not os.path.exists(self.filename):
      23             return []
      24         file = open(self.filename, 'r')
      25         principals = []
      26         for line in file.readlines():
      27             if line.strip() != '':
      28                 user_info = line.strip().split(':', 3)
      29                 p = SimplePrincipal(*user_info)
[226 more lines...]

??changed: - - Exercise 2: The current implementation requires the
passwords to be - plain text, which is of course a huge security risk.
Implement a version - of the plugin that can handle plain text,
crypt-based and SHA - passwords. Implement a setting in the user
interface that let's the user - select one of the encryption types. -
- - Exercise 3: Implement a version of the plugin that provides a
write - interface, i.e. you should be able to add, edit and delete -
Exercise 2: The current implementation requires the passwords to be
plain text, which is of course a huge security risk. Implement a
version of the plugin that can handle plain text, crypt-based and SHA
passwords. Implement a setting in the user interface that let's the
user select one of the encryption types.

    - Exercise 3: Implement a version of the plugin that provides a
      write interface, i.e. you should be able to add, edit and delete

??changed: - - Exercise 4: It is very limiting to require a special
file format for - the principal data. It would be useful to develop a
method that allows - the user to specify the file format. Implement
this feature and provide - an intuitive user interface for this
feature. (This is a tough one; feel - free to make some assumptions to
solve the problem.) - - - Exercise 5: Reading in the user data for
every single authentication - call is quiet expensive, so it would be
helpful to implement some - caching features. This can be done in two
ways: (1) Use the caching - framework to implement a cached version of
the source or (2) save the - list of principals in a volatile
attribute (i.e. _v_principals) and - check for every call whether the
file had been modified since the last - time it was read. - Exercise
4: It is very limiting to require a special file format for the
principal data. It would be useful to develop a method that allows the
user to specify the file format. Implement this feature and provide an
intuitive user interface for this feature. (This is a tough one; feel
free to make some assumptions to solve the problem.)

    - Exercise 5: Reading in the user data for every single
      authentication call is quiet expensive, so it would be helpful to
      implement some caching features. This can be done in two ways: (1) Use
      the caching framework to implement a cached version of the source or
      (2) save the list of principals in a volatile attribute (i.e. '_' 
      ) and check for every call whether the file had been modified since the
      last time it was read.  
--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NewPrincipalSourcePlugins

From Mailer-Daemon at python.org  Tue Feb 17 09:03:35 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Tue Feb 17 09:03:36 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1At5p1-0007cl-34@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris1.directnic.com [204.251.10.81]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1At5lW-0006xp-Jh; Tue, 17 Feb 2004 08:59:58 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [DevelCookbook] changed links and page numbers
Message-ID: <20040217085958EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Tue, 17 Feb 2004 08:59:58 -0500
X-Spam-Status: OK (default 0.001)

??changed:
-       01. Writing Basic Unit Tests (BasicUnitTests) - This recipe shows you
       01. "Writing Basic Unit Tests":BasicUnitTests - This recipe shows you

??changed: - 02. Doctests: Example-driven Unit Tests (DocTests) -
Sometimes regular 02. "Doctests: Example-driven Unit Tests":DocTests -
Sometimes regular

??changed: - (4 pages) - - 03. Writing Functional Tests
(FunctionalTests) - Unit tests are great (4 pages)

       03. "Writing Functional Tests":FunctionalTests - Unit tests are great

??changed: - that and expand on the motivation. (2 pages) that and
expand on the motivation. (7 pages)

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DevelCookbook

From Mailer-Daemon at python.org  Tue Feb 17 09:04:25 2004
From: Mailer-Daemon at python.org (Mail Delivery System)
Date: Tue Feb 17 09:04:27 2004
Subject: [Zope3-dev] Mail delivery failed: returning message to sender
Message-ID: <E1At5pp-00082x-N1@mail.python.org>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey@streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev@zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1At5p7-0007eh-Mv; Tue, 17 Feb 2004 09:03:41 -0500
From: zope3-dev@zope.org (srichter)
Reply-To: zope3-dev@zope.org
To: ;
Subject: [NewResource] first draft (generated from LaTeX file)
Message-ID: <20040217090340EST@dev.zope.org>
X-BeenThere: zope3-dev@zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev@zope.org>
List-Post: <mailto:zope3-dev@zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NewResource/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NewResource/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NewResource>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Tue, 17 Feb 2004 09:03:41 -0500
X-Spam-Status: OK (default 0.000)

??changed:
-Creating a new Browser Resource 
New Principal-Source Plugins
  

??changed: - IsWorkInProgress - outline only; - - Author IsDraft

  Authors

??changed: - Difficulty - - NewComerLevel - - Skills - - - Basic ZCML
knowledge Difficulty

    Sprinter Level  

  Skills

    - You should have a basic understanding of the Zope 3 component
      architecture.

    - It is necessary to understand the purpose and differences
      between permissions, roles and principals.

    - Basic knowledge about the Authentication Service. Optional.  


??changed:
-    Certain output, like images and style sheets are not associated with any
-    other component, so that using a View does not work. For this reason
-    Resources have been thought of, which will be introduced in this
-    mini-recipe. 
        Many systems provide their own mechanisms for authentication.
    Examples include '/etc/passwd' , NIS, Radius and relational
    databases. For a generic platform like Zope it is critically necessary to
    provide facilities to connect to these external authentication sources.

    Zope 3 provides an advanced Authentication Service that provides an
    interface to integrate any external authentication source by simply
    developing a simple plugin. In this recipe we create such a plugin and
    register it with the Authentication Service  .  


??changed:
-    - Goal: Register a file called resource.txt as a Browser Resource.
-
-    - Create a file 'resource.txt' containing:
-    
-      Hello, I am a Zope 3 Resource Component!
-
-    - Now simply register the resource using:
-
-      01 <browser:resource 
-      02     name="resource.txt" file="resource.txt" layer="default" />
-
-    - You should be able to access the resource now via a Browser using
-      "http://localhost:8080/@@/resource.txt"
-
-    - the '@@' in the URL tells the traversal mechanism that the following
-      object is a resource.
-
-    - If you have an image resource, you might want to use different
-      configuration
-[10 more lines...]
    While one can become very fancy in implementing a feature-rich
    principal source implementation, we are concentrating on the most simple
    case here. The exercises point out many of the improvements that can be
    done during later development.

    The goal of this recipe is to create a file-based principal source,
    so that it could read a '/etc/passwd' -like file (it will not
    actually be able to read passwd files, since we do not know whether
    everyone has the 'crypt' module installed on her/his machine). The
    format of the file that we want to be able to read and parse is (users
    are seperated by a newline character)::

      login:password:title:other_stuff
        Let's now turn to the principal source. A component implementing
    'IPrincipalSource' promises to provide three simple methods:  

    -'getPrincipal(id)' - This method gets a particular principal by
      its id, which is unique for this particular source. If no principal
      with the supplied id is found, a 'NotFoundError' is raised.

    -'getPrincipals(name)' - This method returns a list of principals
      whose login somehow contain the substring specified in 'name' .
      If 'name' is an empty string, all principals of this source are
      returned.

    -'authenticate(login, password)' - This method is required by the
      'ILoginPasswordPrincipalSource' interface and provides
      authentication for the provided principal. There are other ways to
      implement authentication for these principals, but they add unnecessary
      complexity. 'None' is returned, if no match is made.  


    The next step is to provide an implementation of 'IPrincipalSource' 
    for password files. Create a new sub-package called 'passwdauth' in
    the 'zope.products.demo' package. Now the first step is to define
    the interfaces, as usual.

    
  Defining the interface


    "What interface do we need?", you might wonder. In order for a
    file-based principle source plugin to provide principals, we need to know
    the file that contains the data and knowing about this file is certainly
    part of the API for this plugin. So we want to create a specific
    interface that contains a filename. If we make this attribute a schema
    field, we can even use the interface/schema to create autogenerated add
    and edit forms.

    In the 'passwdauth' directory add a 'interfaces.py' file and add the
    following contents::

      01 from zope.schema import TextLine
      02 from zope.app.i18n import ZopeMessageIDFactory as _
      04 from zope.app.interfaces.services.pluggableauth import IPrincipalSource
      06 class IFileBasedPrincipalSource(IPrincipalSource):
      07     """Describes file-based principal sources."""
      09     filename = TextLine(
      10         title = _(u'File Name'),
      11         description=_(u'File name of the data file.'),
      12         default = u'/etc/passwd')

    o Line 1: Usual imports of the TextLine field for the filename
      property.

    o Line 2: This is the typical I18n boilerplate (not much though);
      all text strings wrapped by the underscore function will be
      internationalized, or in other terms localizable.

    o Line 4-5: Our file-based principal source is still of type 'IPrincipalSource' 
      , so let's make it the base interface.

    o Line 10-14: Typical internationalized text line field
      declaration, making '/etc/passwd' the default value (even though
      the product will not work with this file due to the crypt issue). You
      might want to add a different default, also based on the operating
      system you are on.  


    
  Writing the tests


    The next step is to write some unit tests that assure that the file
    parser does its job right. But first we need to develop a small data file
    with which we can test the plugin with. Create a file called 'passwd.sample' 
    and add the following two principal entries::

      01 foo1:bar1:Foo Bar 1
      02 foo2:bar2:Foo Bar 2

    Now we have a user with login 'foo1' and one known as 'foo2' ,
    having 'bar1' and 'bar2' as passwords, respectively.

    In the following test code We will only test the aforementioned
    three methods of the principal source. The file reading code is not
    seperately checked, sinde it will be well tested through the other tests.

    Create a 'tests.py' file and add the code below.::

      01 import os
      02 from zope.products.demo import passwdauth
      03 from zope.exceptions import NotFoundError
      04 from unittest import TestCase, TestSuite, main, makeSuite
      06 class PasswdPrincipalSourceTest(TestCase):
      08     def setUp(self):
      09         dir = os.path.split(passwdauth.__file__)[0]
      10         self.source = passwdauth.PasswdPrincipalSource(
      11             os.path.join(dir, 'passwd.sample'))
      13     def test_getPrincipal(self):
      14         self.assertEqual(self.source.getPrincipal('\t\tfoo1').password, 'bar1')
      15         self.assertEqual(self.source.getPrincipal('\t\tfoo2').password, 'bar2')
      16         self.assertRaises(NotFoundError, self.source.getPrincipal, '\t\tfoo')
      18     def test_getPrincipals(self):
      19         self.assertEqual(len(self.source.getPrincipals('foo')), 2)
      20         self.assertEqual(len(self.source.getPrincipals('')), 2)
      21         self.assertEqual(len(self.source.getPrincipals('2')), 1)
      23     def test_authenticate(self):
      24         self.assertEqual(self.source.authenticate('foo1', 'bar1').id, 'foo1')
      25         self.assertEqual(self.source.authenticate('foo1', 'bar'), None)
      26         self.assertEqual(self.source.authenticate('foo', 'bar'), None)
      28 def test_suite():
      29     return TestSuite((
      30         makeSuite(PasswdPrincipalSourceTest),
      31         ))
      33 if __name__=='__main__':
      34     main(defaultTest='test_suite')

    o Line 1, 2, 9-11: The reason we imported 'os' and the 'tests' 
      package itself, was to be able to get to the directory of the code as
      seen in line 9. Once we have the directory it is easy to build up the
      data file path and initialize the principal source (line 10-11).

    o Line 13-16: Test the 'getPrincipal(id)' method. The last test
      checks that the correct error is thrown in case of a failure.

    o Line 18-21: The test for 'getPrincipals(name)' mainly tests that
      the resulting user list is correctly filtered based on the 'name' 
      parameter value.

    o Line 23-26: The authentication test concentrates on checking
      that really only a valid login name and password pair receives a
      positive authentication by returning the principal object.

    o Line 28-34: This is the usual test boiler plate.  


    You can now run the tests either using Zope's 'test.py' test runner
    or by executing the script directly; the latter method requires the
    Python path to be set correctly to 'ZOPE3/src' .

    
  Implementing the plugin


    The implementation of the plugin should be straight forward and bear
    no surprises. The tests already express all the necessary semantics. We
    only have not discussed the data structure of the principal itself yet.
    For it we can reuse the 'SimplePrincipal' , which is a basic 'IUser' 
    implementation that contains all the data fields 'IUserSchemafied' )
    relevant to a principal: id, login (username), password, title and
    description.

    Note that in Zope 3 the principal knows absolutely nothing about its
    roles, permissions or anything else about security. This information is
    handled by other components of the system and is subject to policy
    settings. Now we are ready to realize the principal source. In the '_' 
    file of the 'passwdauth' package we add the following
    implementation::

      01 import os
      02 from persistence import Persistent
      03 from zope.app.container.contained import Contained
      04 from zope.app.interfaces.services.pluggableauth import \
      05      ILoginPasswordPrincipalSource
      06 from zope.app.location import locate
      07 from zope.app.services.pluggableauth import SimplePrincipal
      08 from zope.exceptions import NotFoundError
      09 from zope.interface import implements
      10 from interfaces import IFileBasedPrincipalSource
      12 class PasswdPrincipalSource(Contained, Persistent):
      13     """A Principal Source for /etc/passwd-like files."""
      15     implements(ILoginPasswordPrincipalSource, 
      16                IFileBasedPrincipalSource)
      18     def __init__(self, filename=''):
      19         self.filename = filename
      21     def readPrincipals(self):
      22         if not os.path.exists(self.filename):
      23             return []
      24         file = open(self.filename, 'r')
      25         principals = []
      26         for line in file.readlines():
      27             if line.strip() != '':
      28                 user_info = line.strip().split(':', 3)
      29                 p = SimplePrincipal(*user_info)
[255 more lines...]

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/NewResource

From srichter at cosmos.phy.tufts.edu  Tue Feb 17 09:05:46 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Tue Feb 17 09:06:13 2004
Subject: [Zope3-dev] FYI: Mail delivery failed: ...
In-Reply-To: <E1At5ou-0007bP-Bs@mail.python.org>
References: <E1At5ou-0007bP-Bs@mail.python.org>
Message-ID: <200402170905.46044.srichter@cosmos.phy.tufts.edu>

On Tuesday 17 February 2004 09:03, Mail Delivery System wrote:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
> ? corey@streamreel.net
> ? ? SMTP error from remote mailer after RCPT TO:<corey@streamreel.net>:
> ? ? host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

I removed this E-mail address from the subscriber list.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From faassen at infrae.com  Tue Feb 17 09:23:56 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Tue Feb 17 09:23:07 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <4031FA32.9060301@weitershausen.de>
References: <402F90E3.3040303@zope.com>	<c0rr12$2qa$1@sea.gmane.org>	<4031E922.9060706@zope.com>	<4031F6D0.60303@infrae.com>
	<4031FA32.9060301@weitershausen.de>
Message-ID: <403223FC.7030104@infrae.com>

Philipp von Weitershausen wrote:

> Martijn Faassen wrote:
>
>> This is an important point: The CVS repository layout *is* the 
>> packaging system *for developers*.
>
> For developers of Zope3, not necessarily for 3rd party developers.
>
What ist he packaging system for 3rd party product developers then? For 
their own products, I mean.

>> So please realize that making foo_browser a standard means that if 
>> I'm an independent product developer, in my own repository away from 
>> Zope 3, I need to check out *two* modules to work on my package;
>
>
> Or apt-get install it... After all, you're not developing those 
> modules themselves but developing *with* them, right?

No, I'm an independent product developer and if I'm to follow the Zope 3 
standard and this standard is to use foo_browser, I need to make two 
modules in my version control system for each product I develop.

>> This will make tagging and branching a lot harder.
>
>
> I don't see why you would want to tag/branch Zope3 sources when not 
> developing Zope3 itself but your own repository stuff.
>
Apparently I was not clear enough about being an independent product 
developer, developing an extension to Zope 3 in my own repository.

Regards,

Martijn




From faassen at infrae.com  Tue Feb 17 09:25:23 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Tue Feb 17 09:24:14 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <200402170709.46424.srichter@cosmos.phy.tufts.edu>
References: <402F90E3.3040303@zope.com>
	<4031E922.9060706@zope.com>	<4031F6D0.60303@infrae.com>
	<200402170709.46424.srichter@cosmos.phy.tufts.edu>
Message-ID: <40322453.2000209@infrae.com>

Stephan Richter wrote:
[snip]

>This way, if you you develop a new UI you can just declare
>
><disable>
>  <include package="folder.browser" />
></disable>
><include package="srichter.folder.browser" />
>
>In my opinion this is much more sane than anything that we have discussed 
>concerning this branch of the debate.
>  
>
+1

This looks like a good idea.

Regards,

Martijn


From faassen at infrae.com  Tue Feb 17 09:27:29 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Tue Feb 17 09:26:45 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <40321256.4000509@weitershausen.de>
References: <402F90E3.3040303@zope.com>	<4031E922.9060706@zope.com>	<4031F6D0.60303@infrae.com>	<200402170709.46424.srichter@cosmos.phy.tufts.edu>
	<40321256.4000509@weitershausen.de>
Message-ID: <403224D1.4050000@infrae.com>

Philipp von Weitershausen wrote:

> Where would this stanza of ZCML you're suggesting be? In the global 
> config file (e.g. products.zcml)? Or in the 
> srichter.folder/configure.zcml? Neither place looks "right"... :)

I think it should be in the place where the overriding takes place. That 
way you don't burden people who compose a site together from products, 
only the developer who knows full well what he wants to do -- override 
the default.

Regards,

Martijn


From faassen at infrae.com  Tue Feb 17 09:30:04 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Tue Feb 17 09:28:50 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <1077026360.1886.10.camel@athlon>
References: <402F90E3.3040303@zope.com>
	<c0rr12$2qa$1@sea.gmane.org>	<4031E922.9060706@zope.com>
	<4031F6D0.60303@infrae.com> <1077026360.1886.10.camel@athlon>
Message-ID: <4032256C.10800@infrae.com>

Chris McDonough wrote:

>On Tue, 2004-02-17 at 06:11, Martijn Faassen wrote:
>
>This is an important point: The CVS repository layout *is* the packaging 
>system *for developers*.
>  
>
>
>It needn't be.  I think it would be reasonable to ask developers to run
>an install script just like end users.  Maybe in the case of developers
>it creates symlinks instead of copying.
>  
>
I must've been very unclear about the idea that you're developing a 
product yourself. Are we so focused on developing in the Zope 3 tree 
that we lost the concept of actually developing packages outside it? My 
point is that I don't want to have to create foo and foo_browser in my 
CVS repository if I'm creating the package 'foo'. In this scenario I 
have nothing to do with the Zope 3 core development.

It's not unnatural for me to want to run directly from my CVS checkout, 
and it's not unnatural that I want to branch and tag *everything* in it, 
including UI components, in one go. Or update it with a single cvs 
update, not in two separate modules.

Regards,

Martijn


From jeremy at zope.com  Tue Feb 17 09:28:27 2004
From: jeremy at zope.com (Jeremy Hylton)
Date: Tue Feb 17 09:31:54 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <4031E820.9000302@zope.com>
References: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<200402131703.07139.fred@zope.com> <402D4DAF.10502@zope.com>
	<200402131816.59402.fred@zope.com>
	<1076969043.23662.42.camel@localhost.localdomain>
	<4031E820.9000302@zope.com>
Message-ID: <1077028107.23662.687.camel@localhost.localdomain>

On Tue, 2004-02-17 at 05:08, Jim Fulton wrote:
> Somehow, Z3's setup.py is evidence of problems with distutils.
> I wish we had separate setup.py scripts for the separate major
> components of Zope 3, but somehow, this has been too hard. Instead,
> we have this rather complicated monolithic setup.py. Worse, we have
> three big monolithic setup.py scripts, for Zope 2, for Zope 3, and for
> ZODB that duplicate a good bit of code.
> 
> We should have separate setup.py scripts and a controller script that
> invokes the separate scripts.  It should, IMO, be possible for the central
> script to invoke the others as modules.  This doesn't seem to be possible,
> given the way things setup.py scripts are typically written.  It wouldn't
> be that big a deal to devise a different *style* of writing setup scripts
> so that they could be used by other setup scripts.

I'm in the minority, apparently, but I like having a single, top-level
setup script for ZODB.  It's a central point of control.  There's only
one place to look when a module isn't getting compiled or installed, and
there's a single list of all the software that should be installed.

The ZODB setup.py isn't all that big.  It's mostly just listings of
files, and it would be even smaller if distutils had better support for
data files.

Zope3 is a bit bigger -- it still feels small to me :-) -- because it
doesn't explicitly list packages (so there's Finder code) and because it
has a lot of C extensions.  Each C extension is only a few lines of
code, though, and mostly declarative at that.  It would be a little
smaller of distutils had built-in dependency support, which I've
threatened to add in the past.

At any rate, I think there's a lot of mileage to be had in building a
layer of on top of distutils to do what you want.

Jeremy



From chrism at plope.com  Tue Feb 17 09:40:19 2004
From: chrism at plope.com (Chris McDonough)
Date: Tue Feb 17 09:40:35 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <4032256C.10800@infrae.com>
References: <402F90E3.3040303@zope.com> <c0rr12$2qa$1@sea.gmane.org>
	<4031E922.9060706@zope.com> <4031F6D0.60303@infrae.com>
	<1077026360.1886.10.camel@athlon>  <4032256C.10800@infrae.com>
Message-ID: <1077028819.1886.26.camel@athlon>

On Tue, 2004-02-17 at 09:30, Martijn Faassen wrote:
> Chris McDonough wrote:

> I must've been very unclear about the idea that you're developing a 
> product yourself. Are we so focused on developing in the Zope 3 tree 
> that we lost the concept of actually developing packages outside it? My 
> point is that I don't want to have to create foo and foo_browser in my 
> CVS repository if I'm creating the package 'foo'. In this scenario I 
> have nothing to do with the Zope 3 core development.
> 
> It's not unnatural for me to want to run directly from my CVS checkout, 
> and it's not unnatural that I want to branch and tag *everything* in it, 
> including UI components, in one go. Or update it with a single cvs 
> update, not in two separate modules.

I don't think it matters whether we're talking about 3rd party packages
or core packages.  It's the same issue for all, AFAICT.

The browser and non-browser parts don't need to be separate modules
within your CVS repository.  Maybe you have a 'foo' CVS module that
contains a setup.py, a 'foo' Python package and a 'foo_browser' Python
package.  The setup.py script performs the necessary magic to put each
of the packages into a shared directory (and updates ZCML?  How the heck
is that going to work, btw? ;-).  The packages and the install script
can be versioned as one unit within CVS, but they become two packages
when installed.

As a convenience, developers might choose to flip the "symlink instead
of copy" flag on the setup script, which would symlink the source of
each package into the install directory instead of allowing distutils to
copy it.  That way you could retain the CVS bookkeeping info for each
package but work on it in the context of the install tree.

Make any sense?  The fact that we are constrained by the contents of CVS
representing the eventual install hiearchy is something that has
contributed to spaghetti dependencies within Zope 2, I'd hate to see the
same thing happen for Zope 3.

- C



- C



From tseaver at zope.com  Tue Feb 17 09:42:16 2004
From: tseaver at zope.com (Tres Seaver)
Date: Tue Feb 17 09:42:24 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <4031E411.9010401@zope.com>
References: <402FA0DB.1030406@zope.com>	<40309E4E.2040002@zope.com>	<40310768.4060809@infrae.com>	<200402161321.52738.srichter@cosmos.phy.tufts.edu>
	<4031E411.9010401@zope.com>
Message-ID: <40322848.7000207@zope.com>

Jim Fulton wrote:

> I don't agree. This was huge complaint about Z2.  It was a motivation
> for CMF skins.  People don't necessarily create multiple presentations
> for applications, but they often want to replace the presentation of
> products they get to make them consistent with their application
> presentations.

Actually, while the skins machinery of the CMF makes it *possible* to 
replace any arbitrary skin method from a third-party product, I would 
guess that, "in the wild", replacing a bit of content-specific skin is 
fairly rare:  such customizations are quite brittle against future 
changes to the product, and require a deeper knowledge of the component 
than many will want to have.  Plone 1, for instance, reused almost *all* 
of the "content" skins from CMFDefault.

The "common" replacements are for "global" skin methods (main_template 
and related stylesheets).

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com


From tseaver at zope.com  Tue Feb 17 09:54:34 2004
From: tseaver at zope.com (Tres Seaver)
Date: Tue Feb 17 09:54:39 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <713B58C7-60D5-11D8-88D8-000A95ABA188@commonground.com.au>
References: <402F90E3.3040303@zope.com>	<402FBC31.6040108@weitershausen.de>	<20040216095705.GB10775@vet.uu.nl>	<4030B1C0.4060005@weitershausen.de>	<4030B863.309@interlink.com.au>
	<4030EB9B.1030300@zope.com>
	<713B58C7-60D5-11D8-88D8-000A95ABA188@commonground.com.au>
Message-ID: <40322B2A.4060701@zope.com>

Richard Jones wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 17/02/2004, at 3:11 AM, Tres Seaver wrote:
> 
>> Anthony Baxter wrote:
>>
>>> Sorry, but this stuff is hard. The people who're trying to work on it 
>>> have to do this in their spare time - for instance, the current pypi 
>>> system.
>>
>>
>> Note that PyPI invested effort to add Trove metadata, which I would 
>> call "nice-to-have", and left out dependencies, which I would call 
>> "crucial".  I am not trivializing the effort required to add 
>> dependencies, either;  I just don't consider PyPI very useful without 
>> them.
> 
> 
> This is getting off-topic now, but I think it's important to reiterate 
> Anthony's comment. Send Code. Distutils and PyPI are open to further 
> development. Some people at some stage had some spare time to put in the 
> effort to get something implemented. In my case, I knew I had to 
> explicitly narrow the scope of PyPI or I'd never finish, and 
> dependencies didn't make the cut. I always intended that they be added 
> some time later. Possibly by myself, but most likely by someone else.

Believe me, I know *exactly* how that happens.  I was trying to point 
out that Zope3 needs more from distutils than it currently supports.

> Distutils and PyPI are open code.
> 
> If you think PyPI's currently "pathetic"

Just for clarity, I think I used "pathetic" to refer to distutils' 
handling of data files, not PyPI;  that handling is a "bolt-on," due 
largely to the fact that distributing large numbers of data files wasn't 
on anyone's mind when distutils' design was laid down.

> or not "very useful", then feel 
> free to fix it when you have the spare time. Otherwise, stop the 
> name-calling. It just makes those who have put in the effort feel like 
> shit.

I certainly didn't intend that;  my perspective on PyPI is that it has 
promise, but that I can't make effective use of it without dependencies. 
  The phrase "RPM hell" describes the feeling I get, looking at a 
package distribution system which lacks dependency management.

> I'll note that PyPI is actually quite popular though. So I guess it's 
> useful to some people.

Yes, I am sure that it is.

Please accept my apology for anything which came across as offensive.  I 
want very much for Python and Zope to have a fully-fledged package 
distribution framework, and I appreciate the work which the community 
has contributed so far toward that goal.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com

From tseaver at zope.com  Tue Feb 17 09:54:34 2004
From: tseaver at zope.com (Tres Seaver)
Date: Tue Feb 17 09:54:44 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <713B58C7-60D5-11D8-88D8-000A95ABA188@commonground.com.au>
References: <402F90E3.3040303@zope.com>	<402FBC31.6040108@weitershausen.de>	<20040216095705.GB10775@vet.uu.nl>	<4030B1C0.4060005@weitershausen.de>	<4030B863.309@interlink.com.au>
	<4030EB9B.1030300@zope.com>
	<713B58C7-60D5-11D8-88D8-000A95ABA188@commonground.com.au>
Message-ID: <40322B2A.4060701@zope.com>

Richard Jones wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 17/02/2004, at 3:11 AM, Tres Seaver wrote:
> 
>> Anthony Baxter wrote:
>>
>>> Sorry, but this stuff is hard. The people who're trying to work on it 
>>> have to do this in their spare time - for instance, the current pypi 
>>> system.
>>
>>
>> Note that PyPI invested effort to add Trove metadata, which I would 
>> call "nice-to-have", and left out dependencies, which I would call 
>> "crucial".  I am not trivializing the effort required to add 
>> dependencies, either;  I just don't consider PyPI very useful without 
>> them.
> 
> 
> This is getting off-topic now, but I think it's important to reiterate 
> Anthony's comment. Send Code. Distutils and PyPI are open to further 
> development. Some people at some stage had some spare time to put in the 
> effort to get something implemented. In my case, I knew I had to 
> explicitly narrow the scope of PyPI or I'd never finish, and 
> dependencies didn't make the cut. I always intended that they be added 
> some time later. Possibly by myself, but most likely by someone else.

Believe me, I know *exactly* how that happens.  I was trying to point 
out that Zope3 needs more from distutils than it currently supports.

> Distutils and PyPI are open code.
> 
> If you think PyPI's currently "pathetic"

Just for clarity, I think I used "pathetic" to refer to distutils' 
handling of data files, not PyPI;  that handling is a "bolt-on," due 
largely to the fact that distributing large numbers of data files wasn't 
on anyone's mind when distutils' design was laid down.

> or not "very useful", then feel 
> free to fix it when you have the spare time. Otherwise, stop the 
> name-calling. It just makes those who have put in the effort feel like 
> shit.

I certainly didn't intend that;  my perspective on PyPI is that it has 
promise, but that I can't make effective use of it without dependencies. 
  The phrase "RPM hell" describes the feeling I get, looking at a 
package distribution system which lacks dependency management.

> I'll note that PyPI is actually quite popular though. So I guess it's 
> useful to some people.

Yes, I am sure that it is.

Please accept my apology for anything which came across as offensive.  I 
want very much for Python and Zope to have a fully-fledged package 
distribution framework, and I appreciate the work which the community 
has contributed so far toward that goal.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com


From pje at telecommunity.com  Tue Feb 17 10:00:43 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue Feb 17 09:58:57 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <403218E8.5040104@interlink.com.au>
References: <4031E820.9000302@zope.com>
	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<200402131703.07139.fred@zope.com> <402D4DAF.10502@zope.com>
	<200402131816.59402.fred@zope.com>
	<1076969043.23662.42.camel@localhost.localdomain>
	<4031E820.9000302@zope.com>
Message-ID: <5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>

At 12:36 AM 2/18/04 +1100, Anthony Baxter wrote:
>Jim Fulton wrote:
>>A major problem I have with distutils is that I have to write rather
>>complex scripts to do somewhat simple things.  I don't
>>necessarily have a problem with capturing this meta data in Python.
>
>Ok, then, as a step forward - perhaps someone who's familiar with the
>current Z3 setup.py could do a first cut of what their new setup.py
>would look like, assuming the backend magically appears. This at least 
>allows those of us with some knowledge of distutils innards (my eyes, my 
>eyes!) to get an idea of what the solution might entail.
>
>I'm not saying "come up with the perfect answer" but instead saying "if 
>distutils was implemented in a way that your current needs were met, what 
>would the setup.py say?"

Speaking as another large package maintainer, I'd like setup.py to be 
either nonexistent, or automatically generated from something else that's 
modular.


>I know, for instance, that in my perfect world, there wouldn't be little
>dinky text files (or xml crud) required - this stuff _can_ be expressed in 
>Python, and I'd prefer that it is.

I'm certainly -1 on using XML for this, and I don't have a problem with 
using Python syntax.  But the single file approach has got to go.

The problem with putting everything in a setup.py is that it's not 
reusable.  Modularity is what's needed for large systems like Zope and 
PEAK.  For example, right now I bundle PyProtocols with the PEAK 
distribution.  This means that I have to maintain two setup.py files that 
cover some of the same stuff: one for the independent PyProtocols, and one 
for PEAK that contains PyProtocols setup info.  That's not too big a deal 
right now, but mainly what it does is discourage me from making other parts 
of PEAK separately distributable, because all the other parts are much 
harder to break out, and the dependencies between the parts change over time.

Yes, I know you can create a convention for separating the information into 
multiple files, using execfile or import.  But that convention's not a 
standard, so you can't really bundle somebody else's setup into your own to 
make a larger distribution.

So, if the solution here is to create such a convention, it needs to be 
PEPed so that folks will adopt it.  The existing 'setup.py' mechanism 
creates a tension that usually resolves in favor of distributing one 
mega-package instead of lots of little packages.  So communities that 
develop a lot of software (e.g. Zope, PEAK, Twisted, and others) tend to 
release those systems as humongous "sumo distributions", instead of 
thinking more modularly.  And they tend to duplicate effort because it's 
too bloody much trouble to distribute something from somebody else.

Please understand that I'm not bitching about distutils.  I *love* the 
distutils, because it's so much better than not having the distutils.  I'm 
in this conversation to find solutions to take things to the next 
level.  First, the modular assembly of packages so that people doing "sumo 
distributions" can break them up a little, and encourage people writing 
smaller packages to use an approach that will let their packages be bundled 
in larger packages.  (It'd be nice, for example, if you could run something 
like 'setup.py generate' and have an existing 'setup.py' spit out data for 
incorporation into a larger package, to make redistribution of "legacy" 
packages easier, and to make migration to the modular approach 
easier.)  Then, dependency information to automate assembly of 
already-present packages (e.g. slices of Zope or PEAK).

Anyway, I guess what I'm saying here is that the convention of using a 
monolithic setup.py encourages monolithic packaging, and discourages 
CPAN-style packaging.

It might seem I'm contradicting myself here, in that I'm advocating making 
*more* distributions, incorporating packages from multiple sources, which 
isn't the CPAN way either.  But it's a stepping stone.  Until we have a 
reliable CPAN-like mechanism to download and install dependencies, the gap 
will be filled by motivated packagers (like me and the Zope community) who 
want to provide their users with a single download for some targeted set of 
functionality.  And if it's *easy* to do, then other people will create 
bundles of the stuff they need in their environment, and maybe offer them 
for others to download.  So, it's a stopgap measure, but we have to evolve 
our way to CPAN, which means having survivable options at each point along 
the way, that are more functional than the previous step.


From pje at telecommunity.com  Tue Feb 17 10:04:41 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue Feb 17 10:02:56 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <1077028107.23662.687.camel@localhost.localdomain>
References: <4031E820.9000302@zope.com>
	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<200402131703.07139.fred@zope.com> <402D4DAF.10502@zope.com>
	<200402131816.59402.fred@zope.com>
	<1076969043.23662.42.camel@localhost.localdomain>
	<4031E820.9000302@zope.com>
Message-ID: <5.1.0.14.0.20040217100117.035d03e0@mail.telecommunity.com>

At 09:28 AM 2/17/04 -0500, Jeremy Hylton wrote:
>I'm in the minority, apparently, but I like having a single, top-level
>setup script for ZODB.  It's a central point of control.  There's only
>one place to look when a module isn't getting compiled or installed, and
>there's a single list of all the software that should be installed.

I agree with the DRY principle.  There should be only one authoritative 
source for a piece of information.

However, for larger systems, that principle isn't served by putting 
everything into one setup.py, any more than we put all our Python code into 
one big module.  We ought to be able to "import" the metadata from modular 
setup files.


From philipp at weitershausen.de  Tue Feb 17 10:17:22 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Tue Feb 17 10:10:52 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <1077028819.1886.26.camel@athlon>
References: <402F90E3.3040303@zope.com>
	<c0rr12$2qa$1@sea.gmane.org>	<4031E922.9060706@zope.com>
	<4031F6D0.60303@infrae.com>	<1077026360.1886.10.camel@athlon>
	<4032256C.10800@infrae.com> <1077028819.1886.26.camel@athlon>
Message-ID: <40323082.6000605@weitershausen.de>

Chris McDonough wrote:
> I don't think it matters whether we're talking about 3rd party packages
> or core packages.  It's the same issue for all, AFAICT.
> 
> The browser and non-browser parts don't need to be separate modules
> within your CVS repository.  Maybe you have a 'foo' CVS module that
> contains a setup.py, a 'foo' Python package and a 'foo_browser' Python
> package.  The setup.py script performs the necessary magic to put each
> of the packages into a shared directory (and updates ZCML?  How the heck
> is that going to work, btw? ;-).  The packages and the install script
> can be versioned as one unit within CVS, but they become two packages
> when installed.

So, I'll to run something like 'make' after every friggin' change of a 
.py file? I think it's bad enough having to restart Z3 all the time. 
Hey, we're all using Python for it's being an interpreted language. 
Please let's not have compile-like processes.

I think we're making the CVS issue bigger than it is. Martijn, you're 
likely to have

silva
silva.publication
silva.publication_browser
...

So, you'll just do::

   martijn@infrae:~/silva$ cvs tag SILVA_3_0_0 publication*

I don't think it's that much harder.

> As a convenience, developers might choose to flip the "symlink instead
> of copy" flag on the setup script, which would symlink the source of
> each package into the install directory instead of allowing distutils to
> copy it.  That way you could retain the CVS bookkeeping info for each
> package but work on it in the context of the install tree.
> 
> Make any sense?

A little. But I hate it :) Some kind of one-to-many-package mangling 
will confuse more than help and it's another point of possible failure, 
another thing to maintain etc. setup.py, as has been discussed lately, 
is hard to maintain, since it's monolithic, and don't even get me 
started on test.py! :)

> The fact that we are constrained by the contents of CVS representing
> the eventual install hiearchy is something that has contributed to
> spaghetti dependencies within Zope 2, I'd hate to see the same thing
> happen for Zope 3.

I think we're currently solving this kind of problem with repo-links, 
e.g. with ZConfig and the like. Don't see why we wouldn't want to 
continue this.

Philipp


From philipp at weitershausen.de  Tue Feb 17 10:22:31 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Tue Feb 17 10:15:48 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <40322848.7000207@zope.com>
References: <402FA0DB.1030406@zope.com>	<40309E4E.2040002@zope.com>	<40310768.4060809@infrae.com>	<200402161321.52738.srichter@cosmos.phy.tufts.edu>	<4031E411.9010401@zope.com>
	<40322848.7000207@zope.com>
Message-ID: <403231B7.7010401@weitershausen.de>

Tres Seaver wrote:
> Jim Fulton wrote:
> 
>> I don't agree. This was huge complaint about Z2.  It was a motivation
>> for CMF skins.  People don't necessarily create multiple presentations
>> for applications, but they often want to replace the presentation of
>> products they get to make them consistent with their application
>> presentations.
> 
> Actually, while the skins machinery of the CMF makes it *possible* to 
> replace any arbitrary skin method from a third-party product, I would 
> guess that, "in the wild", replacing a bit of content-specific skin is 
> fairly rare:  such customizations are quite brittle against future 
> changes to the product, and require a deeper knowledge of the component 
> than many will want to have.  Plone 1, for instance, reused almost *all* 
> of the "content" skins from CMFDefault.

Right. For content types, that is mostly true. However, let me point out 
that the Plone community right now is at the point where they regret 
ever having built on top of CMFDefault...

Anyway, Zope3 has much more presentation-ty stuff that can be 
customized. Adding views, custom widget views, etc. come to mind. I 
could easily find myself replacing almost a whole set of browser views 
for a content type...

> The "common" replacements are for "global" skin methods (main_template 
> and related stylesheets).

Yes, but those fall under a different category... We should call those 
skin packages now. I think rotterdam and zopetop should be their own 
package below zope.app or zope.products. You simply replace one of those 
and you have a new look-and-feel. These are the kinds of packages you 
are EXPECTED to replace. In fact, it might even make a lot of sense to 
mark those as *demo* packages...

Philipp


From jeremy at zope.com  Tue Feb 17 10:17:38 2004
From: jeremy at zope.com (Jeremy Hylton)
Date: Tue Feb 17 10:21:06 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <5.1.0.14.0.20040217100117.035d03e0@mail.telecommunity.com>
References: <4031E820.9000302@zope.com>
	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<200402131703.07139.fred@zope.com> <402D4DAF.10502@zope.com>
	<200402131816.59402.fred@zope.com>
	<1076969043.23662.42.camel@localhost.localdomain>
	<4031E820.9000302@zope.com>
	<5.1.0.14.0.20040217100117.035d03e0@mail.telecommunity.com>
Message-ID: <1077031057.23662.723.camel@localhost.localdomain>

On Tue, 2004-02-17 at 10:04, Phillip J. Eby wrote:
> At 09:28 AM 2/17/04 -0500, Jeremy Hylton wrote:
> >I'm in the minority, apparently, but I like having a single, top-level
> >setup script for ZODB.  It's a central point of control.  There's only
> >one place to look when a module isn't getting compiled or installed, and
> >there's a single list of all the software that should be installed.
> 
> I agree with the DRY principle.  There should be only one authoritative 
> source for a piece of information.
> 
> However, for larger systems, that principle isn't served by putting 
> everything into one setup.py, any more than we put all our Python code into 
> one big module.  We ought to be able to "import" the metadata from modular 
> setup files.

Indeed, there's a tradeoff between centralized configuration and
repeating the configuration information in more than one place.  If the
configuration is really simple, I don't mind repeating it, but we're
probably headed towards non-simple configuration.

One problem with a source tree is that it's hard to import things from
it.  If the distutils metadata is in some source directory, you need to
tell setup how to find it.  I don't particularly like a scheme that
grovels over whatever directories you tell it and find things, because
you don't have enough explicit control over what goes on.  It's also
hard to decide how to import something once its found.  Is it part of a
package?  Should it's containing directory be on the pythonpath?

Jeremy



From anthony at interlink.com.au  Tue Feb 17 10:31:44 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Tue Feb 17 10:32:20 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>
References: <4031E820.9000302@zope.com>
	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<200402131703.07139.fred@zope.com> <402D4DAF.10502@zope.com>
	<200402131816.59402.fred@zope.com>
	<1076969043.23662.42.camel@localhost.localdomain>
	<4031E820.9000302@zope.com>
	<5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>
Message-ID: <403233E0.2040401@interlink.com.au>

Phillip J. Eby wrote:
> The problem with putting everything in a setup.py is that it's not 
> reusable.  Modularity is what's needed for large systems like Zope and 
> PEAK.  For example, right now I bundle PyProtocols with the PEAK 
> distribution.  This means that I have to maintain two setup.py files 
> that cover some of the same stuff: one for the independent PyProtocols, 
> and one for PEAK that contains PyProtocols setup info.  That's not too 
> big a deal right now, but mainly what it does is discourage me from 
> making other parts of PEAK separately distributable, because all the 
> other parts are much harder to break out, and the dependencies between 
> the parts change over time.

Does there need to be some sort of additional distutils magic that, say,
walks through the __main__ module, looking for things that "look like"
setup declarations? That way, in your top level setup.py, you'd simply
say something like

from peak_setup import setup as PeakSetup
from frobozz_setup import setup as FrobozzSetup

... or something like that.

The current 'setup()' call might instead be replaced with creation of
instances of a DistutilsSetupClass, or something.

Anthony
-- 
Anthony Baxter     <anthony@interlink.com.au>
It's never too late to have a happy childhood.

From pje at telecommunity.com  Tue Feb 17 10:38:36 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue Feb 17 10:36:52 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <1077031057.23662.723.camel@localhost.localdomain>
References: <5.1.0.14.0.20040217100117.035d03e0@mail.telecommunity.com>
	<4031E820.9000302@zope.com>
	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<200402131703.07139.fred@zope.com> <402D4DAF.10502@zope.com>
	<200402131816.59402.fred@zope.com>
	<1076969043.23662.42.camel@localhost.localdomain>
	<4031E820.9000302@zope.com>
	<5.1.0.14.0.20040217100117.035d03e0@mail.telecommunity.com>
Message-ID: <5.1.0.14.0.20040217103247.02392a50@mail.telecommunity.com>

At 10:17 AM 2/17/04 -0500, Jeremy Hylton wrote:
>On Tue, 2004-02-17 at 10:04, Phillip J. Eby wrote:
> >
> > However, for larger systems, that principle isn't served by putting
> > everything into one setup.py, any more than we put all our Python code 
> into
> > one big module.  We ought to be able to "import" the metadata from modular
> > setup files.
>
>Indeed, there's a tradeoff between centralized configuration and
>repeating the configuration information in more than one place.  If the
>configuration is really simple, I don't mind repeating it, but we're
>probably headed towards non-simple configuration.
>
>One problem with a source tree is that it's hard to import things from
>it.  If the distutils metadata is in some source directory, you need to
>tell setup how to find it.  I don't particularly like a scheme that
>grovels over whatever directories you tell it and find things, because
>you don't have enough explicit control over what goes on.  It's also
>hard to decide how to import something once its found.  Is it part of a
>package?  Should it's containing directory be on the pythonpath?

That's why I said "import" in quotes, to imply "import-like mechanism".  :)

To answer the "how" question, I'd say that control should be explicit; 
either the main setup can explicitly "import" the metadata, or it can 
specify a target item whose dependencies are used to determine what should 
be imported.  Or, we can use the 'package.py' concept whereby you run a 
separate program to generate a setup.py based on a target.

Let's look at a more specific example.  The 'zope' package could contain a 
"setupinfo" that describes what directories under it are 
packages.  Packages with extensions would have setupinfo that describes how 
to build the extensions, and whether the package is dependent on anything 
else.  The top level setup then either says "Import" 'zope' (and therefore 
all its contents) or "import" 'zope.publisher' to package zope.publisher 
and its dependencies.


From tseaver at zope.com  Tue Feb 17 10:41:32 2004
From: tseaver at zope.com (Tres Seaver)
Date: Tue Feb 17 10:41:43 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>
References: <4031E820.9000302@zope.com>	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>	<200402131703.07139.fred@zope.com>
	<402D4DAF.10502@zope.com>	<200402131816.59402.fred@zope.com>	<1076969043.23662.42.camel@localhost.localdomain>	<4031E820.9000302@zope.com>
	<403218E8.5040104@interlink.com.au>
	<5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>
Message-ID: <4032362C.3060704@zope.com>

Phillip J. Eby wrote:
> At 12:36 AM 2/18/04 +1100, Anthony Baxter wrote:
> 
>> Jim Fulton wrote:
>>
>>> A major problem I have with distutils is that I have to write rather
>>> complex scripts to do somewhat simple things.  I don't
>>> necessarily have a problem with capturing this meta data in Python.
>>
>>
>> Ok, then, as a step forward - perhaps someone who's familiar with the
>> current Z3 setup.py could do a first cut of what their new setup.py
>> would look like, assuming the backend magically appears. This at least 
>> allows those of us with some knowledge of distutils innards (my eyes, 
>> my eyes!) to get an idea of what the solution might entail.
>>
>> I'm not saying "come up with the perfect answer" but instead saying 
>> "if distutils was implemented in a way that your current needs were 
>> met, what would the setup.py say?"
> 
> 
> Speaking as another large package maintainer, I'd like setup.py to be 
> either nonexistent, or automatically generated from something else 
> that's modular.

+1.  The configuration metadata in a typical setup.py can *never* be 
introspected, for intsance, short of writing bytecode hacks to pick 
apart the arguments passed to setup().

>> I know, for instance, that in my perfect world, there wouldn't be little
>> dinky text files (or xml crud) required - this stuff _can_ be 
>> expressed in Python, and I'd prefer that it is.
> 
> I'm certainly -1 on using XML for this, and I don't have a problem with 
> using Python syntax.  But the single file approach has got to go.

-1 for Python syntax;  Turing-completeness is a *disadvantage* in a 
configuration language (e.g., why is ZCML not in Python?  why ZConfig?)


WRT the format, I am agnostic about the spelling, but anti-NIH suggests 
that we should adopt a widely-supported parseable format:

   - ConfigParser style INI files (order can't matter, some restrictions
     on spelling section and key names).

   - An XML dialect of some sort (we should be looking to how Debian and
     RPM are spelling the XML variants of their package specification
     files).

> The problem with putting everything in a setup.py is that it's not 
> reusable.  Modularity is what's needed for large systems like Zope and 
> PEAK.  For example, right now I bundle PyProtocols with the PEAK 
> distribution.  This means that I have to maintain two setup.py files 
> that cover some of the same stuff: one for the independent PyProtocols, 
> and one for PEAK that contains PyProtocols setup info.  That's not too 
> big a deal right now, but mainly what it does is discourage me from 
> making other parts of PEAK separately distributable, because all the 
> other parts are much harder to break out, and the dependencies between 
> the parts change over time.
> 
> Yes, I know you can create a convention for separating the information 
> into multiple files, using execfile or import.  But that convention's 
> not a standard, so you can't really bundle somebody else's setup into 
> your own to make a larger distribution.
> 
> So, if the solution here is to create such a convention, it needs to be 
> PEPed so that folks will adopt it.

Or not.  The Python community has not always been amenable to adopting 
stuff which large-system folks find invaluable.


>  The existing 'setup.py' mechanism 
> creates a tension that usually resolves in favor of distributing one 
> mega-package instead of lots of little packages.  So communities that 
> develop a lot of software (e.g. Zope, PEAK, Twisted, and others) tend to 
> release those systems as humongous "sumo distributions", instead of 
> thinking more modularly.  And they tend to duplicate effort because it's 
> too bloody much trouble to distribute something from somebody else.
> 
> Please understand that I'm not bitching about distutils.  I *love* the 
> distutils, because it's so much better than not having the distutils.  
> I'm in this conversation to find solutions to take things to the next 
> level.  First, the modular assembly of packages so that people doing 
> "sumo distributions" can break them up a little, and encourage people 
> writing smaller packages to use an approach that will let their packages 
> be bundled in larger packages.  (It'd be nice, for example, if you could 
> run something like 'setup.py generate' and have an existing 'setup.py' 
> spit out data for incorporation into a larger package, to make 
> redistribution of "legacy" packages easier, and to make migration to the 
> modular approach easier.)  Then, dependency information to automate 
> assembly of already-present packages (e.g. slices of Zope or PEAK).
> 
> Anyway, I guess what I'm saying here is that the convention of using a 
> monolithic setup.py encourages monolithic packaging, and discourages 
> CPAN-style packaging.

Exactly.

> It might seem I'm contradicting myself here, in that I'm advocating 
> making *more* distributions, incorporating packages from multiple 
> sources, which isn't the CPAN way either.  But it's a stepping stone.  
> Until we have a reliable CPAN-like mechanism to download and install 
> dependencies, the gap will be filled by motivated packagers (like me and 
> the Zope community) who want to provide their users with a single 
> download for some targeted set of functionality.  And if it's *easy* to 
> do, then other people will create bundles of the stuff they need in 
> their environment, and maybe offer them for others to download.  So, 
> it's a stopgap measure, but we have to evolve our way to CPAN, which 
> means having survivable options at each point along the way, that are 
> more functional than the previous step.

Agreed.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com


From tseaver at zope.com  Tue Feb 17 10:41:32 2004
From: tseaver at zope.com (Tres Seaver)
Date: Tue Feb 17 10:41:46 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>
References: <4031E820.9000302@zope.com>	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>	<200402131703.07139.fred@zope.com>
	<402D4DAF.10502@zope.com>	<200402131816.59402.fred@zope.com>	<1076969043.23662.42.camel@localhost.localdomain>	<4031E820.9000302@zope.com>
	<403218E8.5040104@interlink.com.au>
	<5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>
Message-ID: <4032362C.3060704@zope.com>

Phillip J. Eby wrote:
> At 12:36 AM 2/18/04 +1100, Anthony Baxter wrote:
> 
>> Jim Fulton wrote:
>>
>>> A major problem I have with distutils is that I have to write rather
>>> complex scripts to do somewhat simple things.  I don't
>>> necessarily have a problem with capturing this meta data in Python.
>>
>>
>> Ok, then, as a step forward - perhaps someone who's familiar with the
>> current Z3 setup.py could do a first cut of what their new setup.py
>> would look like, assuming the backend magically appears. This at least 
>> allows those of us with some knowledge of distutils innards (my eyes, 
>> my eyes!) to get an idea of what the solution might entail.
>>
>> I'm not saying "come up with the perfect answer" but instead saying 
>> "if distutils was implemented in a way that your current needs were 
>> met, what would the setup.py say?"
> 
> 
> Speaking as another large package maintainer, I'd like setup.py to be 
> either nonexistent, or automatically generated from something else 
> that's modular.

+1.  The configuration metadata in a typical setup.py can *never* be 
introspected, for intsance, short of writing bytecode hacks to pick 
apart the arguments passed to setup().

>> I know, for instance, that in my perfect world, there wouldn't be little
>> dinky text files (or xml crud) required - this stuff _can_ be 
>> expressed in Python, and I'd prefer that it is.
> 
> I'm certainly -1 on using XML for this, and I don't have a problem with 
> using Python syntax.  But the single file approach has got to go.

-1 for Python syntax;  Turing-completeness is a *disadvantage* in a 
configuration language (e.g., why is ZCML not in Python?  why ZConfig?)


WRT the format, I am agnostic about the spelling, but anti-NIH suggests 
that we should adopt a widely-supported parseable format:

   - ConfigParser style INI files (order can't matter, some restrictions
     on spelling section and key names).

   - An XML dialect of some sort (we should be looking to how Debian and
     RPM are spelling the XML variants of their package specification
     files).

> The problem with putting everything in a setup.py is that it's not 
> reusable.  Modularity is what's needed for large systems like Zope and 
> PEAK.  For example, right now I bundle PyProtocols with the PEAK 
> distribution.  This means that I have to maintain two setup.py files 
> that cover some of the same stuff: one for the independent PyProtocols, 
> and one for PEAK that contains PyProtocols setup info.  That's not too 
> big a deal right now, but mainly what it does is discourage me from 
> making other parts of PEAK separately distributable, because all the 
> other parts are much harder to break out, and the dependencies between 
> the parts change over time.
> 
> Yes, I know you can create a convention for separating the information 
> into multiple files, using execfile or import.  But that convention's 
> not a standard, so you can't really bundle somebody else's setup into 
> your own to make a larger distribution.
> 
> So, if the solution here is to create such a convention, it needs to be 
> PEPed so that folks will adopt it.

Or not.  The Python community has not always been amenable to adopting 
stuff which large-system folks find invaluable.


>  The existing 'setup.py' mechanism 
> creates a tension that usually resolves in favor of distributing one 
> mega-package instead of lots of little packages.  So communities that 
> develop a lot of software (e.g. Zope, PEAK, Twisted, and others) tend to 
> release those systems as humongous "sumo distributions", instead of 
> thinking more modularly.  And they tend to duplicate effort because it's 
> too bloody much trouble to distribute something from somebody else.
> 
> Please understand that I'm not bitching about distutils.  I *love* the 
> distutils, because it's so much better than not having the distutils.  
> I'm in this conversation to find solutions to take things to the next 
> level.  First, the modular assembly of packages so that people doing 
> "sumo distributions" can break them up a little, and encourage people 
> writing smaller packages to use an approach that will let their packages 
> be bundled in larger packages.  (It'd be nice, for example, if you could 
> run something like 'setup.py generate' and have an existing 'setup.py' 
> spit out data for incorporation into a larger package, to make 
> redistribution of "legacy" packages easier, and to make migration to the 
> modular approach easier.)  Then, dependency information to automate 
> assembly of already-present packages (e.g. slices of Zope or PEAK).
> 
> Anyway, I guess what I'm saying here is that the convention of using a 
> monolithic setup.py encourages monolithic packaging, and discourages 
> CPAN-style packaging.

Exactly.

> It might seem I'm contradicting myself here, in that I'm advocating 
> making *more* distributions, incorporating packages from multiple 
> sources, which isn't the CPAN way either.  But it's a stepping stone.  
> Until we have a reliable CPAN-like mechanism to download and install 
> dependencies, the gap will be filled by motivated packagers (like me and 
> the Zope community) who want to provide their users with a single 
> download for some targeted set of functionality.  And if it's *easy* to 
> do, then other people will create bundles of the stuff they need in 
> their environment, and maybe offer them for others to download.  So, 
> it's a stopgap measure, but we have to evolve our way to CPAN, which 
> means having survivable options at each point along the way, that are 
> more functional than the previous step.

Agreed.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com

From chrism at plope.com  Tue Feb 17 11:06:59 2004
From: chrism at plope.com (Chris McDonough)
Date: Tue Feb 17 12:40:59 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <40323082.6000605@weitershausen.de>
References: <402F90E3.3040303@zope.com> <c0rr12$2qa$1@sea.gmane.org>
	<4031E922.9060706@zope.com> <4031F6D0.60303@infrae.com>
	<1077026360.1886.10.camel@athlon> <4032256C.10800@infrae.com>
	<1077028819.1886.26.camel@athlon> <40323082.6000605@weitershausen.de>
Message-ID: <1077034019.21652.18.camel@athlon>

On Tue, 2004-02-17 at 10:17, Philipp von Weitershausen wrote:
> So, I'll to run something like 'make' after every friggin' change of a 
> .py file? I think it's bad enough having to restart Z3 all the time. 
> Hey, we're all using Python for it's being an interpreted language. 
> Please let's not have compile-like processes.

This is why I suggested the symlink thing, FWIW.  You won't need to run
make after any change if packages are symlinked from source into the
install tree.  Windows people?  They lose.

> A little. But I hate it :) Some kind of one-to-many-package mangling 
> will confuse more than help and it's another point of possible failure, 
> another thing to maintain etc. setup.py, as has been discussed lately, 
> is hard to maintain, since it's monolithic, and don't even get me 
> started on test.py! :)

How is one setup script per package monolithic?

> I think we're currently solving this kind of problem with repo-links, 
> e.g. with ZConfig and the like. Don't see why we wouldn't want to 
> continue this.

Repolinks aside, the dogma of requring the CVS repository layout be the
same as the install layout prevents a lot of packaging flexibility;
namely, it prevents any possibility of having pure container directories
like I suggested in my last email.

Meanwhile, the cost of delegating more installation smarts to each
package is small if you're going to de-monolithicize the main setup.py
by adding smarts to each package anyway, as Jim is suggesting.

- C



From LBerezhny at DevIS.com  Tue Feb 17 11:12:28 2004
From: LBerezhny at DevIS.com (Lex Berezhny)
Date: Tue Feb 17 12:41:08 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <4031ECCF.1020104@zope.com>
References: <402FA0DB.1030406@zope.com> <c0rsve$5jr$1@sea.gmane.org>
	<4031ECCF.1020104@zope.com>
Message-ID: <1077034347.8519.5.camel@hortus>

On Tue, 2004-02-17 at 04:28, Jim Fulton wrote:
> Garrett Smith wrote:
> > I'd like to see modular functionality (hand waving) organized as follows:
> > 
> >   modfoo
> >   --------------------
> >   modfoo/interfaces.py
> >   modfoo/modfoo.py or modfoo/_modfoo.py
> >   modfoo/__init__.py + imports of modfoo.py/_modfoo.py (optional)
> 
> yes
> 
> >   modfoo/browser.py or modfoo/browser/ depending on UI complexity
> >   modfoo/*.py (other implementation modules)
> 
> plus:
> 
>     modfoo/*.pt (template modules)
>     modfoo/*.jpg (images)
>     configure.zcml
> 
> And I think that this provides less separation than we should have.

Why can't *.pt and *.jpg go into the browser directory? I have not
developed Zope3 products yet, but from looking in zope3 Products CVS I
can see that bugtracker has all of its *.pt files in the browser
directory.


From jim at zope.com  Tue Feb 17 11:27:26 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 17 12:41:20 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <1077028107.23662.687.camel@localhost.localdomain>
References: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>	<200402131703.07139.fred@zope.com>
	<402D4DAF.10502@zope.com>	<200402131816.59402.fred@zope.com>	<1076969043.23662.42.camel@localhost.localdomain>	<4031E820.9000302@zope.com>
	<1077028107.23662.687.camel@localhost.localdomain>
Message-ID: <403240EE.3010201@zope.com>

Jeremy Hylton wrote:
> On Tue, 2004-02-17 at 05:08, Jim Fulton wrote:
> 
>>Somehow, Z3's setup.py is evidence of problems with distutils.
>>I wish we had separate setup.py scripts for the separate major
>>components of Zope 3, but somehow, this has been too hard. Instead,
>>we have this rather complicated monolithic setup.py. Worse, we have
>>three big monolithic setup.py scripts, for Zope 2, for Zope 3, and for
>>ZODB that duplicate a good bit of code.
>>
>>We should have separate setup.py scripts and a controller script that
>>invokes the separate scripts.  It should, IMO, be possible for the central
>>script to invoke the others as modules.  This doesn't seem to be possible,
>>given the way things setup.py scripts are typically written.  It wouldn't
>>be that big a deal to devise a different *style* of writing setup scripts
>>so that they could be used by other setup scripts.
> 
> 
> I'm in the minority, apparently,

I hope so. :)

 > but I like having a single, top-level
> setup script for ZODB.  It's a central point of control. 

It's probably OK for ZODB, but I think it really sucks for Zope.

 > There's only
> one place to look when a module isn't getting compiled or installed, and
> there's a single list of all the software that should be installed.
> 
> The ZODB setup.py isn't all that big. 

I find it big and complex.

 > It's mostly just listings of
> files, and it would be even smaller if distutils had better support for
> data files.
> 
> Zope3 is a bit bigger -- it still feels small to me :-) -- because it
> doesn't explicitly list packages (so there's Finder code) and because it
> has a lot of C extensions.  Each C extension is only a few lines of
> code, though, and mostly declarative at that.  It would be a little
> smaller of distutils had built-in dependency support, which I've
> threatened to add in the past.

I find it pretty complex.  I was annoyed that I had to change it and ZODB's
when working on ZODB 3.3 integration.

> At any rate, I think there's a lot of mileage to be had in building a
> layer of on top of distutils to do what you want.

Of course.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Tue Feb 17 11:42:53 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 17 13:15:24 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <1077026360.1886.10.camel@athlon>
References: <402F90E3.3040303@zope.com>
	<c0rr12$2qa$1@sea.gmane.org>	<4031E922.9060706@zope.com>
	<4031F6D0.60303@infrae.com> <1077026360.1886.10.camel@athlon>
Message-ID: <4032448D.2060207@zope.com>

Chris McDonough wrote:
> On Tue, 2004-02-17 at 06:11, Martijn Faassen wrote:
> 
>>Jim Fulton wrote:
>>
>>
>>>I assume we can do an X3.0 release without solving the packaging 
>>>problem, but I think we want this sooner rather than later.  My 
>>>motivation for wanting to talk about this now is, in part that 
>>>software layout debate. In particular, I don't want to use the CVS 
>>>repository layout as my packaging tool.
>>
>>
>>This is an important point: The CVS repository layout *is* the packaging 
>>system *for developers*.
> 
> 
> It needn't be.  I think it would be reasonable to ask developers to run
> an install script just like end users. 

I don't.  This is not an option. Sorry. :)


 > Maybe in the case of developers
> it creates symlinks instead of copying.

Symlinks don't really solve the problem. Think of adding and removing
files.

No, as I stated in my preproposal notes, it must be possible to
run from a CVS checkout.


In a later note, you wrote:

 > The fact that we are constrained by the contents of CVS
 > representing the eventual install hiearchy is something that has
 > contributed to spaghetti dependencies within Zope 2, I'd hate to see the
 > same thing happen for Zope 3.

Don't worry.  One of the main points of the discussion is to
avoid having the CVS repository constrained by distributions.  Distributions
need not (and probably won't) look anything like the repository.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Tue Feb 17 11:45:23 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 17 13:15:29 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <40322453.2000209@infrae.com>
References: <402F90E3.3040303@zope.com>
	<4031E922.9060706@zope.com>	<4031F6D0.60303@infrae.com>
	<200402170709.46424.srichter@cosmos.phy.tufts.edu>
	<40322453.2000209@infrae.com>
Message-ID: <40324523.8070003@zope.com>

Martijn Faassen wrote:
> Stephan Richter wrote:
> [snip]
> 
>> This way, if you you develop a new UI you can just declare
>>
>> <disable>
>>  <include package="folder.browser" />
>> </disable>
>> <include package="srichter.folder.browser" />
>>
>> In my opinion this is much more sane than anything that we have 
>> discussed concerning this branch of the debate.
>>  
>>
> +1
> 
> This looks like a good idea.


Yup. In fact, it was proposed some time ago:

   http://dev.zope.org/Zope3/ZCMLEnhancements

It's on the todo list, although probably after X3.0.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From shane at zope.com  Tue Feb 17 11:57:23 2004
From: shane at zope.com (Shane Hathaway)
Date: Tue Feb 17 13:15:50 2004
Subject: [Zope3-dev] Security: Permissions to use software (?)
In-Reply-To: <402FB604.5030902@zope.com>
References: <402FB604.5030902@zope.com>
Message-ID: <Pine.LNX.4.50.0402171152250.8918-100000@shane.zope.com>

On Sun, 15 Feb 2004, Jim Fulton wrote:

> In general then, utilities, modules, factories, etc. should not
> require permissions to use them. An exception is software used to
> access system resources (e.g. databases or files).  This means that
> access to factories and most utilities should be unconditionally
> allowed, by specifying zope.Public as the required permission.
> Likewise for module attributes that only perform computation.

We're finding the same pattern in CMF.  We've had good success with it.

+1

Shane

From jim at zope.com  Tue Feb 17 12:09:14 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 17 13:15:58 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <1077036821.21647.44.camel@athlon>
References: <402F90E3.3040303@zope.com> <c0rr12$2qa$1@sea.gmane.org>	
	<4031E922.9060706@zope.com> <4031F6D0.60303@infrae.com>	
	<1077026360.1886.10.camel@athlon> <4032448D.2060207@zope.com>
	<1077036821.21647.44.camel@athlon>
Message-ID: <40324ABA.5000500@zope.com>

Chris McDonough wrote:
> On Tue, 2004-02-17 at 11:42, Jim Fulton wrote:
> 
>>>It needn't be.  I think it would be reasonable to ask developers to run
>>>an install script just like end users. 
>>
>>I don't.  This is not an option. Sorry. :)
> 
> 
> I know you're not *really* sorry, but that's OK. ;-)

No, I really am. :)

>> > Maybe in the case of developers
>>
>>>it creates symlinks instead of copying.
>>
>>Symlinks don't really solve the problem. Think of adding and removing
>>files.
> 
> 
> The installer would symlink packages (directories), not individual
> files.

OK, think of adding and removing directories.

> 
>>No, as I stated in my preproposal notes, it must be possible to
>>run from a CVS checkout.
> 
> 
> I don't know why, except for inertia.  This is a complete
> non-requirement from my perspective, for any Python software. 


That's fine.

 From my perspective it is a huge requirement.

Note that I must not be the only one.  Python itself
can be run from a CVS checkout.

 > If Zope 3
> is really at some level a collection of more-or-less independent Python
> packages, it should be possible to treat it as such by rearranging the
> packages in their respective source versions and letting an installer
> take care of placing them in the right directories at install time.  CVS
> should not be responsible for this.

I agree 100%.  But I still insist on the convenience of not having
to run an installtion script, much less rerun one every time I
do a cvs up.

> 
>>Don't worry.  One of the main points of the discussion is to
>>avoid having the CVS repository constrained by distributions.  Distributions
>>need not (and probably won't) look anything like the repository.
> 
> 
> I suspect that's backwards.   If a CVS checkout must be runnable
> in-place, there will be likely be little need or desire to package for
> distribution differently than as one big checkout turd,

Yes there will be,  Distributions will often contain different things than
what's in the repository. There will be experimental things in the repository
that don't make it in to distributions. Similarly, people will create distributions
that contain additional software that's not in the repository.


 > which is fine,

no

> and is the strategy that Zope 2 takes, it's just not what I thought Zope
> 3 wanted to be about.

It it's not what we are going to do.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From garrett at mojave-corp.com  Tue Feb 17 12:14:20 2004
From: garrett at mojave-corp.com (Garrett Smith)
Date: Tue Feb 17 13:16:01 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <4031ECCF.1020104@zope.com>
References: <402FA0DB.1030406@zope.com> <c0rsve$5jr$1@sea.gmane.org>
	<4031ECCF.1020104@zope.com>
Message-ID: <c0thtt$k7s$1@sea.gmane.org>

Jim Fulton wrote:

> plus:
> 
>    modfoo/*.pt (template modules)
>    modfoo/*.jpg (images)
>    configure.zcml
> 
> And I think that this provides less separation than we should have.

Per the nontrivial UI clause, these files should go into the browser 
package:

   modfoo/browser/*.pt
   modfoo/browser/*.jpg
   modfoo/browser/configure.zcml

> People who *just* want to focus on presentation need to sort it
> out from the other code.  People who just want the application code
> have all this extra browser code.
> Jim
> 

I think there's agreement on the separation of presentation logic from 
interfaces and implementations.

I've seen three salient arguments for modfoo_browser:

1 - Flattens the package hierarchy

2 - Gives developers/users more flexibility in 'getting' 'stuff' (i.e. 
when you 'get' modfoo, you don't automatically 'get' the browser code)

3 - Makes it easier to plug in new UI

Re flattening, I'm in the "deep hierarchies bad" camp. But using 
underscores to flatten goes too far. As I pointed out before, this 
argument could be applied to flatten everything. Seriously, we'd only do 
this if there was a really, really compelling reason, no?

Re the second point, I think we're confusing package structure with 
software distribution. The term 'get' is loaded (thus quoted) - what you 
'get' depends on what's been packaged and for whom.

If someone wants to package their modfoo to decouple the UI from the 
core, create two packages (RPM, source dist, etc.).

But we're talking about CVS here. As Jim pointed out, CVS should not be 
the packaging/distribution mechanism. But the modfoo_browser proposal 
does exactly that, per argument two above.

Re argument 3, I'm still not getting it. I've plugged in ooodles of new 
UI over existing Zope 3 application logic/content using skins. If I 
wanted to totally replace the existing Zope 3 UI, I'd create my own 
distribution that didn't ship/use the 'browser' packages. I'm looking at 
the same exact options with 'modfoo_browser', am I not?

  -- Garrett



From philipp at weitershausen.de  Tue Feb 17 12:19:52 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Tue Feb 17 13:16:15 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <1077034019.21652.18.camel@athlon>
References: <402F90E3.3040303@zope.com> <c0rr12$2qa$1@sea.gmane.org>	
	<4031E922.9060706@zope.com> <4031F6D0.60303@infrae.com>	
	<1077026360.1886.10.camel@athlon> <4032256C.10800@infrae.com>	
	<1077028819.1886.26.camel@athlon>
	<40323082.6000605@weitershausen.de>
	<1077034019.21652.18.camel@athlon>
Message-ID: <40324D38.9020808@weitershausen.de>

Chris McDonough wrote:
> On Tue, 2004-02-17 at 10:17, Philipp von Weitershausen wrote:
> 
>>So, I'll to run something like 'make' after every friggin' change of a 
>>.py file? I think it's bad enough having to restart Z3 all the time. 
>>Hey, we're all using Python for it's being an interpreted language. 
>>Please let's not have compile-like processes.
> 
> This is why I suggested the symlink thing, FWIW.  You won't need to run
> make after any change if packages are symlinked from source into the
> install tree.  Windows people?  They lose.

For example Windows people lose. Also, when you add new files, rename 
them, refactor etc., you do not only have to make sure you get it right 
in the revision control system, now you also have a symlink tree to take 
care of...

>>A little. But I hate it :) Some kind of one-to-many-package mangling 
>>will confuse more than help and it's another point of possible failure, 
>>another thing to maintain etc. setup.py, as has been discussed lately, 
>>is hard to maintain, since it's monolithic, and don't even get me 
>>started on test.py! :)
> 
> How is one setup script per package monolithic?

It's not. You must have misunderstood me. I too want a setup file for 
each package. Though I dislike them being python scripts, but I could 
even live with that. I guess they would just contain a lot of 
boiler-plate, and I can only imagine them contaning descriptive 
meta-data, not application logic.

>>I think we're currently solving this kind of problem with repo-links, 
>>e.g. with ZConfig and the like. Don't see why we wouldn't want to 
>>continue this.
> 
> Repolinks aside, the dogma of requring the CVS repository layout be the
> same as the install layout prevents a lot of packaging flexibility;
> namely, it prevents any possibility of having pure container directories
> like I suggested in my last email.

I'm very close to calling YAGNI on this one. Maybe I just don't see it, 
but what exact limitations are you talking about? What went wrong in 
Zope2 because of it? I'm sure there are other ways for solving this...

Philipp


From faassen at infrae.com  Tue Feb 17 12:15:20 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Tue Feb 17 13:16:34 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <4032362C.3060704@zope.com>
References: <4031E820.9000302@zope.com>	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>	<200402131703.07139.fred@zope.com>	<402D4DAF.10502@zope.com>	<200402131816.59402.fred@zope.com>	<1076969043.23662.42.camel@localhost.localdomain>	<4031E820.9000302@zope.com>	<403218E8.5040104@interlink.com.au>	<5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>
	<4032362C.3060704@zope.com>
Message-ID: <40324C28.5080301@infrae.com>

Tres Seaver wrote:

>> Speaking as another large package maintainer, I'd like setup.py to be 
>> either nonexistent, or automatically generated from something else 
>> that's modular.
>
>
> +1.  The configuration metadata in a typical setup.py can *never* be 
> introspected, for intsance, short of writing bytecode hacks to pick 
> apart the arguments passed to setup().

+1 too.

>> I'm certainly -1 on using XML for this, and I don't have a problem 
>> with using Python syntax.  But the single file approach has got to go.
>
>
> -1 for Python syntax;  Turing-completeness is a *disadvantage* in a 
> configuration language (e.g., why is ZCML not in Python?  why ZConfig?)


+1 to not using Python for configuration languages. Python is of course 
convenient on the short run, but I suspect will be harder on the long 
run. If packages were already explicitly declarative some of the 
problems Phillip Eby mentions would not have been an issue.

Using Python instead of declarations is already *hurting* the evolution 
of the packaging system, because people are maintaining their local 
Python hacks instead of thinking about what configuration options are 
really needed in the central packaging system. It focuses short-term 
behavior on fixing the wrong problem.

> WRT the format, I am agnostic about the spelling, but anti-NIH 
> suggests that we should adopt a widely-supported parseable format:


As long as it's declarative and doesn't look like Procmail or M4 macros 
or whatever, I'm fine too. :)

Regards,

Martijn


From jeremy at zope.com  Tue Feb 17 12:14:17 2004
From: jeremy at zope.com (Jeremy Hylton)
Date: Tue Feb 17 13:16:41 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <40324C28.5080301@infrae.com>
References: <4031E820.9000302@zope.com>
	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<200402131703.07139.fred@zope.com>	<402D4DAF.10502@zope.com>
	<200402131816.59402.fred@zope.com>
	<1076969043.23662.42.camel@localhost.localdomain>
	<4031E820.9000302@zope.com>	<403218E8.5040104@interlink.com.au>
	<5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>
	<4032362C.3060704@zope.com>  <40324C28.5080301@infrae.com>
Message-ID: <1077038056.23662.744.camel@localhost.localdomain>

On Tue, 2004-02-17 at 12:15, Martijn Faassen wrote:
> Tres Seaver wrote:
> 
> >> Speaking as another large package maintainer, I'd like setup.py to be 
> >> either nonexistent, or automatically generated from something else 
> >> that's modular.
> >
> >
> > +1.  The configuration metadata in a typical setup.py can *never* be 
> > introspected, for intsance, short of writing bytecode hacks to pick 
> > apart the arguments passed to setup().
> 
> +1 too.

Again, this depends on convention.  If people created introspectable
objects in setup.py, it would be easy.

> As long as it's declarative and doesn't look like Procmail or M4 macros 
> or whatever, I'm fine too. :)

I would like to have a format that is designed for humans to read and
write first and for programs to process second.  Python meets this
requirement, but XML does not.  I don't care too much about the details,
though.

Note that distutils already has one configuration file -- MANIFEST.in --
and there was some discussion on the distutils list about replacing that
with some Python code in setup.py.  The MANIFEST.in is this oddball
little configuration language that seems wordier than the equivalent
Python code.

Jeremy



From jim at zope.com  Tue Feb 17 11:35:51 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 17 13:19:45 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <200402170709.46424.srichter@cosmos.phy.tufts.edu>
References: <402F90E3.3040303@zope.com>
	<4031E922.9060706@zope.com>	<4031F6D0.60303@infrae.com>
	<200402170709.46424.srichter@cosmos.phy.tufts.edu>
Message-ID: <403242E7.2010809@zope.com>

Stephan Richter wrote:
> HI,
> 
> I am not quoting anyone here, because I want to take the discussion one step 
> back.
> 
> The reason we suggested folder and folder_web in the first place was to make 
> it easier to develop new UIs.

Yes

 > And this in turn was born from the problem that
> it was not easy for us to deactivate the browser ZCML in a package. 

Not really.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From simon at joyful.com  Tue Feb 17 12:42:28 2004
From: simon at joyful.com (Simon Michael)
Date: Tue Feb 17 13:19:49 2004
Subject: [Zope3-dev] Re: [NewResource] first draft (generated from LaTeX
	file)
In-Reply-To: <20040217090340EST@dev.zope.org>
References: <20040217090340EST@dev.zope.org>
Message-ID: <40325284.4090508@joyful.com>

srichter wrote:

(a bunch of great-looking wiki docs)

Nice, Stephan!

From jeff at bottlerocket.net  Tue Feb 17 12:43:40 2004
From: jeff at bottlerocket.net (Jeffrey P Shell)
Date: Tue Feb 17 13:19:52 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <200402170709.46424.srichter@cosmos.phy.tufts.edu>
References: <402F90E3.3040303@zope.com> <4031E922.9060706@zope.com>
	<4031F6D0.60303@infrae.com>
	<200402170709.46424.srichter@cosmos.phy.tufts.edu>
Message-ID: <D26751A9-6170-11D8-98CD-003065415378@bottlerocket.net>

+1

I hate the concept of 'folder_browser'

On Feb 17, 2004, at 5:09 AM, Stephan Richter wrote:

> HI,
>
> I am not quoting anyone here, because I want to take the discussion 
> one step
> back.
>
> The reason we suggested folder and folder_web in the first place was 
> to make
> it easier to develop new UIs. And this in turn was born from the 
> problem that
> it was not easy for us to deactivate the browser ZCML in a package.
> Therefore, I would really like to go back to
>
> folder
> folder/browser
> ...
>
> and provide a ZCML way of saying
>
> <disable>
>   <include package="folder.browser" />
> </disable>
>
> This way, if you you develop a new UI you can just declare
>
> <disable>
>   <include package="folder.browser" />
> </disable>
> <include package="srichter.folder.browser" />
>
> In my opinion this is much more sane than anything that we have 
> discussed
> concerning this branch of the debate.
>
> The rest of the packaging ideas, like factoring out components from 
> zope.app
> and creating smaller confined packages with good dependency 
> information and
> so on I really like.
>
> Regards,
> Stephan
> -- 
> Stephan Richter
> CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
> Web2k - Web Software Design, Development and Training
>
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope3-dev


From garrett at mojave-corp.com  Tue Feb 17 12:32:27 2004
From: garrett at mojave-corp.com (Garrett Smith)
Date: Tue Feb 17 13:20:38 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <40321256.4000509@weitershausen.de>
References: <402F90E3.3040303@zope.com>	<4031E922.9060706@zope.com>	<4031F6D0.60303@infrae.com>	<200402170709.46424.srichter@cosmos.phy.tufts.edu>
	<40321256.4000509@weitershausen.de>
Message-ID: <c0tivs$nn5$1@sea.gmane.org>

Philipp von Weitershausen wrote:

> Stephan Richter wrote:
> 
>> The reason we suggested folder and folder_web in the first place was 
>> to make it easier to develop new UIs. And this in turn was born from 
>> the problem that it was not easy for us to deactivate the browser ZCML 
>> in a package. Therefore, I would really like to go back to
>>
>> folder
>> folder/browser
> 
> 
> It is what we have now and we have said more than once that we don't 
> like it, because:
> 
> a) It would making browser code optional harder. When you install 
> 'folder', you get the browser junk with it, no matter whether you want 
> it or not.

 From CVS, yes. But I don't see the problem here. If it's that important 
to give 'consumers' a choice of UI or no-UI, create distributions as 
appropriate.

> b) It doesn't emphasize separation of application and browser code enough.

The folder/folder_browser goes too far and breaks the very real and 
meaningful dependency of folder.browser on folder. These are not sibling 
packages.

I just don't see how a browser subpackage doesn't effectively separate 
the browser code. It's in a separate package, it's separate, what? :-)

> c) It does not flatten the hierarchy enough. We will end up with browser 
> subpackages again.

Circular argument :-)

> What we really want is something like "separate but close". Being 
> increasingly sceptical of my own suggestion, I think Jim's concept is 
> the closest one to that doctrine, even though I still dislike the usage 
> of the underscore and not being able to make proper use of Python 
> namespaces. In that respect, I have great sympathy for Garret's and 
> Roger's opinion. I draw a different conclusion, though.
> 
>> and provide a ZCML way of saying
>>
>  > <disable>
>  >   <include package="folder.browser" />
>  > </disable>
> 
>>
>> This way, if you you develop a new UI you can just declare
>>
>  > <disable>
>  >   <include package="folder.browser" />
>  > </disable>
>  > <include package="srichter.folder.browser" />
> 
> I think that is not nearly as clear as simply adding or removing a line 
> from products.zcml or whereever the numerous packages in zope.app will 
> be configured from.

So, what's wrong with this:

   <configure>

     <include package="folder" />
     <include package="folder.browser" />

   </configure>

  -- Garrett



From garrett at mojave-corp.com  Tue Feb 17 12:21:27 2004
From: garrett at mojave-corp.com (Garrett Smith)
Date: Tue Feb 17 13:21:10 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <200402170646.28203.srichter@cosmos.phy.tufts.edu>
References: <402FA0DB.1030406@zope.com>
	<4030B5FE.8010306@weitershausen.de>	<4031E215.3080703@zope.com>
	<200402170646.28203.srichter@cosmos.phy.tufts.edu>
Message-ID: <c0tib8$lno$1@sea.gmane.org>

Stephan Richter wrote:

> On Tuesday 17 February 2004 04:42, Jim Fulton wrote:
> 
>>>Why is that a problem?
>>
>>Maybe I should have asked you why you thought your ideas might make
>>packaging easier. :)
>>
>>The problem is that, AFAIK, distutils doesn;t support installing
>>subpackages.
> 
> 
> I think we should not worry about distutils limitations at this point.
+1

I know Jim wants to flush out some issues here, but this topic warrants 
its own list.

Seriously, this is a hard, hard topic. I'm surprised there's this much 
energy being spent on improving distutils when Zope X3 1.0 on the table.

  -- Garrett



From chrism at plope.com  Tue Feb 17 11:53:41 2004
From: chrism at plope.com (Chris McDonough)
Date: Tue Feb 17 13:21:16 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <4032448D.2060207@zope.com>
References: <402F90E3.3040303@zope.com> <c0rr12$2qa$1@sea.gmane.org>
	<4031E922.9060706@zope.com> <4031F6D0.60303@infrae.com>
	<1077026360.1886.10.camel@athlon>  <4032448D.2060207@zope.com>
Message-ID: <1077036821.21647.44.camel@athlon>

On Tue, 2004-02-17 at 11:42, Jim Fulton wrote:
> > It needn't be.  I think it would be reasonable to ask developers to run
> > an install script just like end users. 
> 
> I don't.  This is not an option. Sorry. :)

I know you're not *really* sorry, but that's OK. ;-)

>  > Maybe in the case of developers
> > it creates symlinks instead of copying.
> 
> Symlinks don't really solve the problem. Think of adding and removing
> files.

The installer would symlink packages (directories), not individual
files.

> No, as I stated in my preproposal notes, it must be possible to
> run from a CVS checkout.

I don't know why, except for inertia.  This is a complete
non-requirement from my perspective, for any Python software.  If Zope 3
is really at some level a collection of more-or-less independent Python
packages, it should be possible to treat it as such by rearranging the
packages in their respective source versions and letting an installer
take care of placing them in the right directories at install time.  CVS
should not be responsible for this.

> Don't worry.  One of the main points of the discussion is to
> avoid having the CVS repository constrained by distributions.  Distributions
> need not (and probably won't) look anything like the repository.

I suspect that's backwards.  If a CVS checkout must be runnable
in-place, there will be likely be little need or desire to package for
distribution differently than as one big checkout turd, which is fine,
and is the strategy that Zope 2 takes, it's just not what I thought Zope
3 wanted to be about.

- C



From faassen at infrae.com  Tue Feb 17 12:17:53 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Tue Feb 17 13:21:20 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <1077034019.21652.18.camel@athlon>
References: <402F90E3.3040303@zope.com>
	<c0rr12$2qa$1@sea.gmane.org>	<4031E922.9060706@zope.com>
	<4031F6D0.60303@infrae.com>	<1077026360.1886.10.camel@athlon>
	<4032256C.10800@infrae.com>	<1077028819.1886.26.camel@athlon>
	<40323082.6000605@weitershausen.de>
	<1077034019.21652.18.camel@athlon>
Message-ID: <40324CC1.8000407@infrae.com>

Chris McDonough wrote:

>On Tue, 2004-02-17 at 10:17, Philipp von Weitershausen wrote:
>  
>
>>So, I'll to run something like 'make' after every friggin' change of a 
>>.py file? I think it's bad enough having to restart Z3 all the time. 
>>Hey, we're all using Python for it's being an interpreted language. 
>>Please let's not have compile-like processes.
>>    
>>
>
>This is why I suggested the symlink thing, FWIW.  You won't need to run
>make after any change if packages are symlinked from source into the
>install tree.  Windows people?  They lose.
>  
>
I'm worried that this will raise the development barrier. If you start 
needing to cross your symlinks to be able to conveniently develop a Zope 
3 extension, that's not very helpful. It's supposed to be easy to 
develop a Zope 3 extension.

Though I guess doing it the Pythonic way would require you to either 
symlink or re-run setup.py install each time you make a change...

Regards,

Martijn


From srichter at cosmos.phy.tufts.edu  Tue Feb 17 13:10:12 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Tue Feb 17 13:22:10 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <40321256.4000509@weitershausen.de>
References: <402F90E3.3040303@zope.com>
	<200402170709.46424.srichter@cosmos.phy.tufts.edu>
	<40321256.4000509@weitershausen.de>
Message-ID: <200402171310.12239.srichter@cosmos.phy.tufts.edu>

On Tuesday 17 February 2004 08:08, Philipp von Weitershausen wrote:
> Stephan Richter wrote:
> > The reason we suggested folder and folder_web in the first place was to
> > make it easier to develop new UIs. And this in turn was born from the
> > problem that it was not easy for us to deactivate the browser ZCML in a
> > package. Therefore, I would really like to go back to
> >
> > folder
> > folder/browser
>
> It is what we have now and we have said more than once that we don't
> like it, because:

Well, this is *not* what we have right now. We have

folder
browser/folder
interfaces/folder

and I suggest to go back to 

folder
folder/browser
folder/interfaces (if the interfaces are fairly locally applicable)

Also, what I am saying is that the new solutions we are thinking of are in my 
opinion so bad, that this solution looks attractive again.

> a) It would making browser code optional harder. When you install
> 'folder', you get the browser junk with it, no matter whether you want
> it or not.

No, here you mix package structure with distribution. Surely I can have 
folder-1.0.tgz and folder-browser-1.0.tgz and still get the directory 
structure above. The only thing we would need to change would be to not 
include the browser configuration from within folder, but separate them:

<include package="folder"/>
<include package="folder.browser"/>

> b) It doesn't emphasize separation of application and browser code enough.

How does it not. It's a separate package... All what the hierarchy says is 
that this browser package belongs to folder, which is very sensible. As was 
pointed out in other mails, package structure does not have to equal 
distribution structure. I am still completely for the idea of having many 
small packages with dependencies.

> c) It does not flatten the hierarchy enough. We will end up with browser
> subpackages again.

Ok, but: So what? Originally we had some goals in mind when saying we want to 
flatten the hierarchy:

1. Make zope.app more transparent. This is still possible with this 
suggestion.

2. Make it easier to package. I just showed that it would be equally hard or 
easy either way.

3. Separate presentation from content. I think this is still the case; just 
because a package lives in another one, does not mean it merged with its 
parent. Even better, it does not make sense to install folder-browser-1.0 if 
you do not have folder-1.0.

> What we really want is something like "separate but close". Being
> increasingly sceptical of my own suggestion, I think Jim's concept is
> the closest one to that doctrine, even though I still dislike the usage
> of the underscore and not being able to make proper use of Python
> namespaces. In that respect, I have great sympathy for Garret's and
> Roger's opinion. I draw a different conclusion, though.

I think my solution follows the "separate but close" doctrine too and still 
makes proper use of Python namespaces.

> I think that is not nearly as clear as simply adding or removing a line
> from products.zcml or whereever the numerous packages in zope.app will
> be configured from.
>
> Where would this stanza of ZCML you're suggesting be? In the global
> config file (e.g. products.zcml)? Or in the
> srichter.folder/configure.zcml? Neither place looks "right"... :)

I agree with Martijn's response on this question.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From chrism at plope.com  Tue Feb 17 13:25:29 2004
From: chrism at plope.com (Chris McDonough)
Date: Tue Feb 17 13:25:36 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <40324ABA.5000500@zope.com>
References: <402F90E3.3040303@zope.com> <c0rr12$2qa$1@sea.gmane.org>
	<4031E922.9060706@zope.com> <4031F6D0.60303@infrae.com>
	<1077026360.1886.10.camel@athlon> <4032448D.2060207@zope.com>
	<1077036821.21647.44.camel@athlon>  <40324ABA.5000500@zope.com>
Message-ID: <1077042329.21652.79.camel@athlon>

> > The installer would symlink packages (directories), not individual
> > files.
> 
> OK, think of adding and removing directories.

FWIW, it's not often (at least as borne out in Zope 2) that directories
are added or removed.  It happens maybe every two weeks or every month
or so that someone adds a directory.  It happens *very* infrequently
that someone removes a directory.  Under either circumstance,
invariably, someone on the receiving end of that change forgets to add
-d or a -P to their "cvs up" command, and they get an error when they
try to run the software, they figure it out, update, and everything is
ok, and nobody gets hurt.  I don't understand how the impact of my
suggestion is very different (except maybe for symlink removal, which,
really, isn't that big of a deal, given that it's a fairly small number
of directories we're talking about, and a "find -exec rm" could do the
job).

FWIW, as another point, every Zope 2 installation out there that I've
ever put in to production effectively uses checkouts and symlinks in a
like way, mainly to manage shared products directories.  Additionally,
each development Zope 2 instance home I've got on my own computer has a
Products directory full of symlinks like this that point to other
products in another directory that I share between instance homes.  This
is solving a packaging problem for me.  If I could have Zope participate
in that system, I would.  E.g.: do I really need 17 copies of ZCatalog
on my hard disk, one for each software home checkout, even though it
might not have changed between checkouts?

I just wonder what makes "core Zope" all that special that it's exempt
from this kind of thing, especially if you want it to be divisible at
some level?

> > I don't know why, except for inertia.  This is a complete
> > non-requirement from my perspective, for any Python software. 
> 
> 
> That's fine.
> 
>  From my perspective it is a huge requirement.
> 
> Note that I must not be the only one.  Python itself
> can be run from a CVS checkout.

To me, typing "cvs up -dP; make inplace" is just as easy as typing "cvs
up -dP" itself.  It's just such a small price to pay in the big scheme
of things.  But I won't continue to belabor the issue by presenting
counterpoints if there can't be a discussion about it, as you've already
said "no".

>  > If Zope 3
> > is really at some level a collection of more-or-less independent Python
> > packages, it should be possible to treat it as such by rearranging the
> > packages in their respective source versions and letting an installer
> > take care of placing them in the right directories at install time.  CVS
> > should not be responsible for this.
> 
> I agree 100%.  But I still insist on the convenience of not having
> to run an installtion script, much less rerun one every time I
> do a cvs up.

As far as I can tell, those requirements are at odds with one another. 
But maybe something else will fall out.  Shrug.

> >>Don't worry.  One of the main points of the discussion is to
> >>avoid having the CVS repository constrained by distributions.  Distributions
> >>need not (and probably won't) look anything like the repository.
> > 
> > 
> > I suspect that's backwards.   If a CVS checkout must be runnable
> > in-place, there will be likely be little need or desire to package for
> > distribution differently than as one big checkout turd,
> 
> Yes there will be,  Distributions will often contain different things than
> what's in the repository. There will be experimental things in the repository
> that don't make it in to distributions. Similarly, people will create distributions
> that contain additional software that's not in the repository.

I see what you're saying, but I suspect all of the inclusion and
disinclusion of packages will end up itself managed via CVS (as it is in
Zope 2), which just isn't the right tool for that job.  As a result, in
a year from now, it's likely that nobody will remember what the intent
was.

- C



From chrism at plope.com  Tue Feb 17 13:36:15 2004
From: chrism at plope.com (Chris McDonough)
Date: Tue Feb 17 13:37:04 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <40324CC1.8000407@infrae.com>
References: <402F90E3.3040303@zope.com> <c0rr12$2qa$1@sea.gmane.org>
	<4031E922.9060706@zope.com> <4031F6D0.60303@infrae.com>
	<1077026360.1886.10.camel@athlon> <4032256C.10800@infrae.com>
	<1077028819.1886.26.camel@athlon> <40323082.6000605@weitershausen.de>
	<1077034019.21652.18.camel@athlon>  <40324CC1.8000407@infrae.com>
Message-ID: <1077042975.21652.90.camel@athlon>

On Tue, 2004-02-17 at 12:17, Martijn Faassen wrote:
> >This is why I suggested the symlink thing, FWIW.  You won't need to run
> >make after any change if packages are symlinked from source into the
> >install tree.  Windows people?  They lose.
> >  
> >
> I'm worried that this will raise the development barrier. If you start 
> needing to cross your symlinks to be able to conveniently develop a Zope 
> 3 extension, that's not very helpful. It's supposed to be easy to 
> develop a Zope 3 extension.

As far as I can tell, this has nothing to do with developing Zope
extensions; this has to do with developing Zope core.  Nobody needs
symlinks to develop Zope extensions (they don't need UNIX, IOW).  They
can just install Zope normally, and change ZCML in place to include
their own packages/products as necessary.  The "tree full of symlinks"
is purely a convenience for Zope core developers who want to be able to
maintain the *core pieces* in the context of a running checkout. 
Extensions writers are not served at all by this.

> Though I guess doing it the Pythonic way would require you to either 
> symlink or re-run setup.py install each time you make a change...

Not on every change, just on any addition or removal of a top-level
package.

- C



From faassen at infrae.com  Tue Feb 17 13:47:32 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Tue Feb 17 13:46:13 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <1077038056.23662.744.camel@localhost.localdomain>
References: <4031E820.9000302@zope.com>	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>	<200402131703.07139.fred@zope.com>	<402D4DAF.10502@zope.com>	<200402131816.59402.fred@zope.com>	<1076969043.23662.42.camel@localhost.localdomain>	<4031E820.9000302@zope.com>	<403218E8.5040104@interlink.com.au>	<5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>	<4032362C.3060704@zope.com>
	<40324C28.5080301@infrae.com>
	<1077038056.23662.744.camel@localhost.localdomain>
Message-ID: <403261C4.3070909@infrae.com>

Jeremy Hylton wrote:

>On Tue, 2004-02-17 at 12:15, Martijn Faassen wrote:
>  
>
>>Tres Seaver wrote:
>>    
>>
>>>>Speaking as another large package maintainer, I'd like setup.py to be 
>>>>either nonexistent, or automatically generated from something else 
>>>>that's modular.
>>>>        
>>>>
>>>+1.  The configuration metadata in a typical setup.py can *never* be 
>>>introspected, for intsance, short of writing bytecode hacks to pick 
>>>apart the arguments passed to setup().
>>>      
>>>
>>+1 too.
>>    
>>
>
>Again, this depends on convention.  If people created introspectable
>objects in setup.py, it would be easy.
>
>  
>
Okay, if setup.py is introspectible that's fine with me too. That would 
introduce some backwards compatibility issues, perhaps, though.

>>As long as it's declarative and doesn't look like Procmail or M4 macros 
>>or whatever, I'm fine too. :)
>>    
>>
>
>I would like to have a format that is designed for humans to read and
>write first and for programs to process second.  Python meets this
>requirement, but XML does not.  I don't care too much about the details,
>though.
>
>  
>
I'm talking declarative, I deliberately didn't say XML as that yanks 
people's chains. A Python program is not declarative and in case of 
setup.py clearly encourages ad-hoc hackery. If we're going to require 
some completely fixed declarative Python structure, or ZConfig, or 
whatever else, that's fine too. If someone then needs XML they can 
always translate it. The point is that currently this not possible.

>Note that distutils already has one configuration file -- MANIFEST.in --
>and there was some discussion on the distutils list about replacing that
>with some Python code in setup.py.  The MANIFEST.in is this oddball
>little configuration language that seems wordier than the equivalent
>Python code.
>  
>
I'm not saying we should use an oddball little configuration language. 
We should use something that is not oddball and familiar to people and 
declarative.

Regards,

Martijn


From jeff at bottlerocket.net  Tue Feb 17 13:47:19 2004
From: jeff at bottlerocket.net (Jeffrey P Shell)
Date: Tue Feb 17 13:47:37 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <200402160711.24984.srichter@cosmos.phy.tufts.edu>
References: <402FA0DB.1030406@zope.com> <402FC5A0.5020701@weitershausen.de>
	<402FF972.6080605@weitershausen.de>
	<200402160711.24984.srichter@cosmos.phy.tufts.edu>
Message-ID: <B6A318AC-6179-11D8-98CD-003065415378@bottlerocket.net>

On Feb 16, 2004, at 5:11 AM, Stephan Richter wrote:

> On Sunday 15 February 2004 17:57, Philipp von Weitershausen wrote:
>>> <thinking-out-loud-mode>
>>>
>>> What if we had
>>>
>>> - zope.app ? -- containing flat packages with application code
>>> - zope.browser ? -- containing just as flat packages with browser 
>>> code
>>> - zope.webdav ? -- ........ with WebDAV presentation
>>>
>>> Hmm... What about a different top-level package?
>>>
>>> - zope.app ?-- containing flat packages with application code
>>> - zopepresent.browser ?-- contains flat browser packages
>>> - zopepresent.webdav ?-- contains flat WebDAV packages
>>>
>>> Or a different top-level package for each presentation type?
>>>
>>> - zope.app ?-- containing flat packages with application code
>>> - zopebrowser ?-- contains flat browser packages
>>> - zopedav ?-- contains flat WebDAV packages
>>>
>>> </thinking-out-loud-mode>
>>
>> I took this crazy idea one step further: Why not make zope.app a
>> top-level package as well?
>>
>> Consider:
>>
>> - zope ? ? ?-- contains general application code, just like now
>> - zopeapp ? ?-- like zope.app above (flat packages, etc.)
>> - zopebrowser -- like above
>> - ...
>
> I find all these a step in the right direction. Certainly much cleaner 
> than
> the underscore.

It's cleaner than the underscore.  I don't really like it.  It feels 
redundant to have 'zope' there so many times, like the damn 'z' in 
front of so many product names.

I like zope.app
I like zope.app.content

Those were very intuitive.  The separation of components (presentation, 
interfaces) could be tricky and annoying to deal with - but the 
structure was clean and consistent.

As far as navigation goes - I think it's a lot harder to stare at a 
directory listing in a terminal with hundreds of similarly named 
entries and trying to narrow one out.

So, I think that some of the current organization is a bit difficult, 
but I like the general concept of good and deep package hierarchy.

I don't want

folder
folderbrowser
folderwebdav
folderftp
folderxmlrpc
folderrest
foldersoap
folderrdf

For every ******* little item.  Granted, that list is a little extreme, 
but I hope the idea carries.  It seems awfully redundant, and smacks of 
C code naming conventions {where in the absence of namespaces, all 
API's tend to pick up prefixes}.

I liked the ZCML <disable> idea.

If we have to have file and i18n_file, and browser and ftp and xmlrpc 
and yada yada yada stock presentations for each thing like that - then 
I've got lots of terminal paging and scrolling and squinting to deal 
with.

And if, as Jim infers (and I don't think he's off base with this) a lot 
of these packages become small - why have folder [which may be a bad 
example in this case] be a package at all?  If half of these become 
single module packages with a configure.zcml file that I've got to 
track down and winnow out and figure out what's going on - I don't see 
the improvement.  It seems to me to be a step back.

--
Jeffrey P Shell
jeff@bottlerocket.net


From faassen at infrae.com  Tue Feb 17 13:51:39 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Tue Feb 17 13:50:59 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <200402171310.12239.srichter@cosmos.phy.tufts.edu>
References: <402F90E3.3040303@zope.com>	<200402170709.46424.srichter@cosmos.phy.tufts.edu>	<40321256.4000509@weitershausen.de>
	<200402171310.12239.srichter@cosmos.phy.tufts.edu>
Message-ID: <403262BB.9030103@infrae.com>

Stephan Richter wrote:

>Well, this is *not* what we have right now. We have
>
>folder
>browser/folder
>interfaces/folder
>
>and I suggest to go back to 
>
>folder
>folder/browser
>folder/interfaces (if the interfaces are fairly locally applicable)
>
>Also, what I am saying is that the new solutions we are thinking of are in my 
>opinion so bad, that this solution looks attractive again.
>  
>

Also note that I understand this proposal to include more than just 
small packages like folder. I could in theory create a fairly large 
package for XML that is structured like this:

zopexml
zopexml/browser
zopexml/interfaces

with quite extensive submodules in browser and interfaces.

Alternatively I can have a very small package foo, where it looks like this:

foo/foo.py
foo/browser.py
foo/interfaces.py

This is similar to what we have now after we finish refactoring and 
flattening stuff out. :)

Regards,

Martijn


From chrism at plope.com  Tue Feb 17 14:08:20 2004
From: chrism at plope.com (Chris McDonough)
Date: Tue Feb 17 14:09:03 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <40324D38.9020808@weitershausen.de>
References: <402F90E3.3040303@zope.com> <c0rr12$2qa$1@sea.gmane.org>
	<4031E922.9060706@zope.com> <4031F6D0.60303@infrae.com>
	<1077026360.1886.10.camel@athlon> <4032256C.10800@infrae.com>
	<1077028819.1886.26.camel@athlon> <40323082.6000605@weitershausen.de>
	<1077034019.21652.18.camel@athlon> <40324D38.9020808@weitershausen.de>
Message-ID: <1077044900.21652.117.camel@athlon>

On Tue, 2004-02-17 at 12:19, Philipp von Weitershausen wrote:
> For example Windows people lose. Also, when you add new files, rename 
> them, refactor etc., you do not only have to make sure you get it right 
> in the revision control system, now you also have a symlink tree to take 
> care of...

Look, let's face it.  The number of Zope core developers that a) use
Windows, b) don't use Cygwin under Windows to develop Zope core and c)
own Visual C++ to be able to compile the requisite Zope C extensions is
pretty small, probably nearing 1 (*cough* Tim *cough* ;-).

Most Windows people install from binary, period.  And there's Cygwin,
which does symlinks just fine.  If people want to use Windows sans
Cygwin to develop Zope core, that's fine; they just need to copy the
files they change in the installed copy back into the source tree
manually and check them in.  The amount of people we would lose to such
a hardship is... zero.  Really.  The teeming throng of Windows people
here are free to stand up and prove me wrong. ;-)

Writing the additional logic into the package installer scripts (or
distutils) to do symlinks instead of copies for each subpackage of a
container directory full of packages is really not a big deal.  We're
not talking about needing to make a symlink for every new directory,
we're talking about needing to make a symlink for every new package. 
Developers will need to know when they add a package, because they'll
need to specify it in the distutils setup script anyway for installed
versions of Zope to run properly.

> > How is one setup script per package monolithic?
> 
> It's not. You must have misunderstood me. I too want a setup file for 
> each package. Though I dislike them being python scripts, but I could 
> even live with that. I guess they would just contain a lot of 
> boiler-plate, and I can only imagine them contaning descriptive 
> meta-data, not application logic.

OK, I think we completely agree about that.

> > Repolinks aside, the dogma of requring the CVS repository layout be the
> > same as the install layout prevents a lot of packaging flexibility;
> > namely, it prevents any possibility of having pure container directories
> > like I suggested in my last email.
> 
> I'm very close to calling YAGNI on this one. Maybe I just don't see it, 
> but what exact limitations are you talking about? What went wrong in 
> Zope2 because of it? I'm sure there are other ways for solving this...

There's just no way to use a *piece* of Zope 2, except possibly for
ZODB.  But that's only because ZODB has been explicitly maintained
separately, by separate people, as a separate package.  Other than ZODB,
Zope 2 really is a huge turd of interdependencies that cannot be
separated.

Having a one-to-one relationship between a CVS checkout and a runnable
copy of Zope promotes the interdependency problem.  This is because
there is no way to capture the intent of dependencies within the tree
itself; newcomers to the software see the tree as one huge package.

For example, in Zope 2, everyone knows that ZPublisher should probably
be able to depend on ZServer, but not vice versa.  But where can I make
that assertion within a runnable checkout tree?  I can't.  In fact, this
is not the case.  In Zope 2, ZServer does now depend on ZPublisher. 
Why?  Because somebody didn't understand the intent of packaging them
separately.  Nobody has the time to play dependency police forever, so
these sorts of things slip in.  Over time, they come to bind the
software together in such a way that it cannot be separated.  This is
bad, because it reduces maintainability and chases Python folks away;
this "turdness" of Zope 2 is one of the main reasons that most Python
people are frightened of Zope: it's one huge module to them; they cannot
subdivide it into its component parts.

Now, distutils doesn't have the ability to spell dependencies right
now.  But at least it should be possible to group certain packages
together into "superpackages" which are maintained separately from one
other.  The proposed "foo" and "foo_browser" package set represents such
a superpackage.  Other superpackages may exist.  I'm just asserting that
the CVS tree be represented in terms of these superpackages rather than
in terms of how they should be laid out in an installed version.

FWIW, I'm out of time to promote my point of view about this, so I can't
respond to further talk about it, just wanted to say my peace. ;-)

- C



From garrett at mojave-corp.com  Tue Feb 17 14:27:25 2004
From: garrett at mojave-corp.com (Garrett Smith)
Date: Tue Feb 17 14:23:29 2004
Subject: [Zope3-dev] RE: Packaging pre-proposal/notes
Message-ID: <FB37E9B9E9354A4788F1B322E4AAD1D8217D@server1.mojave.local>

Chris McDonough wrote:

> Most Windows people install from binary, period.  And there's Cygwin,
> which does symlinks just fine.  If people want to use Windows sans
> Cygwin to develop Zope core, that's fine; they just need to copy the
> files they change in the installed copy back into the source tree
> manually and check them in.  The amount of people we would lose to
> such a hardship is... zero.  Really.  The teeming throng of Windows
> people here are free to stand up and prove me wrong. ;-)

Whoa. I haven't paid too much attention to this thread (list activity's
been off the chart these days), but I'm definitely one of those Windows
users that doesn't use Cygwin and does use VC++ to compile Python
extensions.

I'm not clear on what we'd need symlinks for, but this sounds like
things are getting pretty complex. What's the payoff?

Maybe this needs to be written up in a proposal.

 -- Garrett

From chrism at plope.com  Tue Feb 17 14:30:25 2004
From: chrism at plope.com (Chris McDonough)
Date: Tue Feb 17 14:31:01 2004
Subject: [Zope3-dev] RE: Packaging pre-proposal/notes
In-Reply-To: <FB37E9B9E9354A4788F1B322E4AAD1D8217D@server1.mojave.local>
References: <FB37E9B9E9354A4788F1B322E4AAD1D8217D@server1.mojave.local>
Message-ID: <1077046225.21647.123.camel@athlon>

On Tue, 2004-02-17 at 14:27, Garrett Smith wrote:
> Whoa. I haven't paid too much attention to this thread (list activity's
> been off the chart these days), 

I'm afraid I don't have the time to summarize the discussion, you'll
need to piece it together if you're interested.  I wouldn't be too
concerned, though, the idea seems all but stillborn anyway given the
reaction of most people.  They will be sorry, but that's the way it
goes. ;-)

-C



From dominik.huber at projekt01.ch  Tue Feb 17 14:46:16 2004
From: dominik.huber at projekt01.ch (Dominik Huber)
Date: Tue Feb 17 14:47:40 2004
Subject: [Zope3-dev] RE: Separate presentation packages
In-Reply-To: <40321D77.5070803@weitershausen.de>
Message-ID: <MLEHIMEMKLLFBGGPMEAHKENDGLAA.dominik.huber@projekt01.ch>

> Philipp von Weitershausen wrote:
[...]
> It is not core vs. browser. 'core' is the wrong word. It is application 
> vs. presentation. Whether something is part of Zope core, optional, or 
> somethine else, is not part of this discussion. We want packages to be 
> able to change their status with respect to coreness or option.

I know, excuse my stupid example :S

[...]
> The bottom line is that we want application and presentation packages 
> "separate but close". That cannot be solved by deep hierarchy.  
> Since Python does not leave us with much else, a naming convention seems like 
> the only solution. Believe me, I don't like underscores in package names 
> either and I'd be happier if I knew a better solution.

I try to express my concern in an other way (excuse my clumsy english).

IMO presentation (view) and application (model) are two different aspects of the same logical level.
I think Jim states the same:
>I think it's pretty jarring. This is what we have now.  (Well,
>what we have now is worse, because of different levels within
>the app and browser hierarchies.

If I structure a simple package x in a pure hierachical way which accounts that presentation and application are on the same level, the following structure might obtained:

x.application.app.Foo
x.application.interfaces.IFoo
...
x.presentation.browser.FooView
x.presentation.xmlrpc.FooView
x.presentation.webdav.FooView
...

IMO this is a deep hierarchy. The "separate but close" way might remove the classification application and presentation (but it will be still easy to mentaly reproduce the beneath deep hierarchy):

x.app.Foo
x.interfaces.IFoo
...
x.browser.FooView
...

It looks like yours (Philipp's) <thinking-out-loud-mode>-suggestion:
> - zope.app   -- containing flat packages with application code
> - zope.browser   -- containing just as flat packages with browser code
> - zope.webdav   -- ........ with WebDAV presentation

If I have to a provide a sophisticated package I would be forced to split up into subpackages because my modules become to complex:

x.app._foo.Foo (import in __init__)
x.app.bar.Bar
x.interfaces._foo.IFoo
x.interfaces.bar.IBar
...
x.browser._foo.FooView
x.browser.bar.BarView
...

Deepness comes with complexity. ("separate but close" = the simplest possible hierarchy which can display a certain complexity but not simplier!)

My concern: Anyhow a package is implemented (simple or sophisticated) a potential reader or contributor should come across the same logical hierarchy in both scenarios. That implies the naming of root modules/packages must be conservative. It's a temporal aspect of unambiguity.
It's not a question of affectation, it's only a trade-off between programmers to provide an unique way code is structured: exp.
- x.app -> application implementation
- x.products -> options and extensions, nested subpackages
- x.interfaces -> interace definition
- x.browser -> http presentation

When I look at zope.app today I think the main advantage is we could establish a prototype of such a trade-off.

I really like those conventions how people have to structure their code. It makes it easier to browse packages. The only thing is that the current prototype shows some weak points. I compare the current situation with the above mockup to illustrate some mismatches, IMO:

- There are no x.app.X but a lot of x.x.X
  
  Application code naming does not behave conservative. 
  Application code complexity is not encapsulated.

- There are often one or two hierarchical levels more because we have to handle zope.apps complexity:

  x.app.interfaces.catalog.catalog.ICatalog
  x.app.browser.catalog.catalog.CatalogEditView

- There is that problem of different levels within application and presentation

  x.app.browser instead x.browser
  x.app.interfaces instead of x.interfaces

- Subpackages are not nested packages (encapsulate). Everything is in an absolute structere.
  There are a lot of packages which doesn'ot belong to the core and increase the complexity. 
  They will be refactored out soon. This will induce more clearness.

  At least remove thematical/functional packages (-> products)
  Nested product packages have a deep hierarchy.

When I consider those mismatches I assess their *impact on usability* is pretty huge and all that is that *what we have now and Jim thinks most people hate it*.

Anyhow it is dangerous to project all those impacts on to the dotted package hierarchy!

> >> Jim Fulton wrote:
> >> These is especially painful for people who don't use emacs. :)
> >> I just spent a week with a room full of vi users doing Zope 3
> >> coding.  They spend way too much time cd-ing,
> > 
> > IMO the physical navigation problem should we solve with better tool
> > support and it's not legitimation for a crucial naming work-around ;)
> 
> What do you mean with better tool support?
It's a usability question of the editor vi and a personal decision of each developer. Nobody would rename code if I say it's pretty hard to develope zope3 using wordpad. ;)

regard,
dominik
From srichter at cosmos.phy.tufts.edu  Tue Feb 17 14:57:06 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Tue Feb 17 14:57:14 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <403262BB.9030103@infrae.com>
References: <402F90E3.3040303@zope.com>
	<200402171310.12239.srichter@cosmos.phy.tufts.edu>
	<403262BB.9030103@infrae.com>
Message-ID: <200402171457.06718.srichter@cosmos.phy.tufts.edu>

On Tuesday 17 February 2004 13:51, Martijn Faassen wrote:
> Also note that I understand this proposal to include more than just
> small packages like folder. I could in theory create a fairly large
> package for XML that is structured like this:
>
> zopexml
> zopexml/browser
> zopexml/interfaces
>
> with quite extensive submodules in browser and interfaces.
>
> Alternatively I can have a very small package foo, where it looks like
> this:
>
> foo/foo.py
> foo/browser.py
> foo/interfaces.py

I agree with all of the above.

> This is similar to what we have now after we finish refactoring and
> flattening stuff out. :)

For 3rd party products, such as the one living in zope.products, this is 
exactely how it works today. zwiki, for example uses your first layout, while 
many of the demo packages I wrote use the latter. I personally like it this 
way a lot.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From faassen at infrae.com  Tue Feb 17 16:32:04 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Tue Feb 17 16:32:10 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <200402171457.06718.srichter@cosmos.phy.tufts.edu>
References: <402F90E3.3040303@zope.com>	<200402171310.12239.srichter@cosmos.phy.tufts.edu>	<403262BB.9030103@infrae.com>
	<200402171457.06718.srichter@cosmos.phy.tufts.edu>
Message-ID: <40328854.1020308@infrae.com>

Stephan Richter wrote:

>>This is similar to what we have now after we finish refactoring and
>>flattening stuff out. :)
>>    
>>
>
>For 3rd party products, such as the one living in zope.products, this is 
>exactely how it works today. zwiki, for example uses your first layout, while 
>many of the demo packages I wrote use the latter. I personally like it this 
>way a lot.
>  
>

Sssh, don't tell them it's *exactly* the same, they insist on changing 
at least something! :)

Regards,

Martijn


From fred at zope.com  Tue Feb 17 17:04:49 2004
From: fred at zope.com (Fred Drake)
Date: Tue Feb 17 17:04:57 2004
Subject: [Zope3-dev] More thoughts on packaging
In-Reply-To: <1076969043.23662.42.camel@localhost.localdomain>
References: <5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<200402131816.59402.fred@zope.com>
	<1076969043.23662.42.camel@localhost.localdomain>
Message-ID: <200402171704.49465.fred@zope.com>

On Monday 16 February 2004 05:04 pm, Jeremy Hylton wrote:
 > I haven't noticed any problems using ZODB3's setup.py to hold metadata.
 > Did you have specific issues in mind?  Perhaps the metadata that is
 > currently in setup.py isn't that interesting -- a URL, email address,
 > description, and version number.

I thought I'd addressed this last week.  Specifically, when I make a change 
to a package that's included in several distributions (such as ZConfig), I 
need to change the setup.py for each distribution.  It's not that I need to 
change setup.py for ZODB, but that I need to change setup.py for ZODB, Zope 
2, Zope 3, and StandaloneZConfig.

 > Several people have griped about having to put metadata in a Python
 > script.  I think they confusing policy and mechanism.  If a distutils

Perhaps.  Using Python as a metadata language doesn't bode well, because it 
means we haven't defined the needed metadata carefully enough to express it 
in a more limited language.

 > command needs metadata to operate, it must be passed to the setup()
 > call.  There's no requirement that the data passed to it be stored in a
 > script called setup.py or in any Python script.  You could put the
 > metadata in a file and write a helper routine that loads metadata to be

And we end up with a similar situation of a 40-line boilerplate setup.py 
with just the code that all our setup.py scripts need to have updated when 
it changes.  Better than the current situation, but still tedious.

 > passed to setup.  (I'm not sure what the file format would be.  If I
 > have to write it by hand and my choices are Python and XML, I'll stick
 > with Python.)

I wouldn't choose either; something closer to plain text is best.  But I 
would choose XML over Python because XML can't be mistaken for a 
programming language, and Python is one.

Some sort of wrapper tool that generates setup.py, or actual improvements to 
distutils, seem like the reasonable possible approaches.


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation


From fred at zope.com  Tue Feb 17 17:18:56 2004
From: fred at zope.com (Fred Drake)
Date: Tue Feb 17 17:19:03 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <5.1.0.14.0.20040216222127.0213acf0@mail.telecommunity.com>
References: <1076969103.23662.44.camel@localhost.localdomain>
	<5.1.0.14.0.20040216222127.0213acf0@mail.telecommunity.com>
Message-ID: <200402171718.56963.fred@zope.com>

At 12:28 PM 2/17/04 +1100, Richard Jones wrote:
 > It has a data_files option (see section 3.5 of the distutils manual)
 > which lists data files to install in subdirs of the install prefix. So
 > in Roundup, I specify things like:
...
 >Or were you thinking of something else?

On Monday 16 February 2004 10:29 pm, Phillip J. Eby wrote:
 > Data files that need to be installed *in* the package directory, ala
 > ZConfig 'component.xml' files.
 >
 > Personally, I use the following subclass of install_data:
...
[...something that modifies install_data to install package data...]
...
 > There probably needs to be a different way to address this than the one
 > I'm using, though, because changing install_data to do what I do would
 > clearly break yours and other people's code who are using install_data
 > to install non-package files.

I think of what distutils currently does with data_files makes sense for 
what I'd call "application data," but not for data that's tightly bound to 
code (like ZConfig schema components).  (Yes, that leaves a very loose idea 
of what application data is, which is fine.)  I think distutils needs to 
grow a way to deal with package data; the application data support doesn't 
need to change (at least not as a side-effect of this).


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation


From jim at zope.com  Wed Feb 18 05:31:34 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Feb 18 05:32:15 2004
Subject: [Zope3-dev] Drop local event service and object hub for now
Message-ID: <40333F06.2050403@zope.com>


Steve and Marius are working on an event service refactoring
proposal.  This will bring about significant changes in the way
that local event subscriptions are handled.

Parentgeddon reduced substantially the need for an object hub.
We only need a hub to support indexes.

Neither the event service nor the hub have been updated to
reflect parentgeddon.

AFAIK, the only thing that uses the hub right now is the index
and catalog code.

I love the current indexing and catalog code, but (based on my
earlier survey) I don't think we need to include it in X3.0.
AFAIK, there are no existing applications that depend on
the existing catalog or indexes.

AFAIK, the only user of the local event service is the hub.

Therefore (whew :), I propose to:

- Remove the code that sets up the local event and hub services.

- Add code to remove previously created event services and hubs.

- Remove the local event service and hub code, being careful
   not to break existing databases.

- Temporarily break the indexing and catalog code

Any objections?  Am I missing any other uses of the local event services
or the hub?

Of course, later, after we have the new event subscription machinery
and simpler hub in place, we'll make the indexes and catalogs work
again,

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org



From jim at zope.com  Wed Feb 18 06:05:11 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Feb 18 06:05:49 2004
Subject: [Zope3-dev] Functional test failure: insensitivefolder
Message-ID: <403346E7.40509@zope.com>

p3 test.py -f
Running functional tests from /home/jim/z3/3
Parsing ftesting.zcml
Error in test testAddCasInsensitiveFolder (zope.products.demo.insensitivefolder.ftests.TestCaseInsensitiveFolder)
Traceback (most recent call last):
   File "/home/jim/z3/3/src/zope/products/demo/insensitivefolder/ftests.py", line 29, in testAddCasInsensitiveFolder
     form={'type_name': u'zope.CaseInsensitiveFolder',
   File "/home/jim/z3/3/src/zope/testing/functional.py", line 200, in publish
     publish(request, handle_errors=handle_errors)
   File "/home/jim/z3/3/src/zope/publisher/publish.py", line 137, in publish
     result = publication.callObject(request, object)
   File "/home/jim/z3/3/src/zope/app/publication/zopepublication.py", line 152, in callObject
     return mapply(ob, request.getPositionalArguments(), request)
   File "/home/jim/z3/3/src/zope/publisher/publish.py", line 113, in mapply
     return debug_call(object, args)
   File "/home/jim/z3/3/src/zope/publisher/publish.py", line 119, in debug_call
     return object(*args)
   File "/home/jim/z3/3/src/zope/app/browser/container/adding.py", line 158, in action
     factory = zapi.getFactory(self, type_name)
   File "/home/jim/z3/3/src/zope/component/__init__.py", line 162, in getFactory
     return getService(context, Factories).getFactory(name)
   File "/home/jim/z3/3/src/zope/component/factory.py", line 68, in getFactory
     raise ComponentLookupError(name)
ComponentLookupError: zope.CaseInsensitiveFolder

======================================================================
ERROR: testAddCasInsensitiveFolder (zope.products.demo.insensitivefolder.ftests.TestCaseInsensitiveFolder)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "/home/jim/z3/3/src/zope/products/demo/insensitivefolder/ftests.py", line 29, in testAddCasInsensitiveFolder
     form={'type_name': u'zope.CaseInsensitiveFolder',
   File "/home/jim/z3/3/src/zope/testing/functional.py", line 200, in publish
     publish(request, handle_errors=handle_errors)
   File "/home/jim/z3/3/src/zope/publisher/publish.py", line 137, in publish
     result = publication.callObject(request, object)
   File "/home/jim/z3/3/src/zope/app/publication/zopepublication.py", line 152, in callObject
     return mapply(ob, request.getPositionalArguments(), request)
   File "/home/jim/z3/3/src/zope/publisher/publish.py", line 113, in mapply
     return debug_call(object, args)
   File "/home/jim/z3/3/src/zope/publisher/publish.py", line 119, in debug_call
     return object(*args)
   File "/home/jim/z3/3/src/zope/app/browser/container/adding.py", line 158, in action
     factory = zapi.getFactory(self, type_name)
   File "/home/jim/z3/3/src/zope/component/__init__.py", line 162, in getFactory
     return getService(context, Factories).getFactory(name)
   File "/home/jim/z3/3/src/zope/component/factory.py", line 68, in getFactory
     raise ComponentLookupError(name)
ComponentLookupError: zope.CaseInsensitiveFolder

----------------------------------------------------------------------
Ran 74 tests in 68.563s

FAILED (errors=1)

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From stephan.richter at tufts.edu  Wed Feb 18 08:58:04 2004
From: stephan.richter at tufts.edu (Stephan Richter)
Date: Wed Feb 18 08:58:34 2004
Subject: [Zope3-dev] Re: [I18nAndL10nInComponents] nice!
In-Reply-To: <20040131022656EST@dev.zope.org>
References: <20040131022656EST@dev.zope.org>
Message-ID: <200402180858.04987.stephan.richter@tufts.edu>

On Saturday 31 January 2004 02:26, simon wrote:
> Thank you Stephan, this was very helpful. i18nextract.py seems to work
> great for Zope 2 products also. I had to add missing # characters to
> multi-line Defaults in the .pot.

Michael,

it is strange that you had to add comment characters. This is definitely a 
bug. Can you be more specific?

Thanks.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From srichter at cosmos.phy.tufts.edu  Wed Feb 18 09:42:25 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Wed Feb 18 09:42:49 2004
Subject: [Zope3-dev] Re: Separate presentation packages
In-Reply-To: <1077034347.8519.5.camel@hortus>
References: <402FA0DB.1030406@zope.com> <4031ECCF.1020104@zope.com>
	<1077034347.8519.5.camel@hortus>
Message-ID: <200402180942.25896.srichter@cosmos.phy.tufts.edu>

On Tuesday 17 February 2004 11:12, Lex Berezhny wrote:
> > ? ? modfoo/*.pt (template modules)
> > ? ? modfoo/*.jpg (images)
> > ? ? configure.zcml
> >
> > And I think that this provides less separation than we should have.
>
> Why can't *.pt and *.jpg go into the browser directory? I have not
> developed Zope3 products yet, but from looking in zope3 Products CVS I
> can see that bugtracker has all of its *.pt files in the browser
> directory.

They usually do, but if you have a tiny product with only one template or 
icon, then it is not worth creating a browser package. But for big projects 
like the bug tracker, you should definitely create a package and leave the 
data files and templates there.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From garrett at mojave-corp.com  Wed Feb 18 09:55:52 2004
From: garrett at mojave-corp.com (Garrett Smith)
Date: Wed Feb 18 09:51:59 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes (repost)
Message-ID: <FB37E9B9E9354A4788F1B322E4AAD1D82182@server1.mojave.local>

I don't know what's up with gmane, but I don't think this made it to the
list...

Philipp von Weitershausen wrote:

> Stephan Richter wrote:
>
>> The reason we suggested folder and folder_web in the first place was
to make it easier to develop new UIs. And this in turn was born from the
problem that it was not easy for us to deactivate the browser ZCML in a
package. Therefore, I would really like to go back to
>>
>> folder
>> folder/browser
>
>
>
> It is what we have now and we have said more than once that we don't
like it, because:
>
> a) It would making browser code optional harder. When you install
'folder', you get the browser junk with it, no matter whether you want
it or not.


>From CVS, yes. But I don't see the problem here. If it's that important
to give 'consumers' a choice of UI or no-UI, create distributions as
appropriate.

> b) It doesn't emphasize separation of application and browser code
enough.


The folder/folder_browser goes too far and breaks the very real and
meaningful dependency of folder.browser on folder. These are not sibling
packages.

I just don't see how a browser subpackage doesn't effectively separate
the browser code. It's in a separate package, it's separate, what? :-)

> c) It does not flatten the hierarchy enough. We will end up with
browser subpackages again.


Circular argument :-)

> What we really want is something like "separate but close". Being
increasingly sceptical of my own suggestion, I think Jim's concept is
the closest one to that doctrine, even though I still dislike the usage
of the underscore and not being able to make proper use of Python
namespaces. In that respect, I have great sympathy for Garret's and
Roger's opinion. I draw a different conclusion, though.
>
>> and provide a ZCML way of saying
>>
>  > <disable>
>  >   <include package="folder.browser" />
>  > </disable>
>
>>
>> This way, if you you develop a new UI you can just declare
>>
>  > <disable>
>  >   <include package="folder.browser" />
>  > </disable>
>  > <include package="srichter.folder.browser" />
>
> I think that is not nearly as clear as simply adding or removing a
line from products.zcml or whereever the numerous packages in zope.app
will be configured from.


So, what's wrong with this:

  <configure>

    <include package="folder" />
    <include package="folder.browser" />

  </configure>

 -- Garrett

From garrett at mojave-corp.com  Wed Feb 18 09:56:33 2004
From: garrett at mojave-corp.com (Garrett Smith)
Date: Wed Feb 18 09:52:36 2004
Subject: [Zope3-dev] Re: Separate presentation packages (repost)
Message-ID: <FB37E9B9E9354A4788F1B322E4AAD1D82183@server1.mojave.local>

Another repost...

Stephan Richter wrote:

> On Tuesday 17 February 2004 04:42, Jim Fulton wrote:
>
>>> Why is that a problem?
>>
>>
>> Maybe I should have asked you why you thought your ideas might make
>> packaging easier. :)
>>
>> The problem is that, AFAIK, distutils doesn;t support installing
>> subpackages.
>
>
>
> I think we should not worry about distutils limitations at this point.

+1

I know Jim wants to flush out some issues here, but this topic warrants
its own list.

Seriously, this is a hard, hard topic. I'm surprised there's this much
energy being spent on improving distutils when Zope X3 1.0 on the table.

 -- Garrett 

From garrett at mojave-corp.com  Wed Feb 18 09:57:03 2004
From: garrett at mojave-corp.com (Garrett Smith)
Date: Wed Feb 18 09:53:07 2004
Subject: [Zope3-dev] Re: Separate presentation packages
Message-ID: <FB37E9B9E9354A4788F1B322E4AAD1D82184@server1.mojave.local>

Another repost...

Jim Fulton wrote:

> plus:
>
>    modfoo/*.pt (template modules)
>    modfoo/*.jpg (images)
>    configure.zcml
>
> And I think that this provides less separation than we should have.


Per the nontrivial UI clause, these files should go into the browser
package:

  modfoo/browser/*.pt
  modfoo/browser/*.jpg
  modfoo/browser/configure.zcml

> People who *just* want to focus on presentation need to sort it
> out from the other code.  People who just want the application code
> have all this extra browser code.
> Jim
>

I think there's agreement on the separation of presentation logic from
interfaces and implementations.

I've seen three salient arguments for modfoo_browser:

1 - Flattens the package hierarchy

2 - Gives developers/users more flexibility in 'getting' 'stuff' (i.e.
when you 'get' modfoo, you don't automatically 'get' the browser code)

3 - Makes it easier to plug in new UI

Re flattening, I'm in the "deep hierarchies bad" camp. But using
underscores to flatten goes too far. As I pointed out before, this
argument could be applied to flatten everything. Seriously, we'd only do
this if there was a really, really compelling reason, no?

Re the second point, I think we're confusing package structure with
software distribution. The term 'get' is loaded (thus quoted) - what you
'get' depends on what's been packaged and for whom.

If someone wants to package their modfoo to decouple the UI from the
core, create two packages (RPM, source dist, etc.).

But we're talking about CVS here. As Jim pointed out, CVS should not be
the packaging/distribution mechanism. But the modfoo_browser proposal
does exactly that, per argument two above.

Re argument 3, I'm still not getting it. I've plugged in ooodles of new
UI over existing Zope 3 application logic/content using skins. If I
wanted to totally replace the existing Zope 3 UI, I'd create my own
distribution that didn't ship/use the 'browser' packages. I'm looking at
the same exact options with 'modfoo_browser', am I not?

 -- Garrett

From srichter at cosmos.phy.tufts.edu  Wed Feb 18 09:59:23 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Wed Feb 18 09:59:44 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <40324523.8070003@zope.com>
References: <402F90E3.3040303@zope.com> <40322453.2000209@infrae.com>
	<40324523.8070003@zope.com>
Message-ID: <200402180959.23383.srichter@cosmos.phy.tufts.edu>

On Tuesday 17 February 2004 11:45, Jim Fulton wrote:
> >> <disable>
> >> ?<include package="folder.browser" />
> >> </disable>
> >> <include package="srichter.folder.browser" />
> >>
> >> In my opinion this is much more sane than anything that we have
> >> discussed concerning this branch of the debate.
> >> ?
> >
> > +1
> >
> > This looks like a good idea.
>
> Yup. In fact, it was proposed some time ago:
>
> ? ?http://dev.zope.org/Zope3/ZCMLEnhancements
>
> It's on the todo list, although probably after X3.0.

If we go this route for package distribution and replacement of default 
configuration, I think this one just went to the top of the priority 
list. :-) Would it be really this hard to do? When disabling, you simply go 
through the actions created by the include and remove them from the action 
list. So you subtract instead of adding.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From jim at zope.com  Wed Feb 18 10:14:55 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Feb 18 10:15:06 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <200402180959.23383.srichter@cosmos.phy.tufts.edu>
References: <402F90E3.3040303@zope.com> <40322453.2000209@infrae.com>
	<40324523.8070003@zope.com>
	<200402180959.23383.srichter@cosmos.phy.tufts.edu>
Message-ID: <4033816F.6010301@zope.com>

Stephan Richter wrote:
> On Tuesday 17 February 2004 11:45, Jim Fulton wrote:
> 
>>>><disable>
>>>> <include package="folder.browser" />
>>>></disable>
>>>><include package="srichter.folder.browser" />
>>>>
>>>>In my opinion this is much more sane than anything that we have
>>>>discussed concerning this branch of the debate.
>>>> 
>>>
>>>+1
>>>
>>>This looks like a good idea.
>>
>>Yup. In fact, it was proposed some time ago:
>>
>>   http://dev.zope.org/Zope3/ZCMLEnhancements
>>
>>It's on the todo list, although probably after X3.0.
> 
> 
> If we go this route for package distribution and replacement of default 
> configuration, I think this one just went to the top of the priority 
> list. :-)

I don't see why.

 > Would it be really this hard to do?

No, but the to do list is still quite big.

 > When disabling, you simply go
> through the actions created by the include and remove them from the action 
> list. So you subtract instead of adding.

Yes, I think so.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From srichter at cosmos.phy.tufts.edu  Wed Feb 18 10:26:58 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Wed Feb 18 10:27:21 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <40324C28.5080301@infrae.com>
References: <4031E820.9000302@zope.com> <4032362C.3060704@zope.com>
	<40324C28.5080301@infrae.com>
Message-ID: <200402181026.58220.srichter@cosmos.phy.tufts.edu>

On Tuesday 17 February 2004 12:15, Martijn Faassen wrote:
> > +1. ?The configuration metadata in a typical setup.py can *never* be
> > introspected, for intsance, short of writing bytecode hacks to pick
> > apart the arguments passed to setup().
>
> +1 too.

+1

> >> I'm certainly -1 on using XML for this, and I don't have a problem
> >> with using Python syntax. ?But the single file approach has got to go.
> >
> > -1 for Python syntax; ?Turing-completeness is a *disadvantage* in a
> > configuration language (e.g., why is ZCML not in Python? ?why ZConfig?)
>
> +1 to not using Python for configuration languages. Python is of course
> convenient on the short run, but I suspect will be harder on the long
> run. If packages were already explicitly declarative some of the
> problems Phillip Eby mentions would not have been an issue.

+1. I think we could use ZConfig for example; people know  the format and it 
was exactely developed for stuff like this.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From pje at telecommunity.com  Wed Feb 18 11:25:08 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed Feb 18 11:24:23 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <1077044900.21652.117.camel@athlon>
References: <40324D38.9020808@weitershausen.de> <402F90E3.3040303@zope.com>
	<c0rr12$2qa$1@sea.gmane.org> <4031E922.9060706@zope.com>
	<4031F6D0.60303@infrae.com> <1077026360.1886.10.camel@athlon>
	<4032256C.10800@infrae.com> <1077028819.1886.26.camel@athlon>
	<40323082.6000605@weitershausen.de>
	<1077034019.21652.18.camel@athlon>
	<40324D38.9020808@weitershausen.de>
Message-ID: <5.1.0.14.0.20040218111716.0385ebe0@mail.telecommunity.com>

At 02:08 PM 2/17/04 -0500, Chris McDonough wrote:
>On Tue, 2004-02-17 at 12:19, Philipp von Weitershausen wrote:
> > For example Windows people lose. Also, when you add new files, rename
> > them, refactor etc., you do not only have to make sure you get it right
> > in the revision control system, now you also have a symlink tree to take
> > care of...
>
>Look, let's face it.  The number of Zope core developers that a) use
>Windows, b) don't use Cygwin under Windows to develop Zope core and c)
>own Visual C++ to be able to compile the requisite Zope C extensions is
>pretty small, probably nearing 1 (*cough* Tim *cough* ;-).

Well, so far virtually all my Zope X3 contributions are to ZConfig, so I'm 
not sure whether that counts.

But I *don't* use Cygwin Python, even though I use the mingw32 tools to 
compile.  So, symlinks still don't actually work for my setup.


>Most Windows people install from binary, period.  And there's Cygwin,
>which does symlinks just fine.  If people want to use Windows sans
>Cygwin to develop Zope core, that's fine; they just need to copy the
>files they change in the installed copy back into the source tree
>manually and check them in.  The amount of people we would lose to such
>a hardship is... zero.  Really.  The teeming throng of Windows people
>here are free to stand up and prove me wrong. ;-)

Well, you won't lose me, but I'll most definitely be annoyed.  :)


>Having a one-to-one relationship between a CVS checkout and a runnable
>copy of Zope promotes the interdependency problem.  This is because
>there is no way to capture the intent of dependencies within the tree
>itself; newcomers to the software see the tree as one huge package.

Which is why we want per-package metadata.


>For example, in Zope 2, everyone knows that ZPublisher should probably
>be able to depend on ZServer, but not vice versa.

Whaaaa???  IMO, absolutely not.  I use Zope 2 ZPublisher without ZServer, 
and I can't see any possible reason ZPublisher should depend on 
ZServer.  None whatsoever.  Zip.  Nada.  As for the inverse, I don't know 
and don't care because I don't use ZServer.


>Now, distutils doesn't have the ability to spell dependencies right
>now.  But at least it should be possible to group certain packages
>together into "superpackages" which are maintained separately from one
>other.  The proposed "foo" and "foo_browser" package set represents such
>a superpackage.  Other superpackages may exist.  I'm just asserting that
>the CVS tree be represented in terms of these superpackages rather than
>in terms of how they should be laid out in an installed version.

IMO, your use case here can be solved by *repository* symlinks.  For 
example, PEAK's CVS area symlinks in the 'protocols' package directory of 
PyProtocols in order to bundle it in the PEAK "superpackage".


From pje at telecommunity.com  Wed Feb 18 11:12:30 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed Feb 18 11:26:56 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <1077036821.21647.44.camel@athlon>
References: <4032448D.2060207@zope.com> <402F90E3.3040303@zope.com>
	<c0rr12$2qa$1@sea.gmane.org> <4031E922.9060706@zope.com>
	<4031F6D0.60303@infrae.com> <1077026360.1886.10.camel@athlon>
	<4032448D.2060207@zope.com>
Message-ID: <5.1.0.14.0.20040218111007.03050420@mail.telecommunity.com>

At 11:53 AM 2/17/04 -0500, Chris McDonough wrote:
>On Tue, 2004-02-17 at 11:42, Jim Fulton wrote:
>
> > No, as I stated in my preproposal notes, it must be possible to
> > run from a CVS checkout.
>
>I don't know why, except for inertia.  This is a complete
>non-requirement from my perspective, for any Python software.

For some of us, it is an absolute requirement.  I've developed things both 
ways, and I would never go back to having to run an installer in order to 
develop.  <shudder>  And symlinks aren't available on Windows.  Despite the 
fact that I exclusively deploy software to Unix platforms, Windows is a 
much more convenient platform for me to use for the actual development.


From fred at zope.com  Wed Feb 18 12:09:53 2004
From: fred at zope.com (Fred Drake)
Date: Wed Feb 18 12:15:48 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <200402181026.58220.srichter@cosmos.phy.tufts.edu>
References: <4031E820.9000302@zope.com> <40324C28.5080301@infrae.com>
	<200402181026.58220.srichter@cosmos.phy.tufts.edu>
Message-ID: <200402181209.53508.fred@zope.com>

On Wednesday 18 February 2004 10:26 am, Stephan Richter wrote:
 > +1. I think we could use ZConfig for example; people know  the format
 > and it was exactely developed for stuff like this.

For a Zope-specific solution, we could use ZConfig as input for a 
setup.py-generator, and that would be cool.

This would not be a general solution, since ZConfig is not part of the 
Python standard library, and the setup.py can't use it because of the 
bootstrap issue.


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation


From chrism at plope.com  Wed Feb 18 12:29:45 2004
From: chrism at plope.com (Chris McDonough)
Date: Wed Feb 18 13:15:08 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <5.1.0.14.0.20040218111716.0385ebe0@mail.telecommunity.com>
References: <40324D38.9020808@weitershausen.de> <402F90E3.3040303@zope.com>
	<c0rr12$2qa$1@sea.gmane.org> <4031E922.9060706@zope.com>
	<4031F6D0.60303@infrae.com> <1077026360.1886.10.camel@athlon>
	<4032256C.10800@infrae.com> <1077028819.1886.26.camel@athlon>
	<40323082.6000605@weitershausen.de> <1077034019.21652.18.camel@athlon>
	<40324D38.9020808@weitershausen.de>
	<5.1.0.14.0.20040218111716.0385ebe0@mail.telecommunity.com>
Message-ID: <1077125385.21652.178.camel@athlon>

On Wed, 2004-02-18 at 11:25, Phillip J. Eby wrote:
> But I *don't* use Cygwin Python, even though I use the mingw32 tools to 
> compile.  So, symlinks still don't actually work for my setup.

Right.  Well, more Windows people around than I thought.  I really had
no idea, sorry!

> >Having a one-to-one relationship between a CVS checkout and a runnable
> >copy of Zope promotes the interdependency problem.  This is because
> >there is no way to capture the intent of dependencies within the tree
> >itself; newcomers to the software see the tree as one huge package.
> 
> Which is why we want per-package metadata.

Sometimes a "package" != a single Python package.  See ZODB, for
example.   I guess you could call this a "distribution", as it is made
up of several dependent Python packages.

This is handled now with repolinks, but this would seem to tie ZC to CVS
for the rest of time, or at least tie them to some version control
system that can also pretend to be a distribution system for the rest of
time.  Subversion doesn't seem to be able to do it, dunno about Arch or
Perforce or Bitkeeper or whatever.  Maybe relying on CVS for the
foreseeable future is ok.  Shrug.

But even if they seem to work ok, repolinks have their issues that make
them completely unacceptable for the purpose of ensuring that packages
don't have inappropriate dependencies.  As an example, ZODB doesn't even
try to live independently of Zope anymore.  Instead, ZODB releases are
now tied to Zope releases, so everything moves in lockstep.  It was just
too hard for people to manage the CVS merging that needed to happen in
order for ZODB to have a real life of its own.  Maybe this is a process
fault, but the technology sure didn't help either.

Shouldn't a Zope release (or any software release) be composed of
specific release versions of its constituent packages instead of some
huge master package perpetually asserting ownership over those packages
via a CVS tag that indicates *its* release, if the constituent packages
really are meant to be independently useful?

> >For example, in Zope 2, everyone knows that ZPublisher should probably
> >be able to depend on ZServer, but not vice versa.
> 
> Whaaaa???  IMO, absolutely not.

Ha.  I honestly have no real idea whether it should be able to or
shouldn't be able to!  Luckily, this actually proves the point I was
trying to make. ;)  There is no way to capture dependency intent without
grouping dependent packages into pure container "superpackages" or
having some sort of dependency system.  The dependency system is more
important than the superpackage use case, really, but I was trying to
service Martijn F's use case of wanting to version "foo" and
"browser_foo" together where each is a separate Python package with the
superpackage use case.

OK, I'm really out of time now, but since folks are dismissing the idea
out of hand, I did need to defend it. ;-)

- C



From mgedmin at b4net.lt  Wed Feb 18 13:49:49 2004
From: mgedmin at b4net.lt (Marius Gedminas)
Date: Wed Feb 18 13:52:14 2004
Subject: [Zope3-dev] Functional test failure: insensitivefolder
In-Reply-To: <403346E7.40509@zope.com>
References: <403346E7.40509@zope.com>
Message-ID: <20040218184949.GA22247@perlas>

On Wed, Feb 18, 2004 at 06:05:11AM -0500, Jim Fulton wrote:
> p3 test.py -f
> Running functional tests from /home/jim/z3/3
> Parsing ftesting.zcml
> Error in test testAddCasInsensitiveFolder 
> (zope.products.demo.insensitivefolder.ftests.TestCaseInsensitiveFolder)
> Traceback (most recent call last):
<...>
> ComponentLookupError: zope.CaseInsensitiveFolder

Someone recently changed ftesting.zcml and it no longer includes
products.zcml.  Make sure your products_ftesting.zcml contains the
following line:

  <include package="zope.products.demo.insensitivefolder"/>

e.g. by doing 'cp products_ftesting.zcml.in product_ftesting.zcml' or
'rm products_ftesting.zcml'.


It would be nice if there was a way to figure out which products had
their ZCML configurations included in products_ftesting.zcml.  Then the
test runner could automatically skip functional tests for those products
who hadn't.

Marius Gedminas
-- 
Press any key to continue, or any other key to cancel.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20040218/015f6d11/attachment.bin
From simon at joyful.com  Wed Feb 18 19:08:02 2004
From: simon at joyful.com (Simon Michael)
Date: Wed Feb 18 19:08:10 2004
Subject: [Zope3-dev] i18nextract issue (Re: [I18nAndL10nInComponents] nice!)
In-Reply-To: <200402180858.04987.stephan.richter@tufts.edu>
References: <20040131022656EST@dev.zope.org>
	<200402180858.04987.stephan.richter@tufts.edu>
Message-ID: <c10up3$rvc$1@sea.gmane.org>

> it is strange that you had to add comment characters. This is definitely a 
> bug. Can you be more specific?

Yes. IIRC, i18nextract generated something like::

  #: i/skins/zwiki_plone/editform.pt:205
  # Default: ""
  "If you are unsure of which format to use, just select Plain\n"
  "             Text and type the document as you usually do."

which I needed to change to::

  #: i/skins/zwiki_plone/editform.pt:205
  # Default: ""
  #"If you are unsure of which format to use, just select Plain\n"
  #"             Text and type the document as you usually do."

to keep msgfmt happy.

-Simon


From dev at projekt01.ch  Wed Feb 18 19:56:52 2004
From: dev at projekt01.ch (Roger ineichen)
Date: Wed Feb 18 19:58:08 2004
Subject: AW: [Zope3-dev] Re: Packaging pre-proposal/notes, Windows and symlinks
In-Reply-To: <1077125385.21652.178.camel@athlon>
Message-ID: <000a01c3f683$45d76ac0$1e63a8c0@projekt01.local>

-C wrote:
> > to
> > compile.  So, symlinks still don't actually work for my setup.
> 
> Right.  Well, more Windows people around than I thought.  I 
> really had no idea, sorry!

btw.
We work with symlink under windows. That's just a 
question of the right tool.

The windows file system supports symlinks like linux,
but there's no tool in the windows installation
for to manage that. You have to use third party tools. 

If anybody is interessted in; go to:
http://www.nedprod.com/programs/Win32/SymLink/
it's open source under GNU license.

regard
Roger Ineichen

> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org http://mail.zope.org/mailman/listinfo/zope3-dev
> 


From philipp at weitershausen.de  Tue Feb 17 12:23:40 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Thu Feb 19 04:29:42 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <4032362C.3060704@zope.com>
References: <4031E820.9000302@zope.com>	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>	<200402131703.07139.fred@zope.com>	<402D4DAF.10502@zope.com>	<200402131816.59402.fred@zope.com>	<1076969043.23662.42.camel@localhost.localdomain>	<4031E820.9000302@zope.com>	<403218E8.5040104@interlink.com.au>	<5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>
	<4032362C.3060704@zope.com>
Message-ID: <40324E1C.2050406@weitershausen.de>

Tres Seaver wrote:
>>> I know, for instance, that in my perfect world, there wouldn't be little
>>> dinky text files (or xml crud) required - this stuff _can_ be 
>>> expressed in Python, and I'd prefer that it is.
>>
>> I'm certainly -1 on using XML for this, and I don't have a problem 
>> with using Python syntax.  But the single file approach has got to go.
> 
> -1 for Python syntax;  Turing-completeness is a *disadvantage* in a 
> configuration language (e.g., why is ZCML not in Python?  why ZConfig?)
> 
> WRT the format, I am agnostic about the spelling, but anti-NIH suggests 
> that we should adopt a widely-supported parseable format:
> 
>   - ConfigParser style INI files (order can't matter, some restrictions
>     on spelling section and key names).

+1

>   - An XML dialect of some sort (we should be looking to how Debian and
>     RPM are spelling the XML variants of their package specification
>     files).

I find more and more people who are increasingly sceptical of ZCML, 
mostly because it's XML. They would really prefer a simpler style. 
ZConfig is very popular among them. I personally think using an 
XML-variant can have its advantages when it comes to parsing, 
validation, editing (-> relaxNG schema, etc.), transforming etc. But 
simplicity counts, too... "Simple is better than complex".

Philipp


From philipp at weitershausen.de  Thu Feb 19 04:44:06 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Thu Feb 19 04:38:23 2004
Subject: [Zope3-dev] removing CustomWidget backward compatability
Message-ID: <c12049$v05$1@sea.gmane.org>

Hi all,

just letting you know that I'm about to remove the CustomWidget backward 
compatability. CustomWidget was renamed CustomWidgetFactory a month ago; 
backward compatability was promised to be kept for a month.

In case you're using CustomWidget, simply replace the term everywhere in 
your source code with 'CustomWidgetFactory' and it should run again.

Philipp



From ZENAWNHOKPOTUV at i-55.com  Thu Feb 19 04:42:05 2004
From: ZENAWNHOKPOTUV at i-55.com (Marianne Adkins)
Date: Thu Feb 19 04:42:12 2004
Subject: [Zope3-dev] absolute lowest moving costs here
Message-ID: <GPRUTASRVCWUWFHKUPKTLAITS@dapa.com>

An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/zope3-dev/attachments/20040219/4e7cfcd5/attachment.html
From faassen at infrae.com  Thu Feb 19 07:47:41 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Thu Feb 19 07:46:25 2004
Subject: [Zope3-dev] Re: Separate presentation packages (repost)
In-Reply-To: <FB37E9B9E9354A4788F1B322E4AAD1D82183@server1.mojave.local>
References: <FB37E9B9E9354A4788F1B322E4AAD1D82183@server1.mojave.local>
Message-ID: <4034B06D.4070403@infrae.com>

Garrett Smith wrote:

>Another repost...
>
>Stephan Richter wrote:
>
>  
>
>>
>>I think we should not worry about distutils limitations at this point.
>>    
>>
>
>+1
>
>I know Jim wants to flush out some issues here, but this topic warrants
>its own list.
>
>Seriously, this is a hard, hard topic. I'm surprised there's this much
>energy being spent on improving distutils when Zope X3 1.0 on the table.
>
>  
>
I agree, though I also would like to point out that this is *exactly* 
why distutils is not improving very quickly. Everybody is obviously far 
more motivated to improve their own projects than worried about 
improving distutils.

Regards,

Martijn


From jeremy at zope.com  Thu Feb 19 10:25:48 2004
From: jeremy at zope.com (Jeremy Hylton)
Date: Thu Feb 19 10:29:29 2004
Subject: [Zope3-dev] Re: Packaging pre-proposal/notes
In-Reply-To: <1077044900.21652.117.camel@athlon>
References: <402F90E3.3040303@zope.com> <c0rr12$2qa$1@sea.gmane.org>
	<4031E922.9060706@zope.com> <4031F6D0.60303@infrae.com>
	<1077026360.1886.10.camel@athlon> <4032256C.10800@infrae.com>
	<1077028819.1886.26.camel@athlon> <40323082.6000605@weitershausen.de>
	<1077034019.21652.18.camel@athlon> <40324D38.9020808@weitershausen.de>
	<1077044900.21652.117.camel@athlon>
Message-ID: <1077204348.26936.12.camel@localhost.localdomain>

On Tue, 2004-02-17 at 14:08, Chris McDonough wrote:
> On Tue, 2004-02-17 at 12:19, Philipp von Weitershausen wrote:
> > For example Windows people lose. Also, when you add new files, rename 
> > them, refactor etc., you do not only have to make sure you get it right 
> > in the revision control system, now you also have a symlink tree to take 
> > care of...
> 
> Look, let's face it.  The number of Zope core developers that a) use
> Windows, b) don't use Cygwin under Windows to develop Zope core and c)
> own Visual C++ to be able to compile the requisite Zope C extensions is
> pretty small, probably nearing 1 (*cough* Tim *cough* ;-).

Well, two, at least.

Jeremy



From jim at zope.com  Thu Feb 19 13:11:11 2004
From: jim at zope.com (Jim Fulton)
Date: Thu Feb 19 13:11:21 2004
Subject: [Zope3-dev] Re: Separate presentation packages: Not :(
In-Reply-To: <402FA0DB.1030406@zope.com>
References: <402FA0DB.1030406@zope.com>
Message-ID: <4034FC3F.3060604@zope.com>


The response to my proposal to have parallel, rather than nested
application and presentation packages has been overwhelmingly negative.
I'll bow to this sentiment, but, as Chris said: "the idea seems all but
stillborn anyway given the reaction of most people.  They will be sorry,
but that's the way it goes. ;-)"

:)

So, we'll move to a very flat organization of zope.app where
most things will be subpackages of zope.app that contain both
application and presentation logic.  Often the presentation
support will be in subpackages:

as in:

zope/
      app/
          folder/
                  __init__.py
                  folder.py
                  configure.zcml
                  tests.py
                  browser/
                          __init__.py
                          browser.py
                          configure.zcml
                          folder.gif
                          tests.py

Other times, the presentation will not be in a separate subpackage,
as in:

zope/
      app/
          folder/
                  __init__.py
                  folder.py
                  configure.zcml
                  browser.py
                  browser.zcml
                  folder.gif
                  tests/
                        test_folder.py
                        test_browser.py

The good news is that,since presentation components are not persistent,
this it will be easy to change our mind when we realize we have erred. :)

Jim

Jim Fulton wrote:
> 
> I sent this earlier in response in another thread, but didn't
> get any response.  I'd be happy to assume no one disagrees
> and accept silence as assent, but, I thought this would be more
> controversal and a terser version got -1's before, so, here it is
> again.  :)
> 
> I think that continueing to separate presentations has a number
> of advantages:
> 
> - It *does* make iteasier for people who just want to modify
>   presentations to find them.
> 
> - It makes it clearer that presentatations are pluggable and how
> 
> - It enforces the separation of presentation and application code
> 
> - If we don't separate presentation into separate packages, some
>   will create presentation-specific subpackages anyway.
> 
> The disadvantages of separate subpackages are:
> 
> - More packages, some of which are very small
> 
> - More navigation, but the navigation is simple under the new
>   shallow organization.  For example, if I'm in foo and I want
>   to get to the directory with the browser code, I only have to
>   cd to ../foo_browser, which isn't so bad.
> 
> I think that the advantages of separating the presentation code far 
> outweigh
> the disadvantages.
> 
> Note that we won't separate interface code except in the case of 
> "framework"
> packages that define pluggable frameworks with interfaces where there
> are expected to be multiple implemantations.
> 
> So, I feel rather strongly that we should have packages like:
> 
> folder
> folder_browser
> file
> file_browser
> 
> and so on. Note, again, that this separation is a good bit different
> than what we have now. The presentation code is *close* to the application
> code while still being separate.
> 
> Silence is assent. :)
> 
> Jim
> 


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org



From jim at zope.com  Thu Feb 19 13:19:09 2004
From: jim at zope.com (Jim Fulton)
Date: Thu Feb 19 13:19:14 2004
Subject: [Zope3-dev] Improving distutils (was Re: Separate presentation
	packages (repost))
In-Reply-To: <4034B06D.4070403@infrae.com>
References: <FB37E9B9E9354A4788F1B322E4AAD1D82183@server1.mojave.local>
	<4034B06D.4070403@infrae.com>
Message-ID: <4034FE1D.8060208@zope.com>

Martijn Faassen wrote:
> Garrett Smith wrote:
> 
>> Another repost...
>>
>> Stephan Richter wrote:
>>
>>  
>>
>>>
>>> I think we should not worry about distutils limitations at this point.
>>>   
>>
>>
>> +1
>>
>> I know Jim wants to flush out some issues here, but this topic warrants
>> its own list.
>>
>> Seriously, this is a hard, hard topic. I'm surprised there's this much
>> energy being spent on improving distutils when Zope X3 1.0 on the table.
>>
>>  
>>
> I agree, though I also would like to point out that this is *exactly* 
> why distutils is not improving very quickly. Everybody is obviously far 
> more motivated to improve their own projects than worried about 
> improving distutils.

Which is why we are going to try to improve distutils. :)

I get the impression that, aside from urgency, people are generally
pretty happy with the goals and vision given in:

   http://dev.zope.org/Zope3/Zope3PackagingProposal

So the main goal of the "Packaging pre-proposal"
discussion has been achieved. :)

We (Fred :) are going to spend some time implementing at least enough
to:

   - Flexibly create and install our own distributions

   - Build CVS checkouts, avoiding complex monolithic setup scripts

   - Create a PEP (or PEPs) to enhance distutils to do what we need

Further technical discussions will eventually move to Python's distutils
development mailing list.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org



From jim at zope.com  Thu Feb 19 13:19:09 2004
From: jim at zope.com (Jim Fulton)
Date: Thu Feb 19 13:19:18 2004
Subject: [Zope3-dev] Improving distutils (was Re: Separate presentation
	packages (repost))
In-Reply-To: <4034B06D.4070403@infrae.com>
References: <FB37E9B9E9354A4788F1B322E4AAD1D82183@server1.mojave.local>
	<4034B06D.4070403@infrae.com>
Message-ID: <4034FE1D.8060208@zope.com>

Martijn Faassen wrote:
> Garrett Smith wrote:
> 
>> Another repost...
>>
>> Stephan Richter wrote:
>>
>>  
>>
>>>
>>> I think we should not worry about distutils limitations at this point.
>>>   
>>
>>
>> +1
>>
>> I know Jim wants to flush out some issues here, but this topic warrants
>> its own list.
>>
>> Seriously, this is a hard, hard topic. I'm surprised there's this much
>> energy being spent on improving distutils when Zope X3 1.0 on the table.
>>
>>  
>>
> I agree, though I also would like to point out that this is *exactly* 
> why distutils is not improving very quickly. Everybody is obviously far 
> more motivated to improve their own projects than worried about 
> improving distutils.

Which is why we are going to try to improve distutils. :)

I get the impression that, aside from urgency, people are generally
pretty happy with the goals and vision given in:

   http://dev.zope.org/Zope3/Zope3PackagingProposal

So the main goal of the "Packaging pre-proposal"
discussion has been achieved. :)

We (Fred :) are going to spend some time implementing at least enough
to:

   - Flexibly create and install our own distributions

   - Build CVS checkouts, avoiding complex monolithic setup scripts

   - Create a PEP (or PEPs) to enhance distutils to do what we need

Further technical discussions will eventually move to Python's distutils
development mailing list.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From fred at zope.com  Thu Feb 19 14:11:39 2004
From: fred at zope.com (Fred Drake)
Date: Thu Feb 19 14:11:48 2004
Subject: [Zope3-dev] ZODB 3.3 coming to Zope 3
Message-ID: <200402191411.39870.fred@zope.com>

We're about to land the changes to Zope 3 so that it uses ZODB 3.3
instead of the abandoned ZODB 4.  We hope to make this change in CVS
tomorrow morning.

After the changes have been made in CVS, we'll send a note to this
list letting everyone know we're done.  At that point, you'll need to
run a conversion script on any existing databases you intend to use
with the updated software.

For the Eager...
----------------

If you just can't wait until tomorrow to test the new software, it's
possible to start playing with it today.  You will need to run several
CVS commands to piece it together; that will not be needed once the
announcement that we're done comes out.

Pick a place to create your working copy, and run these commands (for
Unix):

  $ cd /some/place/
  $ CVSROOT=:ext:cvs.zope.org:/cvs-repository
  $ export CVSROOT
  $ cvs checkout -r zope3-zodb3-devel-branch Zope3
  [...]
  $ cd Zope3/src/
  $ cvs checkout -r zope3-zodb3-devel-branch -d BTrees ZODB/src/BTrees
  [...]
  $ cvs checkout -r zope3-zodb3-devel-branch -d persistent 
ZODB/src/persistent
  [...]
  $ cvs checkout -r zope3-zodb3-devel-branch -d ZODB ZODB/src/ZODB
  [...]
  $ cd ..

You should now be able to build the compiled modules and run the
conversion script:

  $ python2.3 setup.py build_ext -i
  [...]
  $ PYTHONPATH=src python2.3 src/ZODB/zodb4/main.py Data.fs

This will move the existing ZODB 4 database to a backup file (the .fs
extension will be changed to .fs4; if the main file doesn't use the
.fs extension, .fs4 will simply be appended).

You can now start Zope 3 normally.


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation


From jim at zope.com  Thu Feb 19 09:19:21 2004
From: jim at zope.com (Jim Fulton)
Date: Thu Feb 19 14:19:49 2004
Subject: [Zope3-dev] Change focus of sprints
Message-ID: <4034C5E9.8070800@zope.com>


I'd like to change the focus of sprints a bit.  In the past,
sprints were used as a way to get people familiar with Zope 3.
Most people who came to sprints were Zope 3 newbies. As a result,
they were often not really prepared to do very substantive work.
Often people found sprints frustrating because the work was over their
heads.  Or, we had to come up with tasks that people could do based
solely on what they learned in the tutorial.  It's becoming harder
and harder to come up with tasks like that that actually help
the project.  The tutorial prepares people do do application
development for Zope 3, which is good. In the long run, that's the
kind of development most people will do.  Zope 3 itself, however,
needs some people to be able to contribute at a deeper level.

Most of the tasks on the road map for X3.0 are not application tasks.
Most of them are more like system tasks (core tasks)?  I think
X3.1 (or even 2.9) will have many deep (system/core) tasks as well.

The tutorial is now hand's on. It provides an opportunity to gain
experience building Zope 3 applications in a sprint-like setting,
with pair programming and unit tests.  I think we should use the
tutorial as the primary mechanism for letting people just learn
about Zope 3 development. An advantage of using the tutorial for
this is that participants don't need to be Zope contributors.

BTW, I continue to evolve the tutorial.  I've recently combined the
separate tutorial chapters and then split the steps up into separate
files. I've also added notes to the slides, to make them a bit more
self sufficient.  It may still not be possible for some or many people
to use the slides by themselves. <shrug>  New pdfs for the tutorial
can be found at:

   http://dev.zope.org/Zope3/ProgrammerTutorial

I'm having problems with Open Office that are preventing me from
checking in updates sources. Sigh.

So, for sprints, I'd like to shift the focus to "system" or "core"
development, at least for the sprints that I lead.  I'd like to
host some sprints that tackle deeper projects and that are attended
only by Zope 3 (or advanced Zope 2) development veterans.  These sprints
will *not* include tutorial presentations.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org



From jim at zope.com  Thu Feb 19 14:32:36 2004
From: jim at zope.com (Jim Fulton)
Date: Thu Feb 19 14:32:50 2004
Subject: [Zope3-dev] Please update CHANGES.txt when you make a notable
	change!
Message-ID: <40350F54.6010207@zope.com>


We need to get in the habit of updating doc/CHANGES.txt when we make
a notable change.  (I need to get in this habit too.)  If you've
any notable changes since Milestone 5, *please* add a brief
description to doc/CHANGES.txt.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From gary at modernsongs.com  Thu Feb 19 14:33:17 2004
From: gary at modernsongs.com (Gary Poster)
Date: Thu Feb 19 14:33:28 2004
Subject: [Zope3-dev] widget question: propertyNames/getValue
In-Reply-To: <402C00EA.7040708@modernsongs.com>
References: <FB37E9B9E9354A4788F1B322E4AAD1D880A4@server1.mojave.local>	<4025850C.5030901@zope.com>	<200402121707.06805.fred@zope.com>
	<402C00EA.7040708@modernsongs.com>
Message-ID: <40350F7D.3040908@modernsongs.com>



Gary Poster wrote:
> I'd really like a schema of the configurables, though, because then we 
> could make zcml do one of those "if I don't know the attribute I'll try 
> to see if the widget class's schema knows about it, and use it to cast 
> the zcml value" tricks.  You know, one of those.  :-)  So we could have
> <addform ...>
>   <widget class=".widgets.DatePicker" format="%Y-%m-%d" />
> </addform>
> 
> where format is cast as appropriate, as defined in the widget 
> configuration schema (ok, it's easy in this case, but you see what I 
> mean), and then CustomWidgetFactory is called with the class, setting 
> the format.
> 
> That would be nice.  Generating a view class on the file system just to 
> make my text field display at 50 characters wide feels overly heavy to me.
> 
> Gary

More thoughts on this, as we near the landing of Garrett's 
widget-geddon. :-)  I'm hoping to implement what I discuss here, so this 
is request for comments.

In line with what I said above, I'd like to be able to explicitly 
override labels in zcml too.

<addform ...>
   <widget class=".widgets.DualListWidget">
     <label id="available_items" value="Available Vehicles" />
     <label id="selected_items" value="Selected Vehicles" />
   </widget>
</addform>

This would let the zcml component of the message id extraction tool 
catch these sorts of changes.  Implementation-wise, my first take on 
this is to have a label dictionary as part of the widget interface...and 
this would also mean that every widget would have to get display text 
from this dictionary in order to play nicely.  Garrett, do you have any 
concerns?  Is this something you're already beginning to address? 
Anyone else?

(Thanks to Philipp and Jim for recently clarifying the ZCML message id 
story for me, btw :-)

Gary

From jim at zope.com  Thu Feb 19 14:47:58 2004
From: jim at zope.com (Jim Fulton)
Date: Thu Feb 19 14:48:11 2004
Subject: [Zope3-dev] Updated the to-do list
Message-ID: <403512EE.8000002@zope.com>


I just updated doc/TODO.txt and doc/TODOLATER.txt to push more things
after the X3.0 release.  If you think of other things that need to be done, '
please let me know.

If you want to volunteer to work on anything, please let me know. :)

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From garrett at mojave-corp.com  Thu Feb 19 14:52:59 2004
From: garrett at mojave-corp.com (Garrett Smith)
Date: Thu Feb 19 14:49:01 2004
Subject: [Zope3-dev] widgets and ZCML (was widget question:
	propertyNames/getValue)
Message-ID: <FB37E9B9E9354A4788F1B322E4AAD1D880AD@server1.mojave.local>

Gary Poster wrote:
> I'd like to be able to explicitly override labels in zcml too.
> 
> <addform ...>
>    <widget class=".widgets.DualListWidget">
>      <label id="available_items" value="Available Vehicles" />
>      <label id="selected_items" value="Selected Vehicles" />
>    </widget>
> </addform>
> 
> This would let the zcml component of the message id extraction tool
> catch these sorts of changes.  Implementation-wise, my first take on
> this is to have a label dictionary as part of the widget
> interface...and this would also mean that every widget would have to
> get display text from this dictionary in order to play nicely. 
> Garrett, do you have any concerns?  Is this something you're already
> beginning to address? Anyone else?

Given that we (will) have explicit interfaces/schemas for widgets, it
would be nice to generally support specifying widget settings in ZCML.
This opens up the more general topic of specifying schema in ZCML.

Btw, I don't follow your example above. If DualListWidget supports
multiple labels, I'd expect to see them in explicit fields:

  <widget class=".widgets.DualListWidget">
    <field name="availableItemsLabel">Available Vehicles</field>
    <field name="selectedItemsLabel">Selected Vehicles</field>
  </widget>

(This is a hypothetical format for specifying field values in ZCML -
lots of hand waiving at this point.)

I might be totally missing your point :-) but this is the sort of thing
I'm thinking about for widgets and ZCML. (Note also that specifying
schema in ZCML opens up world of other possibilities wrt content types
and whatever else uses schema.)

 -- Garrett

From gary at modernsongs.com  Thu Feb 19 15:33:24 2004
From: gary at modernsongs.com (Gary Poster)
Date: Thu Feb 19 15:33:34 2004
Subject: [Zope3-dev] Re: widgets and ZCML (was widget question:
	propertyNames/getValue)
In-Reply-To: <FB37E9B9E9354A4788F1B322E4AAD1D880AD@server1.mojave.local>
References: <FB37E9B9E9354A4788F1B322E4AAD1D880AD@server1.mojave.local>
Message-ID: <40351D94.8050100@modernsongs.com>



Garrett Smith wrote:
> Gary Poster wrote:
> 
>>I'd like to be able to explicitly override labels in zcml too.
>>
>><addform ...>
>>   <widget class=".widgets.DualListWidget">
>>     <label id="available_items" value="Available Vehicles" />
>>     <label id="selected_items" value="Selected Vehicles" />
>>   </widget>
>></addform>
>
...
>   <widget class=".widgets.DualListWidget">
>     <field name="availableItemsLabel">Available Vehicles</field>
>     <field name="selectedItemsLabel">Selected Vehicles</field>
>   </widget>
> 
> (This is a hypothetical format for specifying field values in ZCML -
> lots of hand waiving at this point.)
> 
> I might be totally missing your point :-) but this is the sort of thing
> I'm thinking about for widgets and ZCML. (Note also that specifying
> schema in ZCML opens up world of other possibilities wrt content types
> and whatever else uses schema.)

I think we are on the same page as far as goals, so cool.  :-)  So, 
since I think we agree, I'm dealing with details.

My proposed zcml was an attempt to leverage the current zcml machinery 
particularly in regards to i18n message ids.  What it comes down to is 
that we need to distinguish between non-message-id fields, which merely 
need to be cast in order to do what we want, and message-id fields, 
which nominally need casting but more importantly need to be findable by 
the i18n message-id extraction machinery.  We do that by specifying that 
an attribute is a message id in the zcml definition schema.

So, two takes that would handle this:

one...

<widget field="start_date"
   class=".widgets.DatePicker" format="%Y-%m-%d">
   <label id="format_description" value="Use Year-month-date" />
</widget>

two...

<widget field="start_date" class=".widgets.DatePicker"
   <property name="format" value="%Y-%m-%d" />
   <label id="format_description" value="Use Year-month-date" />
</widget>

Or similar variants (obviously I'm attribute-friendly and you're 
contents-friendly...I think zcml is ok with the contents approach but I 
forget how to do it...)

:-)

Gary

From srichter at cosmos.phy.tufts.edu  Thu Feb 19 15:43:30 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Thu Feb 19 15:50:22 2004
Subject: [Zope3-dev] Change focus of sprints
In-Reply-To: <4034C5E9.8070800@zope.com>
References: <4034C5E9.8070800@zope.com>
Message-ID: <200402191543.30986.srichter@cosmos.phy.tufts.edu>

On Thursday 19 February 2004 09:19, Jim Fulton wrote:
> So, for sprints, I'd like to shift the focus to "system" or "core"
> development, at least for the sprints that I lead. ?I'd like to
> host some sprints that tackle deeper projects and that are attended
> only by Zope 3 (or advanced Zope 2) development veterans. ?These sprints
> will *not* include tutorial presentations.

+1

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From philipp at weitershausen.de  Thu Feb 19 16:02:50 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Thu Feb 19 15:56:05 2004
Subject: [Zope3-dev] Re: removing CustomWidget backward compatability
In-Reply-To: <c12049$v05$1@sea.gmane.org>
References: <c12049$v05$1@sea.gmane.org>
Message-ID: <c137st$jj9$1@sea.gmane.org>

Philipp von Weitershausen wrote:
> Hi all,
> 
> just letting you know that I'm about to remove the CustomWidget backward 
> compatability. CustomWidget was renamed CustomWidgetFactory a month ago; 
> backward compatability was promised to be kept for a month.
> 
> In case you're using CustomWidget, simply replace the term everywhere in 
> your source code with 'CustomWidgetFactory' and it should run again.

Done, as there were, as expected, no complains.

Philipp



From philipp at weitershausen.de  Thu Feb 19 16:06:43 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Thu Feb 19 16:03:09 2004
Subject: [Zope3-dev] Packages moved from zope.products to zope.app
Message-ID: <c13846$k8s$1@sea.gmane.org>

Hi,

I just moved

- zope.products.statictree to zope.app.tree
- zope.products.apidoc to zope.app.apidoc

Please remove the correspondant import lines for those former products 
from your products.zcml. They are loaded by default now by means of 
zope/app/configure.zcml.

Philipp

P.S.: Note that browser views for statictree (zope.app.tree) have been 
refactored slightly.



From faassen at infrae.com  Thu Feb 19 18:35:52 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Thu Feb 19 18:35:56 2004
Subject: [Zope3-dev] Re: Improving distutils (was Re: Separate presentation
	packages (repost))
In-Reply-To: <4034FE1D.8060208@zope.com>
References: <FB37E9B9E9354A4788F1B322E4AAD1D82183@server1.mojave.local>	<4034B06D.4070403@infrae.com>
	<4034FE1D.8060208@zope.com>
Message-ID: <40354858.8070302@infrae.com>

Jim Fulton wrote:

>> I agree, though I also would like to point out that this is *exactly* 
>> why distutils is not improving very quickly. Everybody is obviously 
>> far more motivated to improve their own projects than worried about 
>> improving distutils.
>
>
> Which is why we are going to try to improve distutils. :)
>
That's of course great news. :)

> I get the impression that, aside from urgency, people are generally
> pretty happy with the goals and vision given in:
>
>   http://dev.zope.org/Zope3/Zope3PackagingProposal
>
No objections from me.

Regards,

Martijn


From faassen at infrae.com  Thu Feb 19 18:36:52 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Thu Feb 19 18:36:56 2004
Subject: [Zope3-dev] Re: Separate presentation packages: Not :(
In-Reply-To: <4034FC3F.3060604@zope.com>
References: <402FA0DB.1030406@zope.com> <4034FC3F.3060604@zope.com>
Message-ID: <40354894.8080604@infrae.com>

Jim Fulton wrote:

> The good news is that,since presentation components are not persistent,
> this it will be easy to change our mind when we realize we have erred. :)
>
Yay! :)

Regards,

Martijn


From philipp at weitershausen.de  Fri Feb 20 04:41:31 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Fri Feb 20 04:34:47 2004
Subject: [Zope3-dev] Re: Change focus of sprints
In-Reply-To: <4034C5E9.8070800@zope.com>
References: <4034C5E9.8070800@zope.com>
Message-ID: <4035D64B.9030204@weitershausen.de>

Jim Fulton wrote:
> BTW, I continue to evolve the tutorial.  I've recently combined the
> separate tutorial chapters and then split the steps up into separate
> files. I've also added notes to the slides, to make them a bit more
> self sufficient.  It may still not be possible for some or many people
> to use the slides by themselves. <shrug>  New pdfs for the tutorial
> can be found at:
> 
>   http://dev.zope.org/Zope3/ProgrammerTutorial
> 
> I'm having problems with Open Office that are preventing me from
> checking in updates sources. Sigh.

I just checked out Step 7 of the tutorial and it still uses CustomWidget 
instead of CustomWidgetFactory. I'd update the slides myself, but since 
they're not checked in, I thought I'd better let you know.

> So, for sprints, I'd like to shift the focus to "system" or "core"
> development, at least for the sprints that I lead.  I'd like to
> host some sprints that tackle deeper projects and that are attended
> only by Zope 3 (or advanced Zope 2) development veterans.  These sprints
> will *not* include tutorial presentations.

+1

When are the next sprints taking place? SprintSchedule doesn't say 
anything. For me, only sprints on European soil are of interest; will 
there be a EuroPython sprint?

Philipp


From faassen at infrae.com  Fri Feb 20 04:49:05 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Fri Feb 20 04:49:10 2004
Subject: [Zope3-dev] Re: Change focus of sprints
In-Reply-To: <4035D64B.9030204@weitershausen.de>
References: <4034C5E9.8070800@zope.com> <4035D64B.9030204@weitershausen.de>
Message-ID: <4035D811.2050609@infrae.com>

Philipp von Weitershausen wrote:

> When are the next sprints taking place? SprintSchedule doesn't say 
> anything. For me, only sprints on European soil are of interest; will 
> there be a EuroPython sprint?


There is definitely room to have a EuroPython sprint, it's just someone 
needs to organize it. :)

Regards,

Martijn


From faassen at infrae.com  Fri Feb 20 04:54:08 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Fri Feb 20 04:54:14 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <40324E1C.2050406@weitershausen.de>
References: <4031E820.9000302@zope.com>	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>	<200402131703.07139.fred@zope.com>	<402D4DAF.10502@zope.com>	<200402131816.59402.fred@zope.com>	<1076969043.23662.42.camel@localhost.localdomain>	<4031E820.9000302@zope.com>	<403218E8.5040104@interlink.com.au>	<5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>	<4032362C.3060704@zope.com>
	<40324E1C.2050406@weitershausen.de>
Message-ID: <4035D940.2000700@infrae.com>

Philipp von Weitershausen wrote:

> I find more and more people who are increasingly sceptical of ZCML, 
> mostly because it's XML. They would really prefer a simpler style.


I don't think this is increasing; people have been railing against the 
evil XML-ish ZCML from the start.

> ZConfig is very popular among them. I personally think using an 
> XML-variant can have its advantages when it comes to parsing, 
> validation, editing (-> relaxNG schema, etc.), transforming etc. But 
> simplicity counts, too... "Simple is better than complex".


As long as the format is regular it is possible to write a tool to 
convert to XML and back. Using XML natively has its benefits as you 
don't have to write these tools, and people don't have to learn new 
syntax rules.

Those people who don't like ZCML because it's too verbose can design 
their own better 'compact' syntax and convert to ZCML from that. I'd be 
very curious to see those efforts and may even participate. Those who 
don't like ZCML as it's not Python..well, they'll have to change their 
minds. :)

Regards,

Martijn


From philipp at weitershausen.de  Fri Feb 20 05:19:04 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Fri Feb 20 05:31:15 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <4035D940.2000700@infrae.com>
References: <4031E820.9000302@zope.com>	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>	<200402131703.07139.fred@zope.com>	<402D4DAF.10502@zope.com>	<200402131816.59402.fred@zope.com>	<1076969043.23662.42.camel@localhost.localdomain>	<4031E820.9000302@zope.com>	<403218E8.5040104@interlink.com.au>	<5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>	<4032362C.3060704@zope.com>
	<40324E1C.2050406@weitershausen.de> <4035D940.2000700@infrae.com>
Message-ID: <4035DF18.4090709@weitershausen.de>

Martijn Faassen wrote:
>> I find more and more people who are increasingly sceptical of ZCML, 
>> mostly because it's XML. They would really prefer a simpler style.
> 
> I don't think this is increasing; people have been railing against the 
> evil XML-ish ZCML from the start.

Yes, but I talk to more and more Zope2 veterans about Zope3 and ZCML and 
they are quite sceptical. Thus, the amount of ZCML scepticism is 
increasing proportionally to the number of people learning about Zope3 :)

>> ZConfig is very popular among them. I personally think using an 
>> XML-variant can have its advantages when it comes to parsing, 
>> validation, editing (-> relaxNG schema, etc.), transforming etc. But 
>> simplicity counts, too... "Simple is better than complex".
> 
> As long as the format is regular it is possible to write a tool to 
> convert to XML and back. Using XML natively has its benefits as you 
> don't have to write these tools, and people don't have to learn new 
> syntax rules.

... and the whole zope.configuration machinery conveniently uses 
SAXParser w/o reinventing the wheel.

> Those people who don't like ZCML because it's too verbose can design 
> their own better 'compact' syntax and convert to ZCML from that. I'd be 
> very curious to see those efforts and may even participate.

I'm thinking about ZConfig <-> ZCML and/or ConfigParser (ini) <-> ZCML. 
Though I would much rather like the backend of zope.configuration to be 
pluggable. It is currently very XML-specific...

Philipp



From andreas at andreas-jung.com  Fri Feb 20 05:37:52 2004
From: andreas at andreas-jung.com (Andreas Jung)
Date: Fri Feb 20 05:37:56 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <4035DF18.4090709@weitershausen.de>
References: <4031E820.9000302@zope.com>
	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<200402131703.07139.fred@zope.com>	<402D4DAF.10502@zope.com>
	<200402131816.59402.fred@zope.com>
	<1076969043.23662.42.camel@localhost.localdomain>
	<4031E820.9000302@zope.com>	<403218E8.5040104@interlink.com.au>
	<5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>
	<4032362C.3060704@zope.com>	<40324E1C.2050406@weitershausen.de>
	<4035D940.2000700@infrae.com> <4035DF18.4090709@weitershausen.de>
Message-ID: <2147483647.1077277071@[192.168.0.102]>



--On Freitag, 20. Februar 2004 11:19 Uhr +0100 Philipp von Weitershausen 
<philipp@weitershausen.de> wrote:

> Martijn Faassen wrote:
>>> I find more and more people who are increasingly sceptical of ZCML,
>>> mostly because it's XML. They would really prefer a simpler style.
>>
>> I don't think this is increasing; people have been railing against the
>> evil XML-ish ZCML from the start.
>
> Yes, but I talk to more and more Zope2 veterans about Zope3 and ZCML and
> they are quite sceptical. Thus, the amount of ZCML scepticism is
> increasing proportionally to the number of people learning about Zope3 :)
>

Talking as a Z2 veteran: I agree with Philipp. Reading and writing ZCML is 
not
very much convinient. Computers are designed to read and write XML
but not humans. ZCML is too verbose and it is hard get see at one glance
what's inside a configuration file..it's too verbose.

-aj




From faassen at infrae.com  Fri Feb 20 06:27:23 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Fri Feb 20 06:26:19 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <2147483647.1077277071@[192.168.0.102]>
References: <4031E820.9000302@zope.com>	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>	<200402131703.07139.fred@zope.com>	<402D4DAF.10502@zope.com>	<200402131816.59402.fred@zope.com>	<1076969043.23662.42.camel@localhost.localdomain>	<4031E820.9000302@zope.com>	<403218E8.5040104@interlink.com.au>	<5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>	<4032362C.3060704@zope.com>	<40324E1C.2050406@weitershausen.de>	<4035D940.2000700@infrae.com>
	<4035DF18.4090709@weitershausen.de>
	<2147483647.1077277071@[192.168.0.102]>
Message-ID: <4035EF1B.9070608@infrae.com>

Andreas Jung wrote:

>> Yes, but I talk to more and more Zope2 veterans about Zope3 and ZCML 
>> and they are quite sceptical. Thus, the amount of ZCML scepticism is 
>> increasing proportionally to the number of people learning about 
>> Zope3 :)
>>
> Talking as a Z2 veteran: I agree with Philipp. Reading and writing 
> ZCML is not very much convinient. Computers are designed to read and 
> write XML but not humans. ZCML is too verbose and it is hard get see 
> at one glance what's inside a configuration file..it's too verbose.
>
Actually, XML *was* designed for human readability; that's the vaunted 
benefit of it over binary formats. XML is of course a compromise between 
computer-readability and human-readability. One can argue how good this 
compromise really was; some people like it better than others. And 
arguably XML is not very human *writable*.

Anyway, my point elsewhere in the thread is that if someone wants a more 
compact syntax/semantics, that means that some language design needs to 
take place, ideally by the people who are feeling the need. :).

Unless you want Python, in which case I disagree with you -- a 
declarative language is good and switching to Python would make things 
worse. I think the current example of distutils setup.py being Python 
and making essential information inaccessible programmatically is a good 
example of what can go wrong with this. Of course it's *possible* to 
write a Python-based system that's declarative, but it's not going to be 
automatic.

I also agree that ZCML could become more human readable and writeable. I 
spent some time some months ago coming up with a Relax NG schema in an 
analysis of ZCML. I had the hope I'd get some inspiration for a compact 
syntax, or at least a less attribute-intensive XML, but so far nothing 
has happened there yet. :)

So, if you're starting a project to improve ZCML, let me know.

In the mean time, let me try to make sure to remind you all we got some 
benefits by using XML, though:

  * at least superficially familiar syntax to most people.

  * encourages us to think in declarative terms.

  * unicode out of the box.

  * namespaces for extensibility out of the box.

  * easy to write parsers and generators.

  * since it's XML, other tools easily applicable; Relax NG schema 
definition language. nxml mode for emacs, etc.

  *  we didn't reinvent the wheel and came up with our own (grotty) 
syntax right away.

  * since we have a fairly formally defined declarative system, we can 
fairly easily transform any new compact syntax to ZCML and back again. 
We can therefore gracefully migrate if we come up with a new, better system.

I know though that this discussion won't convince anybody; XML isn't 
very well liked in the Python community. :)

Regards,

Martijn


From srichter at cosmos.phy.tufts.edu  Fri Feb 20 07:02:03 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Fri Feb 20 07:02:24 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <4035DF18.4090709@weitershausen.de>
References: <4031E820.9000302@zope.com> <4035D940.2000700@infrae.com>
	<4035DF18.4090709@weitershausen.de>
Message-ID: <200402200702.03581.srichter@cosmos.phy.tufts.edu>

On Friday 20 February 2004 05:19, Philipp von Weitershausen wrote:
> > Those people who don't like ZCML because it's too verbose can design
> > their own better 'compact' syntax and convert to ZCML from that. I'd be
> > very curious to see those efforts and may even participate.
>
> I'm thinking about ZConfig <-> ZCML and/or ConfigParser (ini) <-> ZCML.
> Though I would much rather like the backend of zope.configuration to be
> pluggable. It is currently very XML-specific...

No, it is not. nothing in zope.configuration.config depends on XML. You can 
completely replace xmlconfig with something else.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From srichter at cosmos.phy.tufts.edu  Fri Feb 20 07:19:54 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Fri Feb 20 07:20:14 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <4035EF1B.9070608@infrae.com>
References: <4031E820.9000302@zope.com> <2147483647.1077277071@[192.168.0.102]>
	<4035EF1B.9070608@infrae.com>
Message-ID: <200402200719.54570.srichter@cosmos.phy.tufts.edu>

On Friday 20 February 2004 06:27, Martijn Faassen wrote:
> I know though that this discussion won't convince anybody; XML isn't
> very well liked in the Python community. :)

I am personally not a big fan of XML either, but I like it for exactely the 
purposes we use it in ZCML (and for remote communication, like XML-RPC). I do 
not think that some other declarative language will do much better.

ZCML:

<adapter
    for="zope.app.messageboard.interfaces.IMessage"
    provides="zope.app.messageboard.interfaces.IMailSubscription"
    class="zope.app.messageboard.message.MailSubscription" 
    />

INI/ZConfig-like:

[adapter]
    for=zope.app.messageboard.interfaces.IMessage
    provides=zope.app.messageboard.interfaces.IMailSubscription
    class=zope.app.messageboard.message.MailSubscription
\required empty line

Now, I have no clue why people would think the latter is less verbose. The 
same amount of lines and the latter is only shorter by the quotation marks 
and one forward slash. This makes it worth using XML and all the advantages 
Martijn listed.

I have said this many times before: I think that the issue is not ZCML itself, 
but the task it tries to accomplish is not an easy one and requires a lot of 
information. I think that there is nothing verbose about ZCML; we do not even 
use XML elements extensively, but place everything in attributes, which is, 
if I remember correctly from Martijns previous mails, not very XMLish 
anyways. And honestly, when reading an Apache configuration file I am always 
overwhelmed, and that has nothing to do with the way it is written. I imagine 
that newbies feel the same way coming to Zope 3. But in the end, ZCML is 
really your friend. It tells you quickly how the system hangs together and 
can be used. I think it is just something that people will need to learn.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From andreas at andreas-jung.com  Fri Feb 20 07:37:07 2004
From: andreas at andreas-jung.com (Andreas Jung)
Date: Fri Feb 20 07:37:13 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <200402200719.54570.srichter@cosmos.phy.tufts.edu>
References: <4031E820.9000302@zope.com>
	<2147483647.1077277071@[192.168.0.102]> <4035EF1B.9070608@infrae.com>
	<200402200719.54570.srichter@cosmos.phy.tufts.edu>
Message-ID: <2147483647.1077284227@[192.168.0.102]>



--On Freitag, 20. Februar 2004 7:19 Uhr -0500 Stephan Richter 
<srichter@cosmos.phy.tufts.edu> wrote:

> On Friday 20 February 2004 06:27, Martijn Faassen wrote:
>> I know though that this discussion won't convince anybody; XML isn't
>> very well liked in the Python community. :)
>
> I am personally not a big fan of XML either, but I like it for exactely
> the  purposes we use it in ZCML (and for remote communication, like
> XML-RPC). I do  not think that some other declarative language will do
> much better.
>
> ZCML:
>
> <adapter
>     for="zope.app.messageboard.interfaces.IMessage"
>     provides="zope.app.messageboard.interfaces.IMailSubscription"
>     class="zope.app.messageboard.message.MailSubscription"
>     />
>
> INI/ZConfig-like:
>
> [adapter]
>     for=zope.app.messageboard.interfaces.IMessage
>     provides=zope.app.messageboard.interfaces.IMailSubscription
>     class=zope.app.messageboard.message.MailSubscription
> \required empty line
>
> Now, I have no clue why people would think the latter is less verbose.
> The  same amount of lines and the latter is only shorter by the quotation
> marks  and one forward slash. This makes it worth using XML and all the
> advantages  Martijn listed.

The INI file is not less verbose...The point is that it contains three times
the same prefix which is hard to read and write. Make it shorter e.g. like:

[adapter]
     prefix=zope.app.messageboard
     for=interfaces.IMessage
     provides=interfaces.IMailSubscription
    class=message.MailSubscription

At least this is much more eye-friendly. Try to find a solution to avoid
redundancy. Zope3 contains lots of configuration file and properly
lot of redundant strings that can be avoided somehow.  I don't know
very much about the impacts of the shorter notation but the information
represented in a configfile should be easy to read.

-aj





From srichter at cosmos.phy.tufts.edu  Fri Feb 20 07:46:10 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Fri Feb 20 07:46:30 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <2147483647.1077284227@[192.168.0.102]>
References: <4031E820.9000302@zope.com>
	<200402200719.54570.srichter@cosmos.phy.tufts.edu>
	<2147483647.1077284227@[192.168.0.102]>
Message-ID: <200402200746.10277.srichter@cosmos.phy.tufts.edu>

On Friday 20 February 2004 07:37, Andreas Jung wrote:
> The INI file is not less verbose...The point is that it contains three
> times the same prefix which is hard to read and write. Make it shorter e.g.
> like:
>
> [adapter]
> ? ? ?prefix=zope.app.messageboard
> ? ? ?for=interfaces.IMessage
> ? ? ?provides=interfaces.IMailSubscription
> ? ? class=message.MailSubscription
>
> At least this is much more eye-friendly. Try to find a solution to avoid
> redundancy. Zope3 contains lots of configuration file and properly
> lot of redundant strings that can be avoided somehow. ?I don't know
> very much about the impacts of the shorter notation but the information
> represented in a configfile should be easy to read.

Well, this was an example. ZCML does actually better than that even. If the 
Adapter registration is inside the zope.app.messageboard package (which it 
would be, then you have only

<adapter
 ? ? for=".interfaces.IMessage"
 ? ? provides=".interfaces.IMailSubscription"
 ? ? class=".message.MailSubscription"
 ? ? />

Also, the problem you point out is not XML-specific. I would also like to know 
places where we have unnecessary redundancy (preferably file and line). (Note 
that many people choose to use the full Python path, but they do not have 
to.)

BTW, there is currently a lot of redundancy, since interfaces and browser code 
do not live in the same package as the code. Once we implement the new 
structure, a lot (I think 90-95%) of the full Python paths in ZCML will/can 
go away.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From jtk at yahoo.com  Fri Feb 20 08:56:47 2004
From: jtk at yahoo.com (Jeff Kowalczyk)
Date: Fri Feb 20 08:55:19 2004
Subject: [Zope3-dev] Re: Re: More thoughts on packaging
References: <4031E820.9000302@zope.com>
	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>
	<200402131703.07139.fred@zope.com> <402D4DAF.10502@zope.com>
	<200402131816.59402.fred@zope.com>
	<1076969043.23662.42.camel@localhost.localdomain>
	<4031E820.9000302@zope.com> <403218E8.5040104@interlink.com.au>
	<5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>
	<4032362C.3060704@zope.com> <40324E1C.2050406@weitershausen.de>
	<4035D940.2000700@infrae.com>
Message-ID: <pan.2004.02.20.13.56.46.89898@yahoo.com>

Martijn Faassen wrote:
> Those people who don't like ZCML because it's too verbose can design their
> own better 'compact' syntax and convert to ZCML from that. I'd be very
> curious to see those efforts and may even participate. Those who don't
> like ZCML as it's not Python..well, they'll have to change their minds. :)

YAML?

http://yaml.org/spec/

Due to information model differences (http://yaml.org/spec/#id2489434),
YAML would probably most directly translate to the results of parsed ZCML,
rather than XML-format ZCML source. YAML can also serve as an
alternative ZConfig syntax, easier to generate programmatically. And
as a metadata format for distutils improvements, etc. Massive potential in
a minimal syntax.



From srichter at cosmos.phy.tufts.edu  Fri Feb 20 09:03:00 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Fri Feb 20 09:03:19 2004
Subject: [Zope3-dev] Re: Re: More thoughts on packaging
In-Reply-To: <pan.2004.02.20.13.56.46.89898@yahoo.com>
References: <4031E820.9000302@zope.com> <4035D940.2000700@infrae.com>
	<pan.2004.02.20.13.56.46.89898@yahoo.com>
Message-ID: <200402200903.00195.srichter@cosmos.phy.tufts.edu>

On Friday 20 February 2004 08:56, Jeff Kowalczyk wrote:
> YAML?
>
> http://yaml.org/spec/

I looked through some examples and I most say it looks very cryptic, so 
perlish. I doubt Python programmers like that syntax. I would stay with ZCML.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From gary at modernsongs.com  Fri Feb 20 09:57:06 2004
From: gary at modernsongs.com (Gary Poster)
Date: Fri Feb 20 09:57:11 2004
Subject: [Zope3-dev] Re: Re: More thoughts on packaging
In-Reply-To: <200402200903.00195.srichter@cosmos.phy.tufts.edu>
References: <4031E820.9000302@zope.com>
	<4035D940.2000700@infrae.com>	<pan.2004.02.20.13.56.46.89898@yahoo.com>
	<200402200903.00195.srichter@cosmos.phy.tufts.edu>
Message-ID: <40362042.4000201@modernsongs.com>



Stephan Richter wrote:
> On Friday 20 February 2004 08:56, Jeff Kowalczyk wrote:
> 
>>YAML?
>>
>>http://yaml.org/spec/
> 
> 
> I looked through some examples and I most say it looks very cryptic, so 
> perlish. I doubt Python programmers like that syntax. I would stay with ZCML.

Hm.  I did the same and I liked it.  The bang is maybe a little 
off-putting but "< / >" etc. are arguably worse.  YAML might be a winner.

My open-mindedness established as bona fides ;-), I'll now agree with 
Stephan that exploring YAML, ZConfig, and so on for the setup feels like 
a post-X3.0 task to me.  But one worth keeping in mind.

Gary

From anthony at interlink.com.au  Fri Feb 20 10:09:35 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Fri Feb 20 10:09:46 2004
Subject: [Zope3-dev] Re: Re: More thoughts on packaging
In-Reply-To: <pan.2004.02.20.13.56.46.89898@yahoo.com>
References: <4031E820.9000302@zope.com>	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>	<200402131703.07139.fred@zope.com>
	<402D4DAF.10502@zope.com>	<200402131816.59402.fred@zope.com>	<1076969043.23662.42.camel@localhost.localdomain>	<4031E820.9000302@zope.com>
	<403218E8.5040104@interlink.com.au>	<5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>	<4032362C.3060704@zope.com>
	<40324E1C.2050406@weitershausen.de>	<4035D940.2000700@infrae.com>
	<pan.2004.02.20.13.56.46.89898@yahoo.com>
Message-ID: <4036232F.7010701@interlink.com.au>

Jeff Kowalczyk wrote:
> Martijn Faassen wrote:
> 
>>Those people who don't like ZCML because it's too verbose can design their
>>own better 'compact' syntax and convert to ZCML from that. I'd be very
>>curious to see those efforts and may even participate. Those who don't
>>like ZCML as it's not Python..well, they'll have to change their minds. :)
> 
> 
> YAML?
> 
> http://yaml.org/spec/

YAML feels very very hackish, like an accumulation of features rather 
than a well-designed language. The magic line noise formatting makes me 
recoil in horror - I find reST annoying enough in that respect, and so 
don't use it much at all. Trying to do what is essentially a programing 
task (packaging) in YAML seems like a sure path to insanity.

As far as the original point (which was 'packaging systems') I can't see 
that an XML syntax is going to win many friends in Python land, and so 
unless the Zope community wants to maintain their own packaging system, 
a compromise on something that's a bit easier to write may be needed.

As far as the claim that a Python-based system "isn't declarative" - 
well, that's obviously a fault with the current distutils approach, not 
a problem with python itself. Being in Python has allowed people to put 
little bits and pieces in their setup.py's to do things "a little 
differently" -- unless you're proposing to build something that will be 
all things to all people, you're going to be making a much more limited 
system than what we have now. Note that, for instance, RPM's 'spec' 
format has many possibilities to call out to a shell to do things that 
are "a little bit different", so we're not the only ones who've needed 
this flexibility.

Anthony

-- 
Anthony Baxter     <anthony@interlink.com.au>
It's never too late to have a happy childhood.

From shane at zope.com  Fri Feb 20 10:10:00 2004
From: shane at zope.com (Shane Hathaway)
Date: Fri Feb 20 10:10:46 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <4035D940.2000700@infrae.com>
References: <40324E1C.2050406@weitershausen.de> <4035D940.2000700@infrae.com>
Message-ID: <Pine.LNX.4.50.0402200942350.410-100000@shane.zope.com>

On Fri, 20 Feb 2004, Martijn Faassen wrote:

> Those people who don't like ZCML because it's too verbose can design 
> their own better 'compact' syntax and convert to ZCML from that. I'd be 
> very curious to see those efforts and may even participate. Those who 
> don't like ZCML as it's not Python..well, they'll have to change their 
> minds. :)

I'll note that our configuration strategy for Zope 2 has always been to
configure things through the web.  This mode of operation is highly
effective for complex things.  A GUI prompts for information, while a
written language requires some level of fluency to be effective.

If Zope 3 acquires a good GUI for creating ZCML, the syntax of ZCML won't
matter as much.  XML behind the GUI would actually be an asset, since XML
is regular enough for a GUI to change it.  Therefore, if we intend to
include a ZCML GUI in Zope 3, I'll be happier with the direction Zope 3 is
heading.

Shane

From dev at projekt01.ch  Fri Feb 20 10:33:34 2004
From: dev at projekt01.ch (Roger ineichen)
Date: Fri Feb 20 10:34:54 2004
Subject: AW: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <Pine.LNX.4.50.0402200942350.410-100000@shane.zope.com>
Message-ID: <000f01c3f7c6$e8b30ee0$1e63a8c0@projekt01.local>

>Shane Hathaway wrote:
> ...
> If Zope 3 acquires a good GUI for creating ZCML, the syntax 
> of ZCML won't matter as much.  XML behind the GUI would 
> actually be an asset, since XML is regular enough for a GUI 
> to change it.  Therefore, if we intend to include a ZCML GUI 
> in Zope 3, I'll be happier with the direction Zope 3 is heading.

1+ 

Just another idea,
And if we misconfigure a .zcml we should have a 
"starting the last working version" mechanism 
if Zope3 doesn't start after changing a .zcml. 

regards
Roger Ineichen

> Shane
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org http://mail.zope.org/mailman/listinfo/zope3-dev
> 


From shane at zope.com  Fri Feb 20 10:41:22 2004
From: shane at zope.com (Shane Hathaway)
Date: Fri Feb 20 10:42:00 2004
Subject: AW: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <000f01c3f7c6$e8b30ee0$1e63a8c0@projekt01.local>
References: <000f01c3f7c6$e8b30ee0$1e63a8c0@projekt01.local>
Message-ID: <Pine.LNX.4.50.0402201038240.410-100000@shane.zope.com>

On Fri, 20 Feb 2004, Roger ineichen wrote:

> >Shane Hathaway wrote:
> > ...
> > If Zope 3 acquires a good GUI for creating ZCML, the syntax 
> > of ZCML won't matter as much.  XML behind the GUI would 
> > actually be an asset, since XML is regular enough for a GUI 
> > to change it.  Therefore, if we intend to include a ZCML GUI 
> > in Zope 3, I'll be happier with the direction Zope 3 is heading.
> 
> 1+ 

Thanks.

> Just another idea,
> And if we misconfigure a .zcml we should have a 
> "starting the last working version" mechanism 
> if Zope3 doesn't start after changing a .zcml. 

That would be useful within the GUI, though Zope 3 itself shouldn't be
aware that functionality.  It should just trust the ZCML files.

Shane

From jim at zope.com  Fri Feb 20 11:07:33 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 20 11:07:45 2004
Subject: [Zope3-dev] ZCML
Message-ID: <403630C5.1090609@zope.com>


I just want to point out that any discussion of switching from
ZCML is pointless.  We aren't moving away from it any time soon,
if ever.

If anyone is serious about championing something else, they
need to create a working protype of Zope 3 that uses
the alternative syntax.  As Stephan pointed out, the ZCML
architecture should make it pretty easy to do an alternative
syntax.  If such a prototype existed and *worked*, then we could
look at it and see if it's really any better.

But, please don't waste effort on this before X3.0. There's
important work that has to be done before then and we need
all the constructive help we can get.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Fri Feb 20 12:29:55 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 20 12:31:04 2004
Subject: [Zope3-dev] ZODB 3.3 coming to Zope 3
In-Reply-To: <40363F6E.1010807@zope.com>
References: <200402191411.39870.fred@zope.com> <40363F6E.1010807@zope.com>
Message-ID: <40364413.1030601@zope.com>

Jim Fulton wrote:
> Fred Drake wrote:
> 
>> We're about to land the changes to Zope 3 so that it uses ZODB 3.3
>> instead of the abandoned ZODB 4.  We hope to make this change in CVS
>> tomorrow morning.
>>
>> After the changes have been made in CVS, we'll send a note to this
>> list letting everyone know we're done. 
> 
> 
> The changes to make Zope 3 use ZODB 3 have been checked in.

In a fresh checkout, I'm getting an error because ZEO isn't
there.  Don't know why we didn't see this before. We're looking
into it, but you can ignore this error for now.

Jim


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Fri Feb 20 12:10:06 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 20 12:34:03 2004
Subject: [Zope3-dev] ZODB 3.3 coming to Zope 3
In-Reply-To: <200402191411.39870.fred@zope.com>
References: <200402191411.39870.fred@zope.com>
Message-ID: <40363F6E.1010807@zope.com>

Fred Drake wrote:
> We're about to land the changes to Zope 3 so that it uses ZODB 3.3
> instead of the abandoned ZODB 4.  We hope to make this change in CVS
> tomorrow morning.
> 
> After the changes have been made in CVS, we'll send a note to this
> list letting everyone know we're done. 

The changes to make Zope 3 use ZODB 3 have been checked in.

We currently have both ZODB abd zodb packages, which will
break windows checkouts.  We are going to fix this by getting rid
of the zodb package. We'll send another note to let everyone know
when this is done.

If you have any code that imports from zodb, you will need to change
it to import from ZODB instead.

 > At that point, you'll need to
> run a conversion script on any existing databases you intend to use
> with the updated software.

Update Procedure
----------------

Use this procedure to update the software and convert databases:

1. Back up your databases (Data.fs* files).

2. Update the software using "cvs up -dP".

3. Re-build compiled modules:

    $ python2.3 setup.py build_ext -i

4. Run the conversion script for each FileStorage:

    $ PYTHONPATH=src python2.3 src/ZODB/zodb4/main.py Data.fs

This will move the existing ZODB 4 database to a backup file (the .fs
extension will be changed to .fs4; if the main file doesn't use the
.fs extension, .fs4 will simply be appended).

Jim (and Fred)

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From pw_lists at slinkp.com  Fri Feb 20 12:44:44 2004
From: pw_lists at slinkp.com (Paul Winkler)
Date: Fri Feb 20 12:44:50 2004
Subject: [Zope3-dev] Re: Change focus of sprints
In-Reply-To: <4035D64B.9030204@weitershausen.de>
References: <4034C5E9.8070800@zope.com> <4035D64B.9030204@weitershausen.de>
Message-ID: <20040220174444.GC1754@slinkp.com>

On Fri, Feb 20, 2004 at 10:41:31AM +0100, Philipp von Weitershausen wrote:
> When are the next sprints taking place? SprintSchedule doesn't say 
> anything.

www.pycon.org/dc2004

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's WILD SURGEON TECHNOLOGY!
(random hero from isometric.spaceninja.com)

From casey at zope.com  Fri Feb 20 11:24:05 2004
From: casey at zope.com (Casey Duncan)
Date: Fri Feb 20 12:50:20 2004
Subject: [Zope3-dev] Re: ZCML
References: <403630C5.1090609@zope.com>
Message-ID: <20040220112405.24168fd9.casey@zope.com>

On Fri, 20 Feb 2004 11:07:33 -0500
Jim Fulton <jim@zope.com> wrote:

> 
> I just want to point out that any discussion of switching from
> ZCML is pointless.  We aren't moving away from it any time soon,
> if ever.
> 
> If anyone is serious about championing something else, they
> need to create a working protype of Zope 3 that uses
> the alternative syntax.  As Stephan pointed out, the ZCML
> architecture should make it pretty easy to do an alternative
> syntax.  If such a prototype existed and *worked*, then we could
> look at it and see if it's really any better.

I think many are missing the issue with ZCML by debating about how the
information is spelled. No format will likely IMO be significantly
easier or harder to grok at a glance than the existing one. ZCML holds a
lot of the complexity of the system, IMO this complexity is much harder
to fully grasp than the spelling of the XML.

Shane points out that a GUI would be helpful. In many ways that task is
aided by the fact the ZCML is XML. In fact I would suggest that what
might contemplate initially is a browser which simply transforms the XML
(gasp ;^) into HTML for presentation. This would be read-only, but it
would allow for a "fly-over" view of the system config. In fact this
wouldn't even need to be dynamic at first. A tool could be written to
generate static (gasp again ;^) HTML on the file system (ok, now I'm
getting really loopy) which you could point your browser at.

Now of course this doesn't directly solve the writing problem, but at
least improves the "get the big picture" problem, and might give you a
clue where to write something at least.
 
> But, please don't waste effort on this before X3.0. There's
> important work that has to be done before then and we need
> all the constructive help we can get.

If we are to improve the configuration of Zope I would suggest that we
look at ways to remove redundancy and increase the clarity of the
spelling we already have. This has already been done several times, and
I think it has achieved success. As I use ZCML myself I find it much
less opaque, and I also have seen ways it could be made more clear.

Another meta-task might be to think about what configuration is likely
to be commonly overridden and try to disentangle it from declarations
that only Jim would ever change ;^). I'm sure this is already done to an
extent, but continuing to iteratively reorganize things (like we have
with the modules and packages) could greatly help the transparency of
the configuration on the whole.

-Casey


From pw_lists at slinkp.com  Fri Feb 20 12:56:20 2004
From: pw_lists at slinkp.com (Paul Winkler)
Date: Fri Feb 20 12:56:24 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <Pine.LNX.4.50.0402200942350.410-100000@shane.zope.com>
References: <40324E1C.2050406@weitershausen.de> <4035D940.2000700@infrae.com>
	<Pine.LNX.4.50.0402200942350.410-100000@shane.zope.com>
Message-ID: <20040220175620.GD1754@slinkp.com>

On Fri, Feb 20, 2004 at 10:10:00AM -0500, Shane Hathaway wrote:
> On Fri, 20 Feb 2004, Martijn Faassen wrote:
> 
> > Those people who don't like ZCML because it's too verbose can design 
> > their own better 'compact' syntax and convert to ZCML from that. I'd be 
> > very curious to see those efforts and may even participate. Those who 
> > don't like ZCML as it's not Python..well, they'll have to change their 
> > minds. :)
> 
> I'll note that our configuration strategy for Zope 2 has always been to
> configure things through the web.  This mode of operation is highly
> effective for complex things.  A GUI prompts for information, while a
> written language requires some level of fluency to be effective.

OTOH, I've found the TTW configuration for zope 2 leads to maintenance
nightmares when you have multiple systems (e.g. dev, staging, and
production).  However, this is an artifact of the implementation -
TTW configuration in zope 2 usually consists of setting properties
and security on objects, which cannot easily be separated from 
the object's data or contents.  Try to duplicate a complex 
CMF skin configuration without dragging along the contents
of the actual skin folders and you will see what I mean.
Or try to duplicate security settings for a folder without
copying the contents of the folder.

I hope that this will be much better in z3, due to much configuration
being separated into ZCML, and things like properties/annotations 
hopefully being serializable via the filesystem sync tools.
I dunno what TTW security management for z3 will look like, but 
it surely can't be any more difficult than z2 ;-)

-- 

Paul Winkler
http://www.slinkp.com


From jim at zope.com  Fri Feb 20 14:05:13 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 20 14:05:21 2004
Subject: [Zope3-dev] ZODB 3.3 coming to Zope 3
In-Reply-To: <40363F6E.1010807@zope.com>
References: <200402191411.39870.fred@zope.com> <40363F6E.1010807@zope.com>
Message-ID: <40365A69.9080408@zope.com>

Jim Fulton wrote:
> Fred Drake wrote:
> 
>> We're about to land the changes to Zope 3 so that it uses ZODB 3.3
>> instead of the abandoned ZODB 4.  We hope to make this change in CVS
>> tomorrow morning.
>>
>> After the changes have been made in CVS, we'll send a note to this
>> list letting everyone know we're done. 
> 
> 
> The changes to make Zope 3 use ZODB 3 have been checked in.
> 
> We currently have both ZODB abd zodb packages, which will
> break windows checkouts.  We are going to fix this by getting rid
> of the zodb package. We'll send another note to let everyone know
> when this is done.
> 
> If you have any code that imports from zodb, you will need to change
> it to import from ZODB instead.
> 
>  > At that point, you'll need to
> 
>> run a conversion script on any existing databases you intend to use
>> with the updated software.
> 
> 
> Update Procedure
> ----------------
> 
> Use this procedure to update the software and convert databases:
> 
> 1. Back up your databases (Data.fs* files).
> 
> 2. Update the software using "cvs up -dP".
> 
> 3. Re-build compiled modules:
> 
>    $ python2.3 setup.py build_ext -i
> 
> 4. Run the conversion script for each FileStorage:
> 
>    $ PYTHONPATH=src python2.3 src/ZODB/zodb4/main.py Data.fs
> 
> This will move the existing ZODB 4 database to a backup file (the .fs
> extension will be changed to .fs4; if the main file doesn't use the
> .fs extension, .fs4 will simply be appended).

We had missed checking in the src/ZODB/zodb4 directory.

This is fixed now.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Fri Feb 20 14:06:09 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 20 14:06:17 2004
Subject: [Zope3-dev] ZODB 3.3 coming to Zope 3
In-Reply-To: <40364413.1030601@zope.com>
References: <200402191411.39870.fred@zope.com> <40363F6E.1010807@zope.com>
	<40364413.1030601@zope.com>
Message-ID: <40365AA1.4020903@zope.com>

Jim Fulton wrote:
> Jim Fulton wrote:
> 
>> Fred Drake wrote:
>>
>>> We're about to land the changes to Zope 3 so that it uses ZODB 3.3
>>> instead of the abandoned ZODB 4.  We hope to make this change in CVS
>>> tomorrow morning.
>>>
>>> After the changes have been made in CVS, we'll send a note to this
>>> list letting everyone know we're done. 
>>
>>
>>
>> The changes to make Zope 3 use ZODB 3 have been checked in.
> 
> 
> In a fresh checkout, I'm getting an error because ZEO isn't
> there.  Don't know why we didn't see this before. We're looking
> into it, but you can ignore this error for now.

Fixed.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Fri Feb 20 14:08:19 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 20 14:08:27 2004
Subject: [Zope3-dev] ZODB 3.3 coming to Zope 3
In-Reply-To: <40363F6E.1010807@zope.com>
References: <200402191411.39870.fred@zope.com> <40363F6E.1010807@zope.com>
Message-ID: <40365B23.2040206@zope.com>

Jim Fulton wrote:
> Fred Drake wrote:
> 
...

> Update Procedure
> ----------------
> 
> Use this procedure to update the software and convert databases:
> 
> 1. Back up your databases (Data.fs* files).
> 
> 2. Update the software using "cvs up -dP".
> 
> 3. Re-build compiled modules:
> 
>    $ python2.3 setup.py build_ext -i
> 
> 4. Run the conversion script for each FileStorage:
> 
>    $ PYTHONPATH=src python2.3 src/ZODB/zodb4/main.py Data.fs
> 
> This will move the existing ZODB 4 database to a backup file (the .fs
> extension will be changed to .fs4; if the main file doesn't use the
> .fs extension, .fs4 will simply be appended).

We just found another problem.  If your database has records
for object's whos class isn't around anymore, the script will
fail.

We'll fix this in an hour or two.

Jim


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jtk at yahoo.com  Fri Feb 20 14:20:07 2004
From: jtk at yahoo.com (Jeff Kowalczyk)
Date: Fri Feb 20 14:18:40 2004
Subject: [Zope3-dev] Re: Re: Re: More thoughts on packaging
References: <4031E820.9000302@zope.com> <4035D940.2000700@infrae.com>
	<pan.2004.02.20.13.56.46.89898@yahoo.com>
	<200402200903.00195.srichter@cosmos.phy.tufts.edu>
Message-ID: <pan.2004.02.20.19.20.06.159521@yahoo.com>

(getting one clarification in under the wire, deferring respectfully to
the wise alternatives=temporarilyPointless edict hereafter)

ZCML and ZConfig are the permanent standards, granted. Alternatives
shouldn't distract from necessary tasks, and shouldn't expect to replace
either standard. I suggest YAML as one possibility, when mention is
occasionally made that alternatives are of interest to some.

YAML is only a serialization language. The information model corresponds
to python's native data structures. For reasonable data it has reasonable
line noise, compared to other formats of equivalent capability. Compare
this example and its parsed result in python. Advanced features would add
line noise in exchange for de-serialization directly to specific types
(e.g. classes Invoice, Person, Address and Product, instead of strings).
If using those features, one can simplify or eliminate pre-serialization
and post-parse duties such as iterating over DOM elements or parsing
string values into specfic types.

If YAML had anything to do with packaging, it would be as an expression of
the metadata, not any imperative commands. Some of that metadata could be
(cross-platform) command objects, which could be managed properly by an
improved distutils, then the packaging format wouldn't have any directly
executed imperatives. Sort of like ebuilds, without the bare shell
scripting.

Because the information models are different, a direct YAML-ZCML mapping
is not worthwhile. However, YAML corresponding to parsed ZCML (and
ZConfig) data structures may be interesting, at an appropriate juncture in
Z3 development.

Until then, heeding reasoned warnings of pointlessness...


YAML Source, one unnamed document:

---
invoice: 34843
date   : 2001-01-23
bill-to: &id001
    given  : Chris
    family : Dumars
    address:
        lines: |
            458 Walkman Dr.
            Suite #292
        city    : Royal Oak
        state   : MI
        postal  : 48046
ship-to: *id001
product:
    - sku         : BL394D
      quantity    : 4
      description : Basketball
      price       : 450.00
    - sku         : BL4438H
      quantity    : 1
      description : Super Hoop
      price       : 2392.00
tax  : 251.42
total: 4443.52
comments:
    Late afternoon is best.
    Backup contact is Nancy
    Billsmer @ 338-4338.


Parsed structure using simple types, no explicit typing used, parser set
for no implicit typing (all scalars become strings), mapping order
preserved for readability:

{'invoice': '34843',
 'date': '2001-01-23',
 'bill-to':
    {'given': 'Chris',
     'family': 'Dumars',
     'address':
        {'city': 'Royal Oak',
         'lines': '458 Walkman Dr.\nSuite #292\n',
         'state': 'MI',
         'postal': '48046',}},
 'ship-to':
    {'given': 'Chris',
     'family': 'Dumars',
     'address':
        {'city': 'Royal Oak',
         'lines': '458 Walkman Dr.\nSuite #292\n',
         'state': 'MI',
         'postal': '48046',}},
 'product': [{'sku': 'BL394D',
              'quantity': '4',
              'description': 'Basketball',
              'price': '450.0'},
             {'sku': 'BL4438H',
              'quantity': '1',
              'description': 'Super Hoop',
              'price': '2392.00'}],
 'tax': '251.42',
 'total': '4443.52',
 'comments': 'Late afternoon is best. Backup contact is Nancy Billsmer @
 338-4338.\n'}



From jim at zope.com  Fri Feb 20 15:52:14 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 20 15:57:21 2004
Subject: [Zope3-dev] ZODB 3.3 coming to Zope 3
In-Reply-To: <40365B23.2040206@zope.com>
References: <200402191411.39870.fred@zope.com> <40363F6E.1010807@zope.com>
	<40365B23.2040206@zope.com>
Message-ID: <4036737E.3000104@zope.com>

Jim Fulton wrote:
> Jim Fulton wrote:
> 
>> Fred Drake wrote:
>>
> ...
> 
>> Update Procedure
>> ----------------
>>
>> Use this procedure to update the software and convert databases:
>>
>> 1. Back up your databases (Data.fs* files).
>>
>> 2. Update the software using "cvs up -dP".
>>
>> 3. Re-build compiled modules:
>>
>>    $ python2.3 setup.py build_ext -i
>>
>> 4. Run the conversion script for each FileStorage:
>>
>>    $ PYTHONPATH=src python2.3 src/ZODB/zodb4/main.py Data.fs
>>
>> This will move the existing ZODB 4 database to a backup file (the .fs
>> extension will be changed to .fs4; if the main file doesn't use the
>> .fs extension, .fs4 will simply be appended).
> 
> 
> We just found another problem.  If your database has records
> for object's whos class isn't around anymore, the script will
> fail.
> 
> We'll fix this in an hour or two.

OK, done.  The script now skips database records when
data cannot be unpickled due to import errors.

Jim


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From shane at zope.com  Fri Feb 20 15:58:37 2004
From: shane at zope.com (Shane Hathaway)
Date: Fri Feb 20 15:59:17 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <20040220175620.GD1754@slinkp.com>
References: <Pine.LNX.4.50.0402200942350.410-100000@shane.zope.com>
	<20040220175620.GD1754@slinkp.com>
Message-ID: <Pine.LNX.4.50.0402201544170.410-100000@shane.zope.com>

On Fri, 20 Feb 2004, Paul Winkler wrote:

> On Fri, Feb 20, 2004 at 10:10:00AM -0500, Shane Hathaway wrote:
> > I'll note that our configuration strategy for Zope 2 has always been to
> > configure things through the web.  This mode of operation is highly
> > effective for complex things.  A GUI prompts for information, while a
> > written language requires some level of fluency to be effective.
> 
> OTOH, I've found the TTW configuration for zope 2 leads to maintenance
> nightmares when you have multiple systems (e.g. dev, staging, and
> production).  However, this is an artifact of the implementation -
> TTW configuration in zope 2 usually consists of setting properties
> and security on objects, which cannot easily be separated from 
> the object's data or contents.  Try to duplicate a complex 
> CMF skin configuration without dragging along the contents
> of the actual skin folders and you will see what I mean.
> Or try to duplicate security settings for a folder without
> copying the contents of the folder.

I agree that's a problem.  I think that only means configurable tools need
a clean serialization format, and we need tools for importing/exporting
configurations.  We didn't know that (or we hadn't internalized it) when
CMF was being created.  Fortunately, we know it now. :-)

Shane

From faassen at infrae.com  Fri Feb 20 16:49:28 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Fri Feb 20 16:47:55 2004
Subject: [Zope3-dev] Re: Re: More thoughts on packaging
In-Reply-To: <4036232F.7010701@interlink.com.au>
References: <4031E820.9000302@zope.com>	<5.1.1.6.0.20040213145959.02a7d430@telecommunity.com>	<200402131703.07139.fred@zope.com>	<402D4DAF.10502@zope.com>	<200402131816.59402.fred@zope.com>	<1076969043.23662.42.camel@localhost.localdomain>	<4031E820.9000302@zope.com>	<403218E8.5040104@interlink.com.au>	<5.1.0.14.0.20040217093345.035c5780@mail.telecommunity.com>	<4032362C.3060704@zope.com>	<40324E1C.2050406@weitershausen.de>	<4035D940.2000700@infrae.com>	<pan.2004.02.20.13.56.46.89898@yahoo.com>
	<4036232F.7010701@interlink.com.au>
Message-ID: <403680E8.2080803@infrae.com>

Anthony Baxter wrote:

> As far as the claim that a Python-based system "isn't declarative" - 
> well, that's obviously a fault with the current distutils approach, 
> not a problem with python itself. 

Of course it's possible to write a system that allows you to express
things in a declarative way in Python. Then again, it's uncomfortably 
easy to escape from this, which makes it uncomfortably easy to *not* 
build a declarative way of configuring things and instead stay stuck 
with the current system. This is what happened with distutils (unless 
this discussion will result in it being fixed :).

Another issue with declarations in Python is that the only way to 
introspect it is when the programmer actually spent time designing and 
implementing an introspection API for whatever is declared. An 
independent declarative language can be processed and interpreted using 
external tools. If the declarative language happens to be expressed in 
XML, some of these tools are already there.

> Being in Python has allowed people to put little bits and pieces in 
> their setup.py's to do things "a little differently" -- unless you're 
> proposing to build something that will be all things to all people, 
> you're going to be making a much more limited system than what we have 
> now. 

A declarative system can point to Python code. Just look at ZCML. :)

> Note that, for instance, RPM's 'spec' format has many possibilities to 
> call out to a shell to do things that are "a little bit different", so 
> we're not the only ones who've needed this flexibility.

Agreed. It's just a question of what kind of flexibility, the 
*perspective* of aiming for a declarative style, and when it's too much 
-- the ultimate in flexibility is an empty directory where you can start 
writing Python code.

Regards,

Martijn


From faassen at infrae.com  Fri Feb 20 16:57:05 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Fri Feb 20 16:55:19 2004
Subject: [Zope3-dev] ZCML
In-Reply-To: <403630C5.1090609@zope.com>
References: <403630C5.1090609@zope.com>
Message-ID: <403682B1.1080500@infrae.com>

Jim Fulton wrote:

> I just want to point out that any discussion of switching from
> ZCML is pointless.  We aren't moving away from it any time soon,
> if ever.
>
> If anyone is serious about championing something else, they
> need to create a working protype of Zope 3 that uses
> the alternative syntax.  As Stephan pointed out, the ZCML
> architecture should make it pretty easy to do an alternative
> syntax.  

An easy alternative for the prototype would be to simply generate ZCML 
from whatever language is designed. Has a bunch of benefits; for 
instance you could check that whatever you generate complies with the 
ZCML Relax NG schema (presuming that is kept up to date :).

Note that I'm not serious about championing something else at this point 
in time. I think improvements are possible but a lot of thinking and 
designing will need to take place before that. And ZCML works pretty 
well, and is easy to evolve away from if someone comes up with something 
better.

Regards,

Martijn


From pw_lists at slinkp.com  Fri Feb 20 17:51:46 2004
From: pw_lists at slinkp.com (Paul Winkler)
Date: Fri Feb 20 17:51:50 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <Pine.LNX.4.50.0402201544170.410-100000@shane.zope.com>
References: <Pine.LNX.4.50.0402200942350.410-100000@shane.zope.com>
	<20040220175620.GD1754@slinkp.com>
	<Pine.LNX.4.50.0402201544170.410-100000@shane.zope.com>
Message-ID: <20040220225146.GC3129@slinkp.com>

On Fri, Feb 20, 2004 at 03:58:37PM -0500, Shane Hathaway wrote:
> > OTOH, I've found the TTW configuration for zope 2 leads to maintenance
> > nightmares when you have multiple systems (e.g. dev, staging, and
(snip)
> I agree that's a problem.  I think that only means configurable tools need
> a clean serialization format, and we need tools for importing/exporting
> configurations.  We didn't know that (or we hadn't internalized it) when
> CMF was being created.  Fortunately, we know it now. :-)

Yeah, a lot of the pieces of the puzzle exist. We have zsync.
CMF for zope 2 has a decent filesystem representation of properties, 
implemented by FSPropertyManager. We could do something similar
for annotations and use zsync with it. It will rock :-) 

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's CHICKEN NUGGET FROM MCDONALDS STRANGE!
(random hero from isometric.spaceninja.com)

From srichter at cosmos.phy.tufts.edu  Fri Feb 20 18:04:20 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Fri Feb 20 18:04:42 2004
Subject: [Zope3-dev] ZCML
In-Reply-To: <403682B1.1080500@infrae.com>
References: <403630C5.1090609@zope.com> <403682B1.1080500@infrae.com>
Message-ID: <200402201804.20591.srichter@cosmos.phy.tufts.edu>

On Friday 20 February 2004 16:57, Martijn Faassen wrote:
> An easy alternative for the prototype would be to simply generate ZCML
> from whatever language is designed. Has a bunch of benefits; for
> instance you could check that whatever you generate complies with the
> ZCML Relax NG schema (presuming that is kept up to date :).

We need to autogenerate it. When I developed docconfig.py I added all the 
necessary plumbing. Martijn, are you coming to PyCon 2004? It would be a nice 
side project. The only reason I have not developed the generator yet is that 
I did not fully understood relax ng.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From srichter at cosmos.phy.tufts.edu  Fri Feb 20 18:05:41 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Fri Feb 20 18:05:58 2004
Subject: [Zope3-dev] Re: More thoughts on packaging
In-Reply-To: <20040220225146.GC3129@slinkp.com>
References: <Pine.LNX.4.50.0402200942350.410-100000@shane.zope.com>
	<Pine.LNX.4.50.0402201544170.410-100000@shane.zope.com>
	<20040220225146.GC3129@slinkp.com>
Message-ID: <200402201805.41931.srichter@cosmos.phy.tufts.edu>

On Friday 20 February 2004 17:51, Paul Winkler wrote:
> (snip)
>
> > I agree that's a problem. ?I think that only means configurable tools
> > need a clean serialization format, and we need tools for
> > importing/exporting configurations. ?We didn't know that (or we hadn't
> > internalized it) when CMF was being created. ?Fortunately, we know it
> > now. :-)
>
> Yeah, a lot of the pieces of the puzzle exist. We have zsync.
> CMF for zope 2 has a decent filesystem representation of properties,
> implemented by FSPropertyManager. We could do something similar
> for annotations and use zsync with it. It will rock :-)

aehm, just implement a new annotations adapter for zsync and you are done.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From faassen at infrae.com  Fri Feb 20 19:06:56 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Fri Feb 20 19:07:01 2004
Subject: [Zope3-dev] ZCML
In-Reply-To: <200402201804.20591.srichter@cosmos.phy.tufts.edu>
References: <403630C5.1090609@zope.com> <403682B1.1080500@infrae.com>
	<200402201804.20591.srichter@cosmos.phy.tufts.edu>
Message-ID: <4036A120.2020804@infrae.com>

Stephan Richter wrote:

>On Friday 20 February 2004 16:57, Martijn Faassen wrote:
>  
>
>>An easy alternative for the prototype would be to simply generate ZCML
>>from whatever language is designed. Has a bunch of benefits; for
>>instance you could check that whatever you generate complies with the
>>ZCML Relax NG schema (presuming that is kept up to date :).
>>    
>>
>
>We need to autogenerate it. When I developed docconfig.py I added all the 
>necessary plumbing. Martijn, are you coming to PyCon 2004? It would be a nice 
>side project. The only reason I have not developed the generator yet is that 
>I did not fully understood relax ng.
>  
>

Nope, I won't be at PyCon 2004.

Regards,

Martijn


From jim at zope.com  Sat Feb 21 06:09:20 2004
From: jim at zope.com (Jim Fulton)
Date: Sat Feb 21 06:10:03 2004
Subject: [Zope3-dev] ZODB 3.3 coming to Zope 3
In-Reply-To: <40363F6E.1010807@zope.com>
References: <200402191411.39870.fred@zope.com> <40363F6E.1010807@zope.com>
Message-ID: <40373C60.5010701@zope.com>

Jim Fulton wrote:
> Fred Drake wrote:
> 
>> We're about to land the changes to Zope 3 so that it uses ZODB 3.3
>> instead of the abandoned ZODB 4.  We hope to make this change in CVS
>> tomorrow morning.
>>
>> After the changes have been made in CVS, we'll send a note to this
>> list letting everyone know we're done. 
> 
> 
> The changes to make Zope 3 use ZODB 3 have been checked in.
> 
> We currently have both ZODB abd zodb packages, which will
> break windows checkouts.  We are going to fix this by getting rid
> of the zodb package. We'll send another note to let everyone know
> when this is done.
> 
> If you have any code that imports from zodb, you will need to change
> it to import from ZODB instead.

I've just removed the last of the zodb files.  You should to
a cvs up with -P to remove this directory from your checkout. Tommorow,
I'll  actually remove the directory from the CVS repository to eliminate
the conflict on Windows.  If you have the directory in your checkout
after I remove the directory from the repository, you'll get an
error when you do an update. (You will be able to get around this
error by removing the directory from the checkout manually.)

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Mon Feb 23 07:36:24 2004
From: jim at zope.com (Jim Fulton)
Date: Mon Feb 23 07:37:06 2004
Subject: [Zope3-dev] ZODB 3.3 coming to Zope 3
In-Reply-To: <40373C60.5010701@zope.com>
References: <200402191411.39870.fred@zope.com> <40363F6E.1010807@zope.com>
	<40373C60.5010701@zope.com>
Message-ID: <4039F3C8.40306@zope.com>

Jim Fulton wrote:
> Jim Fulton wrote:
> 
>> Fred Drake wrote:
>>
>>> We're about to land the changes to Zope 3 so that it uses ZODB 3.3
>>> instead of the abandoned ZODB 4.  We hope to make this change in CVS
>>> tomorrow morning.
>>>
>>> After the changes have been made in CVS, we'll send a note to this
>>> list letting everyone know we're done. 
>>
>>
>>
>> The changes to make Zope 3 use ZODB 3 have been checked in.
>>
>> We currently have both ZODB abd zodb packages, which will
>> break windows checkouts.  We are going to fix this by getting rid
>> of the zodb package. We'll send another note to let everyone know
>> when this is done.
>>
>> If you have any code that imports from zodb, you will need to change
>> it to import from ZODB instead.
> 
> 
> I've just removed the last of the zodb files.  You should to
> a cvs up with -P to remove this directory from your checkout. Tommorow,
> I'll  actually remove the directory from the CVS repository to eliminate
> the conflict on Windows.  If you have the directory in your checkout
> after I remove the directory from the repository, you'll get an
> error when you do an update. (You will be able to get around this
> error by removing the directory from the checkout manually.)

I have now removed the src/zodb directory from the repository.

It should be possible to use an up-to-date Zope 3 on Windows again.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Mon Feb 23 07:39:13 2004
From: jim at zope.com (Jim Fulton)
Date: Mon Feb 23 07:39:55 2004
Subject: [Zope3-dev] ZODB 3.3 coming to Zope 3
In-Reply-To: <40363F6E.1010807@zope.com>
References: <200402191411.39870.fred@zope.com> <40363F6E.1010807@zope.com>
Message-ID: <4039F471.2060006@zope.com>

Jim Fulton wrote:
...
> 
> Update Procedure
> ----------------
> 
> Use this procedure to update the software and convert databases:
> 
> 1. Back up your databases (Data.fs* files).
> 
> 2. Update the software using "cvs up -dP".
> 
> 3. Re-build compiled modules:
> 
>    $ python2.3 setup.py build_ext -i
> 
> 4. Run the conversion script for each FileStorage:
> 
>    $ PYTHONPATH=src python2.3 src/ZODB/zodb4/main.py Data.fs
> 
> This will move the existing ZODB 4 database to a backup file (the .fs
> extension will be changed to .fs4; if the main file doesn't use the
> .fs extension, .fs4 will simply be appended).


When we removed the files from zodb, we neglected to create necessary
module aliases. This has now been done.

Also, the conversion script didn't process site.zcml and, thus, didn't
pick up ZCML-defined module aliases. This has been fixed.
I've checked in this, and, some other fixes.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From dominik.huber at projekt01.ch  Mon Feb 23 12:50:29 2004
From: dominik.huber at projekt01.ch (Dominik Huber  )
Date: Mon Feb 23 12:51:20 2004
Subject: [Zope3-dev] queryAdapter via __conform__
Message-ID: <200402231850.AA140115998@mail.projekt01.ch>

If queryAdapter is called by a view, the result is an unproxied adapted object.
If __conform__ is invoked during this call, the resulting adapted object is proxied.

I would suggest to extend queryAdapter by a removeAllProxies to provid a consistent behavior. Thus for example 
the __conform__ mechansim could also used in the widget framework (editview).

I will checking this changes if nobody has objections.

Regards,
Dominik

see ..\src\zope\component\__init__.py

def queryAdapter(object, interface, default=None, name='', context=None):
    [...]
    conform = getattr(object, '__conform__', None)
    if conform is not None:
        try:
            adapter = conform(interface)
        except TypeError:
        [...]
        else:
            if adapter is not None:
                # CHANGE 
                from zope.proxy import removeAllProxies
                return removeAllProxies(adapter)

    if interface.isImplementedBy(object):
        return object

    return queryNamedAdapter(object, interface, name, default, context)

From jim at zope.com  Mon Feb 23 13:18:27 2004
From: jim at zope.com (Jim Fulton)
Date: Mon Feb 23 13:18:38 2004
Subject: [Zope3-dev] queryAdapter via __conform__
In-Reply-To: <200402231850.AA140115998@mail.projekt01.ch>
References: <200402231850.AA140115998@mail.projekt01.ch>
Message-ID: <403A43F3.3090007@zope.com>

Dominik Huber wrote:
> If queryAdapter is called by a view, the result is an unproxied adapted object.

Well, if the object being adaptged is proxied, then queryAdapter will
either return the object itself, which would be proxied, or it would return
an adapter of the proxied object, in which case you have an adapter
of a proxy, and the underlying object is protected.

> If __conform__ is invoked during this call, the resulting adapted object is proxied.

If you are getting a proxy from __conform__, then the underlying object
was proxied and the resulting adapter should be proxied.

> I would suggest to extend queryAdapter by a removeAllProxies to provid a consistent behavior. Thus for example 
> the __conform__ mechansim could also used in the widget framework (editview).

No.

> I will checking this changes if nobody has objections.

I object. Don't check this change in.
Such a change would cause __conform__ to be a security hole.

Why is a security-proxied adapter a problem?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From dev at projekt01.ch  Mon Feb 23 15:39:57 2004
From: dev at projekt01.ch (Roger ineichen)
Date: Mon Feb 23 15:40:56 2004
Subject: AW: [Zope3-dev] queryAdapter via __conform__
In-Reply-To: <403A43F3.3090007@zope.com>
Message-ID: <000201c3fa4d$347eb210$1e63a8c0@projekt01.local>

jim wrote:
> Dominik Huber wrote:
> > If queryAdapter is called by a view, the result is an unproxied 
> > adapted object.
> 
> Well, if the object being adaptged is proxied, then 
> queryAdapter will either return the object itself, which 
> would be proxied, or it would return an adapter of the 
> proxied object, in which case you have an adapter of a proxy, 
> and the underlying object is protected.

Yes, but if we call queryAdapter for to get a adapter from the
adapter service we get a unproxied adapter.

I think __conform__ is for to provide to return adapter by the object
it self. 
queryAdapter(object, interface, default=None, name='', context=None)
             ^^^^^^
If __conform__ of the object is invoked, we get back a proxied adapter.
                      ^^^^^^
The widget framework let's render widgets from a adapter (if this 
adapter comes from the adapter service) 
If we get the adapter from the method __conform__ we get a 
proxied object and the method _setUpWidgets() from the
widget framework isn't allowed to set adapted.__parent__ = self.context,
because adapted is proxied.

_setUpWidgets() and adapted.__parent__ = self.context are in 
the  file "..src\zope\app\browser\form\editview.py",

What can we do to support adapter which we get back from
the invoked __conform__?

> > If __conform__ is invoked during this call, the resulting adapted 
> > object is proxied.
> 
> If you are getting a proxy from __conform__, then the 
> underlying object was proxied and the resulting adapter 
> should be proxied.

No, we get a proxied object if we return a object in the __conform__
method. But we never proxied the object before. "Something" is 
proxing the object. (Perhaps we call this from a view) 
We check also the object befor we return the object and there
was no proxy before. But after the return we have a proxy around the object.


> > I would suggest to extend queryAdapter by a 
> removeAllProxies to provid 
> > a consistent behavior. Thus for example
> > the __conform__ mechansim could also used in the widget 
> framework (editview).
> 
> No.
> 
> > I will checking this changes if nobody has objections.
> 
> I object. Don't check this change in.
> Such a change would cause __conform__ to be a security hole.
> 
> Why is a security-proxied adapter a problem?

See above the proxy returned from the __conform__ method let
us not set the __parent__ attribute. But if we get the adapter
from the adapter service theres no problem. Because we don't have
security-proxied around the adapted object. 

At least if we check this with isProxy(), we get a "false".

Sorry, about my ugly english, perhaps dominik can explain this 
in a better way.

Roger


From jim at zope.com  Mon Feb 23 17:59:47 2004
From: jim at zope.com (Jim Fulton)
Date: Mon Feb 23 17:59:55 2004
Subject: AW: [Zope3-dev] queryAdapter via __conform__
In-Reply-To: <000201c3fa4d$347eb210$1e63a8c0@projekt01.local>
References: <000201c3fa4d$347eb210$1e63a8c0@projekt01.local>
Message-ID: <403A85E3.6050409@zope.com>

Roger ineichen wrote:
> jim wrote:
> 
>>Dominik Huber wrote:
>>
>>>If queryAdapter is called by a view, the result is an unproxied 
>>>adapted object.
>>
>>Well, if the object being adaptged is proxied, then 
>>queryAdapter will either return the object itself, which 
>>would be proxied, or it would return an adapter of the 
>>proxied object, in which case you have an adapter of a proxy, 
>>and the underlying object is protected.
> 
> 
> Yes, but if we call queryAdapter for to get a adapter from the
> adapter service we get a unproxied adapter.

This is a restatement of what you said above, and to which I replied.
I won't bother to repeat my earlier reply. ;)

...

> The widget framework let's render widgets from a adapter (if this 
> adapter comes from the adapter service) 

You are talking about the fact that the *form* framework
is willing to adapt a form's context to a schema. Then the
object used to access the data is an adapter. This adapter could
come from a __conform__ method. Is this what you mean?

> If we get the adapter from the method __conform__ we get a 
> proxied object and the method _setUpWidgets() from the
> widget framework isn't allowed to set adapted.__parent__ = self.context,
> because adapted is proxied.
> 
> _setUpWidgets() and adapted.__parent__ = self.context are in 
> the  file "..src\zope\app\browser\form\editview.py",

It would be cleaner if the __conform__ method set the __parent__
attribute before returning the adapter.  It would be good
to modify editview to check whether the parent was already set before
setting it. Feel free to make that change if you want. :)

> What can we do to support adapter which we get back from
> the invoked __conform__?

You need to make security declarations for the adapter.
To do this, you need to actually use the class ZCML
directive:

<adapter provides="IFooSchema" for="IBar" factory=".BarFooSchema" />

<class class=".BarFooSchema">
    <require permission="x.ManageBar"
             interface="IFooSchema"
             set_schema="IFooSchema"
             set_attributes="__parent__"
             />
</content>

This is more cumbersome than it should be.  We should
provide a way to express this with the adapter directive
only.

>>>If __conform__ is invoked during this call, the resulting adapted 
>>>object is proxied.
>>
>>If you are getting a proxy from __conform__, then the 
>>underlying object was proxied and the resulting adapter 
>>should be proxied.
> 
> 
> No, we get a proxied object if we return a object in the __conform__
> method. But we never proxied the object before.

I think you are mistaken.

 > "Something" is
> proxing the object. (Perhaps we call this from a view) 

The object passed to getAdapter is proxied. This is the context of
the view and it is almost certainly proxied.

> We check also the object befor we return the object and there
> was no proxy before. But after the return we have a proxy around the object.

Again, I think you are mistaken.  If the object isn't proxied,
then I have a hard time believing calling __conform__ would magically
add a proxy. How did you arrive at the conclusion that the object
was not proxied?

> 
> 
>>>I would suggest to extend queryAdapter by a 
>>
>>removeAllProxies to provid 
>>
>>>a consistent behavior. Thus for example
>>>the __conform__ mechansim could also used in the widget 
>>
>>framework (editview).
>>
>>No.
>>
>>
>>>I will checking this changes if nobody has objections.
>>
>>I object. Don't check this change in.
>>Such a change would cause __conform__ to be a security hole.
>>
>>Why is a security-proxied adapter a problem?
> 
> 
> See above the proxy returned from the __conform__ method let
> us not set the __parent__ attribute. But if we get the adapter
> from the adapter service theres no problem. Because we don't have
> security-proxied around the adapted object. 
 > At least if we check this with isProxy(), we get a "false".

Sure, see my above suggestions.


> 
> Sorry, about my ugly english,

No problem. Thanks for speaking english.

Sorry I only speak English. (I am slowly learning Spanish. :)

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From paoloinvernizzi at dmsware.com  Tue Feb 24 03:13:28 2004
From: paoloinvernizzi at dmsware.com (Paolo Invernizzi)
Date: Tue Feb 24 03:13:37 2004
Subject: [Zope3-dev] Re: ZODB 3.3 coming to Zope 3
In-Reply-To: <4039F471.2060006@zope.com>
References: <200402191411.39870.fred@zope.com> <40363F6E.1010807@zope.com>
	<4039F471.2060006@zope.com>
Message-ID: <c1f138$t9d$1@sea.gmane.org>

Jim Fulton wrote:

> When we removed the files from zodb, we neglected to create necessary
> module aliases. This has now been done.
> 
> Also, the conversion script didn't process site.zcml and, thus, didn't
> pick up ZCML-defined module aliases. This has been fixed.
> I've checked in this, and, some other fixes.
> 
> Jim
> 

Hi Jim,

I've tried the conversion from a fresh check-out:

Pickling errors:

         No module named zodb.btrees.Length


The data.fs is a plain zope3 plus one zwiki...

Thanks in advance.

---
Paolo Invernizzi


From jim at zope.com  Tue Feb 24 05:25:30 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 24 05:26:11 2004
Subject: [Zope3-dev] Re: ZODB 3.3 coming to Zope 3
In-Reply-To: <c1f138$t9d$1@sea.gmane.org>
References: <200402191411.39870.fred@zope.com>
	<40363F6E.1010807@zope.com>	<4039F471.2060006@zope.com>
	<c1f138$t9d$1@sea.gmane.org>
Message-ID: <403B269A.5040005@zope.com>

Paolo Invernizzi wrote:
> Jim Fulton wrote:
> 
>> When we removed the files from zodb, we neglected to create necessary
>> module aliases. This has now been done.
>>
>> Also, the conversion script didn't process site.zcml and, thus, didn't
>> pick up ZCML-defined module aliases. This has been fixed.
>> I've checked in this, and, some other fixes.
>>
>> Jim
>>
> 
> Hi Jim,
> 
> I've tried the conversion from a fresh check-out:
> 
> Pickling errors:
> 
>         No module named zodb.btrees.Length
> 
> 
> The data.fs is a plain zope3 plus one zwiki...

I presume that the conversion suceeded but you had one or more skipped
records.

I just added an alias for Length. You should to a cvs up and try again.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From paoloinvernizzi at dmsware.com  Tue Feb 24 05:50:20 2004
From: paoloinvernizzi at dmsware.com (Paolo Invernizzi)
Date: Tue Feb 24 05:50:27 2004
Subject: [Zope3-dev] Re: ZODB 3.3 coming to Zope 3
In-Reply-To: <403B269A.5040005@zope.com>
References: <200402191411.39870.fred@zope.com>	<40363F6E.1010807@zope.com>	<4039F471.2060006@zope.com>	<c1f138$t9d$1@sea.gmane.org>
	<403B269A.5040005@zope.com>
Message-ID: <403B2C6C.7020207@dmsware.com>

Jim Fulton wrote:

> I presume that the conversion suceeded but you had one or more skipped
> records.

Yep, 265! :-\

> I just added an alias for Length. You should to a cvs up and try again.

Done. All went right, and the wiki is again up and running.

Thanks for the fast reply.

---
Paolo Invernizzi


From dominik.huber at projekt01.ch  Tue Feb 24 06:06:24 2004
From: dominik.huber at projekt01.ch (Dominik Huber)
Date: Tue Feb 24 06:08:00 2004
Subject: [Zope3-dev] queryAdapter via __conform__
In-Reply-To: <403A43F3.3090007@zope.com>
Message-ID: <MLEHIMEMKLLFBGGPMEAHAEOJGLAA.dominik.huber@projekt01.ch>



Jim Fulton wrote:
> 
> Dominik Huber wrote:
> > If queryAdapter is called by a view, the result is an unproxied 
> adapted object.
> 
> Well, if the object being adaptged is proxied, then queryAdapter will
> either return the object itself, which would be proxied, or it 
> would return
> an adapter of the proxied object, in which case you have an adapter
> of a proxy, and the underlying object is protected.

I comprehend this the same way.

> > If __conform__ is invoked during this call, the resulting 
> adapted object is proxied.
> 
> If you are getting a proxy from __conform__, then the underlying object
> was proxied and the resulting adapter should be proxied.

That is the fact I observed too.

> > I would suggest to extend queryAdapter by a removeAllProxies to 
> provid a consistent behavior. Thus for example 
> > the __conform__ mechansim could also used in the widget 
> framework (editview).
> 
> No.
> 
> > I will checking this changes if nobody has objections.
> 
> I object. Don't check this change in.
> Such a change would cause __conform__ to be a security hole.
> 
> Why is a security-proxied adapter a problem?

I'm not against security-proxied adapters but then all adapters should be security-proxied if possible. My sole objection was that the current implementation does not provide a consistent way. IMO the invocation via __coform__ should provide an alternative (similar) way to adapted an object.

I ignored the securtiy aspect (B.3), exuse me, but the the only consistent way without security concerns would be to security-proxy all adapters (via global and conform invocation B.2 and B.4). This conclusion bases on two scenarios: a sample adapter that references a proxied object (A) and a sample adapter that references an unproxied object (B).

IMO already the current implementation could cause the same security hole if sombody stores a unproxied reference to the object inside the adapter (B.1).

A: sample adapter with s._object reference to the proxied object
----------------------------------------------------------------

1. via global lookup (current implementation): adapted isProxy: False, object isProxy: True
*2. via global lookup (security-proxied adapter): adapted isProxy: True, object isProxy: True
3. via conform lookup (incl. removeProxies): adapted isProxy: False, object isProxy: False
4. via conform lookup (excl. removeProxies): adapted isProxy: True, object isProxy: True

B: sample adapter with s._object reference to the unproxied object
------------------------------------------------------------------

1. via global lookup (current implementation): adapted isProxy: False, object isProxy: False
*2. via global lookup (security-proxied adapter): adapted isProxy: True, object isProxy: True
3. via conform lookup (incl. removeProxies): adapted isProxy: False, object isProxy: False
4. via conform lookup (excl. removeProxies): adapted isProxy: True, object isProxy: True

*hypothetical

regards,
dominik





From jim at zope.com  Tue Feb 24 07:09:15 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 24 07:09:53 2004
Subject: [Zope3-dev] queryAdapter via __conform__
In-Reply-To: <MLEHIMEMKLLFBGGPMEAHAEOJGLAA.dominik.huber@projekt01.ch>
References: <MLEHIMEMKLLFBGGPMEAHAEOJGLAA.dominik.huber@projekt01.ch>
Message-ID: <403B3EEB.3070505@zope.com>

Dominik Huber wrote:
> 

...

>>Why is a security-proxied adapter a problem?
> 
> 
> I'm not against security-proxied adapters but then all adapters should be 
 > security-proxied if possible.

I don't agree.

> My sole objection was that the current implementation
 > does not provide a consistent way. IMO the invocation via __coform__ should provide
 > an alternative (similar) way to adapted an object.

But __conform__ is a very different mechanism. Given that it is
a very differtent mechanism, I'm not surprised that the way things
are proxied is different.

> I ignored the securtiy aspect (B.3), exuse me, but the the only
 > consistent way without security concerns would be to security-proxy
 > all adapters (via global and conform invocation B.2 and B.4).
 > This conclusion bases on two scenarios: a sample adapter that references
 > a proxied object (A) and a sample adapter that references an unproxied object (B).
> 
> IMO already the current implementation could cause the same security hole 
 > if sombody stores a unproxied reference to the object inside the adapter (B.1).

But for someone to do this, they'd need an unproxied reference to the object]
in the first place, in which they could do what they wanted anyway.  This introduces
no new hole.  The only way that code can get an unpoxied reference to an object
is if the code is trusted.

> 
> A: sample adapter with s._object reference to the proxied object
> ----------------------------------------------------------------
> 
> 1. via global lookup (current implementation): adapted isProxy: False, object isProxy: True
> *2. via global lookup (security-proxied adapter): adapted isProxy: True, object isProxy: True
> 3. via conform lookup (incl. removeProxies): adapted isProxy: False, object isProxy: False
> 4. via conform lookup (excl. removeProxies): adapted isProxy: True, object isProxy: True
> 
> B: sample adapter with s._object reference to the unproxied object
> ------------------------------------------------------------------
> 
> 1. via global lookup (current implementation): adapted isProxy: False, object isProxy: False
> *2. via global lookup (security-proxied adapter): adapted isProxy: True, object isProxy: True
> 3. via conform lookup (incl. removeProxies): adapted isProxy: False, object isProxy: False
> 4. via conform lookup (excl. removeProxies): adapted isProxy: True, object isProxy: True
> 
> *hypothetical

What is important is that the underlying content is protected.
The current schema achieves that.  Adding extra proxies around adapters
that adapt proxied objects doesn't improve the protection. Removing proxies
around adapters of unproxied objects removes needed protection.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From philipp at weitershausen.de  Tue Feb 24 12:12:42 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Tue Feb 24 12:11:40 2004
Subject: [Zope3-dev] Package restructuring: zope.app.content
Message-ID: <c1g09g$bcj$1@sea.gmane.org>

Hello all,

I just merged philikon-movecontent-branch to HEAD. All content types are 
now in their own packages below zope.app, together with their interfaces 
and browser views. zope.app.content has been reduced to a simple module now.

Your Zope instance should continue to work normally, thanks to 
modulealiases. These will later be removed once we have a conversion 
script for the ZODB. Since we'll be moving more stuff around, we will 
rely on modulealiases for now.

Note that the PythonPage content object has moved to zope.app, too. So 
in case you're including it in your products.zcml, you can remove that 
line safely (you need to remove it to make Zope3 startup ;)).

Don't get lost in our new package structure... Oh wait, that was the old 
one that was so labyrinthy... :) Note that this is just the start. 
There's a lot more to move around...

Best regards,

Philipp



From dominikhuber at perse.ch  Tue Feb 24 13:16:10 2004
From: dominikhuber at perse.ch (Dominik Huber)
Date: Tue Feb 24 13:17:34 2004
Subject: [Zope3-dev] queryAdapter via __conform__
In-Reply-To: <403A85E3.6050409@zope.com>
Message-ID: <MLEHIMEMKLLFBGGPMEAHAEOLGLAA.dominikhuber@perse.ch>

Jim Fulton wrote:
[...]
> But __conform__ is a very different mechanism. Given that it is
> a very differtent mechanism, I'm not surprised that the way things
> are proxied is different.

Given the fact we can't change the different mechanism to obtain a consistent behavior we are faced with the problem to make the overlying frameworks and users kind of __conform__-aware. We have to declare that adapters can be proxied or unproxied.

I'm not surprised too because meanwhile I almost know the blackbox inside queryAdapter :) 
But somebody who uses the api queryAdpater (as I before) has no chance to be __conform__-aware and he will *except* a consistent behavior whatever very different mechanism are encapsulated inside.

> It would be cleaner if the __conform__ method set the __parent__
> attribute before returning the adapter.  It would be good
> to modify editview to check whether the parent was already set before
> setting it. Feel free to make that change if you want. :)

I'm willing to change the form framework (if the others appreciate those changes) but I'm not realy happy with your proposed solution.

The purpose is to provide an IFoo adapter via __conform__. IFoo does not declare __parent__. In the real live I have no chance to guess that somebody in an overlying framework likes to inject a __parent__ attribute into my IFoo adapter. (In those moments it's pretty cool to have a security-proxied adapter that resents such intrusive intentsions :)

I would prefer to change the form framework the same way containers behave handling its simplistic containments. IOW I would like to decorate __parent__ inside an overlying frameworks instead of injecting __parent__ into the adapter***  or extending all class directives by set_attributes = '__parent__' ****.

Would that be a passable way? I'm not realy aware of all the possible invocations of such a decorated adapter during his journey through zope3 (-> Event publishing).

Should such a decorator implement ILocation? Or another interface like IAdaptionContext:

class IAdaptionContext(Interface):
    """Locate an adapters via it context.
    """
    __parent__ = Attribute("The context of the adapter")

> What is important is that the underlying content is protected.
> The current schema achieves that.  Adding extra proxies around adapters
> that adapt proxied objects doesn't improve the protection. 
> Removing proxies
> around adapters of unproxied objects removes needed protection.

When I looked at the problem the second time I recognized that security-proxied adapters supply a pretty cool protection.

A metaphor illustrating the fact: I see a proxy like a protection shield (blue laser orb).
Providing an global adapter is similar to wrapping such a protection shield (including its object) inside a carton box (adapter). The carton box is still outside an has to resent intrusive intentsions such as __parent__ injections by overlying frameworks.
The other way is the adaption via __conform__: It puts the carton box into the 'same' protection shield via the proxy-mechanism. The carton box is protected too and does not get wet. (I do not intend to provide nested laser orbs. I'm already happy with the __conform__ way).

I don't intend to bother you with stupid questions but would it not possible to achieve the same protection for global adapters too? Kind of unbag the object, then wrapping the unproxied object and then proxy the resulting adapter.

Thanks for being so patient...
Regards,
Dominik

*** example form framework: (zope.app.browser.form.editview.EditView):

    def _setUpWidgets(self):
        adapted = getAdapter(self.context, self.schema)
        if adapted is not self.context:
-->         adapted.__parent__ = self.context

**** example adapter registration
<class class=".BarFooSchema">
    <require permission="x.ManageBar"
             interface="IFooSchema"
             set_schema="IFooSchema"
--->         set_attributes="__parent__"
             />
</content>
From stephan.richter at tufts.edu  Tue Feb 24 14:11:57 2004
From: stephan.richter at tufts.edu (Stephan Richter)
Date: Tue Feb 24 14:12:03 2004
Subject: [Zope3-dev] Code cleanup day
Message-ID: <200402241411.57732.stephan.richter@tufts.edu>

Hello everyone,

while writing the book for Zope 3, I saw a lot of code. I noticed that certain 
sections of the code are in really bad shape in terms of cosmetics. The 
common issues are:

1. Headers and module doc strings do not conform to the style guide. There are 
still files (especially C code) that do not have a valid ZPL 2.0 header. 
Also, some files have no doc string or a doc string that only includes the 
CVS id. We should at least have a title in the module doc string.

2. Interface, Method and Attribute/Field doc strings. I noticed that many 
interfaces have insufficient doc strings. For example, if I remember right, 
the IPrincipal doc string talks about how a principal is used in a particular 
context, but does not explain what the principal is in the first place. In 
even worse cases attribute explanations contained things like "XXX to be done 
later" or empty strings. If the API doc tool is supposed to be helpful, we 
need to have good doc strings. There are some minor things about the format 
of doc strings, but we can discuss this later.

3. Refactoring scars. While our merciless refactorings went pretty good and we 
often cleanup after ourselves, scars from the many refactorings start to 
show. A good example is the zope.component package. The interfaces are 
inconsistent and services implement methods that are not in the interfaces 
(but should be). This is noone's fault, just a result of time. But I think we 
should remove these dirty spots, since it will make it easier for the 
incoming newbie to see what's going on.

I am sure there are a couple of things I missed, but this should cover the 
majority. 

To make a better release of Zope X3.0 possible, I would suggest that we have a 
code cleanup day after Zope X3.0 beta 1 somewhen in April. 

What do you guys think? Would you participate? Note that there is something to 
do for anyone, from the total beginner to the core hacker.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From jim at zope.com  Tue Feb 24 14:15:04 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 24 14:15:30 2004
Subject: [Zope3-dev] Re: Heads Up! Namegeddon 2
In-Reply-To: <4026D19B.5060905@zope.com>
References: <4026D19B.5060905@zope.com>
Message-ID: <403BA2B8.3060205@zope.com>

Jim Fulton wrote:
> 
> I think we are going to decide to have a second and final
> namegeddon before the first release.  My guess is that this
> should happen the week of February 23-27. We will probably
> ask that people not check things in during that week.
> Also, if there is pending work at the end of that week,
> merging it will probably be rather difficult.

False alarm!

We decided that we would do this gradually.  You can go ahead
and check things in as needed.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Tue Feb 24 14:20:14 2004
From: jim at zope.com (Jim Fulton)
Date: Tue Feb 24 14:21:36 2004
Subject: [Zope3-dev] queryAdapter via __conform__
In-Reply-To: <MLEHIMEMKLLFBGGPMEAHAEOLGLAA.dominikhuber@perse.ch>
References: <MLEHIMEMKLLFBGGPMEAHAEOLGLAA.dominikhuber@perse.ch>
Message-ID: <403BA3EE.8050704@zope.com>

Dominik Huber wrote:
 > Jim Fulton wrote:
 > [...]
 >
 >>But __conform__ is a very different mechanism. Given that it is
 >>a very differtent mechanism, I'm not surprised that the way things
 >>are proxied is different.


 > Given the fact we can't change the different mechanism to obtain a
 > consistent behavior we are faced with the problem to make the
 > overlying frameworks and users kind of __conform__-aware. We have to
 > declare that adapters can be proxied or unproxied.

 > I'm not surprised too because meanwhile I almost know the blackbox
 > inside queryAdapter :) But somebody who uses the api queryAdpater
 > (as I before) has no chance to be __conform__-aware and he will
 > *except* a consistent behavior whatever very different mechanism are
 > encapsulated inside.

I don't know of anyone else who has been surprised by this before,
because:

- Almost no one is using __conform__.

- Use of adapters in forms is also rare.

Two rares make a very rare. :)

 >
 >
 >>It would be cleaner if the __conform__ method set the __parent__
 >>attribute before returning the adapter.  It would be good
 >>to modify editview to check whether the parent was already set before
 >>setting it. Feel free to make that change if you want. :)
 >
 >

 > I'm willing to change the form framework (if the others appreciate
 > those changes) but I'm not realy happy with your proposed solution.
 > The purpose is to provide an IFoo adapter via __conform__. IFoo does
 > not declare __parent__. In the real live I have no chance to guess
 > that somebody in an overlying framework likes to inject a __parent__
 > attribute into my IFoo adapter. (In those moments it's pretty cool
 > to have a security-proxied adapter that resents such intrusive
 > intentsions :)

Good point.

 > I would prefer to change the form framework the same way containers
 > behave handling its simplistic containments. IOW I would like to
 > decorate __parent__ inside an overlying frameworks instead of
 > injecting __parent__ into the adapter*** or extending all class
 > directives by set_attributes = '__parent__' ****.

Which is what the form framework does now, sort of.

 > Would that be a passable way? I'm not realy aware of all the
 > possible invocations of such a decorated adapter during his journey
 > through zope3 (-> Event publishing).

 > Should such a decorator implement ILocation? Or another interface
 > like IAdaptionContext:

 > class IAdaptionContext(Interface):
 >     """Locate an adapters via it context.
 >     """
 >     __parent__ = Attribute("The context of the adapter")

Hm, we should probably use a LocationProxy here.

See zope.app.location

 >>What is important is that the underlying content is protected.
 >>The current schema achieves that.  Adding extra proxies around adapters
 >>that adapt proxied objects doesn't improve the protection.
 >>Removing proxies
 >>around adapters of unproxied objects removes needed protection.
 >
 >

 > When I looked at the problem the second time I recognized that
 > security-proxied adapters supply a pretty cool protection.

 > A metaphor illustrating the fact: I see a proxy like a protection
 > shield (blue laser orb).  Providing an global adapter is similar to
 > wrapping such a protection shield (including its object) inside a
 > carton box (adapter). The carton box is still outside an has to
 > resent intrusive intentsions such as __parent__ injections by
 > overlying frameworks.  The other way is the adaption via
 > __conform__: It puts the carton box into the 'same' protection
 > shield via the proxy-mechanism. The carton box is protected too and
 > does not get wet. (I do not intend to provide nested laser orbs. I'm
 > already happy with the __conform__ way).


 > I don't intend to bother you with stupid questions but would it not
 > possible to achieve the same protection for global adapters too?
 > Kind of unbag the object, then wrapping the unproxied object and
 > then proxy the resulting adapter.

See:

   http://mail.zope.org/pipermail/zope3-dev/2004-February/009742.html

for a discussion on this topic.

Generally, you want to adapters to be publically accessable
and to protect the objects they adapt.  I want to make this
easier to spell.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From gary at modernsongs.com  Tue Feb 24 17:52:42 2004
From: gary at modernsongs.com (Gary Poster)
Date: Tue Feb 24 17:52:54 2004
Subject: [Zope3-dev] queryAdapter via __conform__
In-Reply-To: <403BA3EE.8050704@zope.com>
References: <MLEHIMEMKLLFBGGPMEAHAEOLGLAA.dominikhuber@perse.ch>
	<403BA3EE.8050704@zope.com>
Message-ID: <403BD5BA.6090005@modernsongs.com>



Jim Fulton wrote:

> 
> - Use of adapters in forms is also rare.

:-) tangential, but count us in to the "adapters for forms" camp.  We 
are bypassing the security because of the library use, but there ya go. 
  I think Tres used some adapters with forms last year at the Zope 3 cms 
sprint in Germany too, maybe...

Gary

From dominikhuber at perse.ch  Wed Feb 25 02:50:19 2004
From: dominikhuber at perse.ch (Dominik Huber)
Date: Wed Feb 25 02:51:43 2004
Subject: [Zope3-dev] queryAdapter via __conform__
In-Reply-To: <403BA3EE.8050704@zope.com>
Message-ID: <MLEHIMEMKLLFBGGPMEAHKEPBGLAA.dominikhuber@perse.ch>

Jim Fulton wrote:
> Two rares make a very rare. :)
Stay abreast of changes ;)

> Hm, we should probably use a LocationProxy here.
I'll check it out...

Thanks for all the informations.

Regards,
Dominik Huber, Projekt01 GmbH
_____________________________
END OF MESSAGE




From jim at zope.com  Wed Feb 25 05:39:11 2004
From: jim at zope.com (Jim Fulton)
Date: Wed Feb 25 05:39:29 2004
Subject: [Zope3-dev] queryAdapter via __conform__
In-Reply-To: <MLEHIMEMKLLFBGGPMEAHKEPBGLAA.dominikhuber@perse.ch>
References: <MLEHIMEMKLLFBGGPMEAHKEPBGLAA.dominikhuber@perse.ch>
Message-ID: <403C7B4F.3080109@zope.com>

Dominik Huber wrote:
> Jim Fulton wrote:
> 
>>Two rares make a very rare. :)
> 
> Stay abreast of changes ;)
> 
> 
>>Hm, we should probably use a LocationProxy here.
> 
> I'll check it out...
> 
> Thanks for all the informations.

Thanks for your persistence. :)

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From mzlrthnh at hotmail.com  Wed Feb 25 06:24:16 2004
From: mzlrthnh at hotmail.com (Monique Ivey)
Date: Wed Feb 25 06:32:28 2004
Subject: [Zope3-dev] Fake rolex watches culprit
Message-ID: <YPJMLNTDHRPKFWBMVKBMZ@yahoo.com>

An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/zope3-dev/attachments/20040225/50b71a22/attachment-0001.html
From dev at projekt01.ch  Wed Feb 25 08:00:26 2004
From: dev at projekt01.ch (Roger ineichen)
Date: Wed Feb 25 08:01:28 2004
Subject: [Zope3-dev] Usability question
Message-ID: <000a01c3fb9f$57b5a600$1e63a8c0@projekt01.local>

Hello together

Is there a way to register a own box with information
to the Rotterdam skin?

Or do we just have the "tooltip" outside a view?

Of corse we can write our information in a own view, but
this information are lost if you change to the introspection
which is also a view on the same object.

We wrote our own zmi skin. In this skin we are free to 
provide what we whant. But it whould be nice to
support aditional informations from our product
in the Rotterdam skin outside of a page/view.

Perhaps I blame me now, but,
In Plone is a way to register slots and anybody can
fill this slots with own information.

We have done this in our skin in a same style.
1. We add a directive for (slot)_views
2. We call a view in our (zmi)skin on the left side. 
3. This view is collecting registred (slot)_views 
and returns the result in our (zmi)skin.

If we hade this mechanism we could add the tooltip
the same way. And this gives us a option to add 
custom product boxes.

regards
Roger Ineichen
_____________________________
Projekt01 GmbH
www.projekt01.ch
_____________________________
END OF MESSAGE


From philipp at weitershausen.de  Wed Feb 25 10:11:09 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Wed Feb 25 10:04:28 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <200402241411.57732.stephan.richter@tufts.edu>
References: <200402241411.57732.stephan.richter@tufts.edu>
Message-ID: <403CBB0D.8000108@weitershausen.de>

Stephan,

short answer: good idea. If I may add to the list of cosmetic surgeries 
to be done:

1. Use new-style classes whereever possible. Need to decide whether to 
subclass object or use __metaclass__ = type or both

2. Enforce http://dev.zope.org/Zope3/ZCMLStyleGuide. According to what 
I've seen in checkins, people seem to have different taste with how ZCML 
should be formatted, and seldomly look at the before mentioned style 
guide. I've actually seen correct format being "beaufified" incorrectly.

3. Schema fields accept both a pair of title/description OR __doc__ (as 
  keyword argument). The former is used throughout the whole Zope3 
source, except when Jim edited it... then it's using __doc__ ;)

I can see why people would prefer __doc__, but using title/description 
is much better for schemas that are going to be used as a basis for Web 
forms later (think: i18n, explicit message ids, etc.).

If people would *still* like to use the __doc__ facility, we should at 
least make this a non-keyword argument... Field(__doc__="Foo") is just ugly.

4. Revalidate all ZPTs against the XHTML DTDs and review them for known 
browser issues (<br/> ==> <br />). I've done this last year already, but 
there were a lot of checkins since, a few of them in which I already 
noticed incorrect XHTML.

5. Make the commonly long list of imports more scrutable. I haven't 
found anything in the coding style, but I usually follow this order::

   1. Import modules from standard python library/global ackages
   2. Import modules from the 'zope' package
   3. Import modules from the 'zope.app' package

while "import XYZ" goes before "from XYZ import ABC".

E.g.::

   import os
   from smtplib import SMTP

   from zope.configuration import xmlconfig
   from zope.security import getProxy

   from zope.app.tests import PeacefulSetup
   from zope.app.browser.form.widget import ListWidget

IMHO, this visual aid will make it a lot easier when we will have to 
determine package dependencies. While we will probably have a tool to 
extract those at some point, the developer still needs to be aware of 
the what he/she's importing. Give you an example: a 'zope' package 
should hardly ever import something from 'zope.app'. Sadly, some do :(

> To make a better release of Zope X3.0 possible, I would suggest that
> we have a code cleanup day after Zope X3.0 beta 1 somewhen in April.

The idea of a "spring cleaning day" is kinda cool. We could make this an 
annual thing; I'm sure we'll have something to do *every* year.

Philipp


From sidnei at awkly.org  Wed Feb 25 10:48:24 2004
From: sidnei at awkly.org (Sidnei da Silva)
Date: Wed Feb 25 10:48:58 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <403CBB0D.8000108@weitershausen.de>
References: <200402241411.57732.stephan.richter@tufts.edu>
	<403CBB0D.8000108@weitershausen.de>
Message-ID: <20040225154824.GF15554@moria.redesul.com.br>

On Wed, Feb 25, 2004 at 04:11:09PM +0100, Philipp von Weitershausen wrote:
| 2. Enforce http://dev.zope.org/Zope3/ZCMLStyleGuide. According to what 
| I've seen in checkins, people seem to have different taste with how ZCML 
| should be formatted, and seldomly look at the before mentioned style 
| guide. I've actually seen correct format being "beaufified" incorrectly.

I'm surprised that such a thing exists. I may not have paid enough
attention. However, I disagree with some of the suggested
formatting. I'm currently using emacs nxml-mode (plus a patch to
indent attributes in multiple lines correctly), and IMHO it does a
wonderful job at (no-brainer) indenting both ZCML and ZPT. Can I
suggest some minor changes to the proposed style?

-- 
Sidnei da Silva <sidnei@awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher

This file will self-destruct in five minutes.

From stephan.richter at tufts.edu  Wed Feb 25 11:00:26 2004
From: stephan.richter at tufts.edu (Stephan Richter)
Date: Wed Feb 25 11:00:54 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <20040225154824.GF15554@moria.redesul.com.br>
References: <200402241411.57732.stephan.richter@tufts.edu>
	<403CBB0D.8000108@weitershausen.de>
	<20040225154824.GF15554@moria.redesul.com.br>
Message-ID: <200402251100.26248.stephan.richter@tufts.edu>

On Wednesday 25 February 2004 10:48, Sidnei da Silva wrote:
> | 2. Enforce http://dev.zope.org/Zope3/ZCMLStyleGuide. According to what
> | I've seen in checkins, people seem to have different taste with how ZCML
> | should be formatted, and seldomly look at the before mentioned style
> | guide. I've actually seen correct format being "beaufified" incorrectly.
>
> I'm surprised that such a thing exists. I may not have paid enough
> attention. However, I disagree with some of the suggested
> formatting. I'm currently using emacs nxml-mode (plus a patch to
> indent attributes in multiple lines correctly), and IMHO it does a
> wonderful job at (no-brainer) indenting both ZCML and ZPT. Can I
> suggest some minor changes to the proposed style?

You may.

However, the styles were discussed before and we have to realize that changing 
them means changing a lot of code, since most files follow the guide pretty 
good.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From srichter at cosmos.phy.tufts.edu  Wed Feb 25 11:02:39 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Wed Feb 25 11:03:03 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <403CBB0D.8000108@weitershausen.de>
References: <200402241411.57732.stephan.richter@tufts.edu>
	<403CBB0D.8000108@weitershausen.de>
Message-ID: <200402251102.39609.srichter@cosmos.phy.tufts.edu>

On Wednesday 25 February 2004 10:11, Philipp von Weitershausen wrote:
<snip further cleanup spots>

Yes, all these can be added. I think we should start a page with the tasks and 
a priority list...

> > To make a better release of Zope X3.0 possible, I would suggest that
> > we have a code cleanup day after Zope X3.0 beta 1 somewhen in April.
>
> The idea of a "spring cleaning day" is kinda cool. We could make this an
> annual thing; I'm sure we'll have something to do *every* year.

That name is cool! I hope that by mid-March (shortly after the PyCon sprint), 
we will have a date for the beta at which time I would also schedule this 
day!

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From philipp at weitershausen.de  Wed Feb 25 11:09:56 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Wed Feb 25 11:03:23 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <20040225154824.GF15554@moria.redesul.com.br>
References: <200402241411.57732.stephan.richter@tufts.edu>
	<403CBB0D.8000108@weitershausen.de>
	<20040225154824.GF15554@moria.redesul.com.br>
Message-ID: <403CC8D4.5010602@weitershausen.de>

Sidnei da Silva wrote:
> On Wed, Feb 25, 2004 at 04:11:09PM +0100, Philipp von Weitershausen wrote:
> > 2. Enforce http://dev.zope.org/Zope3/ZCMLStyleGuide. According to what 
> > I've seen in checkins, people seem to have different taste with how ZCML 
> > should be formatted, and seldomly look at the before mentioned style 
> > guide. I've actually seen correct format being "beaufified" incorrectly.
> 
> I'm surprised that such a thing exists. I may not have paid enough
> attention. However, I disagree with some of the suggested
> formatting. I'm currently using emacs nxml-mode (plus a patch to
> indent attributes in multiple lines correctly), and IMHO it does a
> wonderful job at (no-brainer) indenting both ZCML and ZPT. Can I
> suggest some minor changes to the proposed style?

I actually like it the way it is, but that's just me (and SteveA who 
wrote the guide). I might already haven a idea of what the changes are 
you're going to suggest (since you were one of the "beautifiers" :)) but 
it'd be good to have the arguments on the table for discussion.

Philipp


From sidnei at awkly.org  Wed Feb 25 11:14:33 2004
From: sidnei at awkly.org (Sidnei da Silva)
Date: Wed Feb 25 11:15:10 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <200402251100.26248.stephan.richter@tufts.edu>
References: <200402241411.57732.stephan.richter@tufts.edu>
	<403CBB0D.8000108@weitershausen.de>
	<20040225154824.GF15554@moria.redesul.com.br>
	<200402251100.26248.stephan.richter@tufts.edu>
Message-ID: <20040225161433.GI15554@moria.redesul.com.br>

On Wed, Feb 25, 2004 at 11:00:26AM -0500, Stephan Richter wrote:
| You may.
| 
| However, the styles were discussed before and we have to realize that changing 
| them means changing a lot of code, since most files follow the guide pretty 
| good.

I think the main differences are:

 - Don't skip the first identation level
 - Use 2 instead of 4 chars for identing attributes in new lines
 - Indent attribute value to the same level as the starting `"` on the
   previous line, if the value spans multiple lines

Thoughts?

-- 
Sidnei da Silva <sidnei@awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher

"You can't make a program without broken egos."

From philipp at weitershausen.de  Wed Feb 25 11:29:28 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Wed Feb 25 11:22:57 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <20040225161433.GI15554@moria.redesul.com.br>
References: <200402241411.57732.stephan.richter@tufts.edu>
	<403CBB0D.8000108@weitershausen.de>
	<20040225154824.GF15554@moria.redesul.com.br>
	<200402251100.26248.stephan.richter@tufts.edu>
	<20040225161433.GI15554@moria.redesul.com.br>
Message-ID: <403CCD68.1000903@weitershausen.de>

Sidnei da Silva wrote:
> On Wed, Feb 25, 2004 at 11:00:26AM -0500, Stephan Richter wrote:
> > You may.
> > 
> > However, the styles were discussed before and we have to realize that changing 
> > them means changing a lot of code, since most files follow the guide pretty 
> > good.

/me agrees. Still, why would we need a whole day to cleanup stuff if 
we're just dealing with a bunch of files with minor cosmetic problems?

> I think the main differences are:
> 
>  - Don't skip the first identation level

I prefer indenting stuff below the DocumentElement, too.

>  - Use 2 instead of 4 chars for identing attributes in new lines

-1

Using 2 spaces for sub-element indention and 4 for attributes makes it a 
lot easier to read, IMO. You may laugh, but it helps me to distinguish 
attributes from sub-elements.

Btw, I also dislike this notation::

     <security:permission id="zope.View"
                          title="View"
                          />

>  - Indent attribute value to the same level as the starting `"` on the
>    previous line, if the value spans multiple lines

Can you give an example? I'm not sure what you mean, and even if, how is 
it currently violated by current ZCML?

Philipp


From sidnei at awkly.org  Wed Feb 25 11:29:14 2004
From: sidnei at awkly.org (Sidnei da Silva)
Date: Wed Feb 25 11:29:55 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <403CCD68.1000903@weitershausen.de>
References: <200402241411.57732.stephan.richter@tufts.edu>
	<403CBB0D.8000108@weitershausen.de>
	<20040225154824.GF15554@moria.redesul.com.br>
	<200402251100.26248.stephan.richter@tufts.edu>
	<20040225161433.GI15554@moria.redesul.com.br>
	<403CCD68.1000903@weitershausen.de>
Message-ID: <20040225162914.GL15554@moria.redesul.com.br>

| >I think the main differences are:
| >
| > - Don't skip the first identation level
|
| I prefer indenting stuff below the DocumentElement, too.

Good :)

| > - Use 2 instead of 4 chars for identing attributes in new lines
|
| -1
|
| Using 2 spaces for sub-element indention and 4 for attributes makes it a
| lot easier to read, IMO. You may laugh, but it helps me to distinguish
| attributes from sub-elements.

I can live with that. ;)

| Btw, I also dislike this notation::
|
|     <security:permission id="zope.View"
|                          title="View"
|                          />

Yeah, but its better than:

|     <security:permission id="zope.View"
|         title="View"
|         />

While the optimal would be:

|     <security:permission
|         id="zope.View"
|         title="View"
|         />

I can live with the last one, but I prefer the first for elements with
<3 attributes.

| > - Indent attribute value to the same level as the starting `"` on the
| >   previous line, if the value spans multiple lines
|
| Can you give an example? I'm not sure what you mean, and even if, how is
| it currently violated by current ZCML?

I don't think it is violated somewhere, but here goes an example:

Optimal:

    keyword_arguments="type_id other_id name technician_id
                       subject_type_id subject_id comments
                       commit_message collection_date"

Ugly:

    keyword_arguments="type_id other_id name technician_id
    subject_type_id subject_id comments commit_message
    collection_date"

Not-so-good:

    keyword_arguments="type_id other_id name technician_id
        subject_type_id subject_id comments commit_message
        collection_date"

--
Sidnei da Silva <sidnei@awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher

Variables don't; constants aren't.

From faassen at infrae.com  Wed Feb 25 11:52:22 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Wed Feb 25 11:50:01 2004
Subject: [Zope3-dev] dependency checking tool
Message-ID: <403CD2C6.2080000@infrae.com>

Hi there,

I see that Stephan checked in a tool that helps with checking 
dependencies. I would like to point him to import checker:

http://cvs.infrae.com/tools/importchecker/

which while aimed to find unused imports contains much code that could 
be useful for a general dependency analysis tool.

It uses the compiler module to find import statements, can find 
references to imported stuff in the rest of the Python code, keeps a 
database of import statements,  knows how to handle relative imports, etc.

It should be especially easy to fix 'getDependenciesOfPythonFile' to do
something better.

I should really do a new release of this anyway. :)

Regards,

Martijn


From Sylvain.Thenault at logilab.fr  Wed Feb 25 12:08:48 2004
From: Sylvain.Thenault at logilab.fr (Sylvain =?iso-8859-1?Q?Th=E9nault?=)
Date: Wed Feb 25 12:08:54 2004
Subject: [Zope3-dev] dependency checking tool
In-Reply-To: <403CD2C6.2080000@infrae.com>
References: <403CD2C6.2080000@infrae.com>
Message-ID: <20040225170847.GA9554@crater.logilab.fr>

On Wednesday 25 February ? 17:52, Martijn Faassen wrote:
> Hi there,

Hi !
 
> I see that Stephan checked in a tool that helps with checking 
> dependencies. I would like to point him to import checker:
> 
> http://cvs.infrae.com/tools/importchecker/
> 
> which while aimed to find unused imports contains much code that could 
> be useful for a general dependency analysis tool.
> 
> It uses the compiler module to find import statements, can find 
> references to imported stuff in the rest of the Python code, keeps a 
> database of import statements,  knows how to handle relative imports, etc.

notice pylint does import analysis to, among other things

regards
-- 
Sylvain Th?nault                               LOGILAB, Paris (France).

http://www.logilab.com   http://www.logilab.fr  http://www.logilab.org


From stephan.richter at tufts.edu  Wed Feb 25 12:05:10 2004
From: stephan.richter at tufts.edu (Stephan Richter)
Date: Wed Feb 25 12:22:23 2004
Subject: [Zope3-dev] dependency checking tool
In-Reply-To: <403CD2C6.2080000@infrae.com>
References: <403CD2C6.2080000@infrae.com>
Message-ID: <200402251205.10508.stephan.richter@tufts.edu>

On Wednesday 25 February 2004 11:52, Martijn Faassen wrote:
> I see that Stephan checked in a tool that helps with checking
> dependencies. I would like to point him to import checker:
>
> http://cvs.infrae.com/tools/importchecker/

Good point, martijn. I had totally forgotten about the tool!

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From faassen at infrae.com  Wed Feb 25 12:31:09 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Wed Feb 25 12:29:09 2004
Subject: [Zope3-dev] dependency checking tool
In-Reply-To: <20040225170847.GA9554@crater.logilab.fr>
References: <403CD2C6.2080000@infrae.com>
	<20040225170847.GA9554@crater.logilab.fr>
Message-ID: <403CDBDD.3040706@infrae.com>

Sylvain Th?nault wrote:

>notice pylint does import analysis to, among other things
>  
>
Yes, I think I tried pychecker and also pylint at the time (half a year 
ago), but the former was not up to the job and I had trouble getting the 
latter to work.

The advantage of importchecker may be that it just tries to check for 
unused imports, and tries to be very good at it. It may therefore be 
better up to the job of checking the Zope 3 codebase. Of course pylint 
may for all I know be actually better at it. I should try it again. :)

Regards,

Martijn


From faassen at infrae.com  Wed Feb 25 12:32:32 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Wed Feb 25 12:30:07 2004
Subject: [Zope3-dev] importchecker 1.0 released
Message-ID: <403CDC30.3070305@infrae.com>

Hi there,

At long last, I've released importchecker 1.0. This tool can be used to 
check for unused imports in the Zope 3 codebases (and other codebases, 
presumably).

Take a look at it here (as soon as its publication status moves on from 
'pending'..).

http://zope.org/Members/faassen/importchecker

Regards,

Martijn


From mgedmin at b4net.lt  Wed Feb 25 12:35:28 2004
From: mgedmin at b4net.lt (Marius Gedminas)
Date: Wed Feb 25 12:35:54 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <403CBB0D.8000108@weitershausen.de>
References: <200402241411.57732.stephan.richter@tufts.edu>
	<403CBB0D.8000108@weitershausen.de>
Message-ID: <20040225173528.GB18803@perlas>

On Wed, Feb 25, 2004 at 04:11:09PM +0100, Philipp von Weitershausen wrote:
> 5. Make the commonly long list of imports more scrutable.

Also trim imports that are not needed.  I ran a homebrew dependency checker
tool (hi, Martijn, Stephan ;-) on Zope 3 and it reported over 700 unused
imports.  Some of those are false positives, e.g. things that are imported into
__init__.py for API reasons, but other imports can (and should) be safely
removed.

> I haven't 
> found anything in the coding style, but I usually follow this order::
> 
>   1. Import modules from standard python library/global ackages
>   2. Import modules from the 'zope' package
>   3. Import modules from the 'zope.app' package
> 
> while "import XYZ" goes before "from XYZ import ABC".

PEP 8 says

"""
    - Imports are always put at the top of the file, just after any
      module comments and docstrings, and before module globals and
      constants. 

      1. standard library imports
      2. related major package imports (i.e. all email package imports next)
      3. application specific imports

      You should put a blank line between each group of imports.
"""

Marius Gedminas
-- 
If you are angry with someone, you should walk a mile in their shoes... then
you'll be a mile away from them, and you'll have their shoes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20040225/256583b9/attachment.bin
From faassen at infrae.com  Wed Feb 25 12:56:08 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Wed Feb 25 12:53:44 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <20040225173528.GB18803@perlas>
References: <200402241411.57732.stephan.richter@tufts.edu>	<403CBB0D.8000108@weitershausen.de>
	<20040225173528.GB18803@perlas>
Message-ID: <403CE1B8.4030906@infrae.com>

Marius Gedminas wrote:

>On Wed, Feb 25, 2004 at 04:11:09PM +0100, Philipp von Weitershausen wrote:
>  
>
>>5. Make the commonly long list of imports more scrutable.
>>    
>>
>
>Also trim imports that are not needed.  I ran a homebrew dependency checker
>tool (hi, Martijn, Stephan ;-) on Zope 3 and it reported over 700 unused
>imports.  Some of those are false positives, e.g. things that are imported into
>__init__.py for API reasons, but other imports can (and should) be safely
>removed.
>  
>
I can confirm this; the Zope3 codebase picked up tons of unused imports 
since the last cleanup round by Philipp.

My importchecker only picks up 521 unused imports. This includes 
__init__.py API related false positives.

I think importchecker is better at avoiding false positives than your 
homegrown tool. Alternatively of course importchecker is missing a lot 
of real positives. :)

Regards,

Martijn


From chrism at plope.com  Wed Feb 25 13:03:47 2004
From: chrism at plope.com (Chris McDonough)
Date: Wed Feb 25 13:04:29 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <20040225154824.GF15554@moria.redesul.com.br>
References: <200402241411.57732.stephan.richter@tufts.edu>
	<403CBB0D.8000108@weitershausen.de>
	<20040225154824.GF15554@moria.redesul.com.br>
Message-ID: <1077732227.7540.7.camel@athlon>

Sidnei,

Do you think you could share that indent-attributes-aross-multiple-lines
patch for nxml mode?  Also, just curious, I just started using nxml-mode
(as a result of your email), but I wondered if you've found a way to get
it to stop complaining about undefined prefixes for tal: and metal:
namespaces in ZPT?

- C


On Wed, 2004-02-25 at 10:48, Sidnei da Silva wrote:
> On Wed, Feb 25, 2004 at 04:11:09PM +0100, Philipp von Weitershausen wrote:
> | 2. Enforce http://dev.zope.org/Zope3/ZCMLStyleGuide. According to what 
> | I've seen in checkins, people seem to have different taste with how ZCML 
> | should be formatted, and seldomly look at the before mentioned style 
> | guide. I've actually seen correct format being "beaufified" incorrectly.
> 
> I'm surprised that such a thing exists. I may not have paid enough
> attention. However, I disagree with some of the suggested
> formatting. I'm currently using emacs nxml-mode (plus a patch to
> indent attributes in multiple lines correctly), and IMHO it does a
> wonderful job at (no-brainer) indenting both ZCML and ZPT. Can I
> suggest some minor changes to the proposed style?


From chrism at plope.com  Wed Feb 25 13:11:35 2004
From: chrism at plope.com (Chris McDonough)
Date: Wed Feb 25 13:12:14 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <1077732227.7540.7.camel@athlon>
References: <200402241411.57732.stephan.richter@tufts.edu>
	<403CBB0D.8000108@weitershausen.de>
	<20040225154824.GF15554@moria.redesul.com.br>
	<1077732227.7540.7.camel@athlon>
Message-ID: <1077732695.7540.11.camel@athlon>

Duh, nevermind about the namespace question.  I wasn't definining the
xmlns in my top-level tag.

On Wed, 2004-02-25 at 13:03, Chris McDonough wrote:
> Sidnei,
> 
> Do you think you could share that indent-attributes-aross-multiple-lines
> patch for nxml mode?  Also, just curious, I just started using nxml-mode
> (as a result of your email), but I wondered if you've found a way to get
> it to stop complaining about undefined prefixes for tal: and metal:
> namespaces in ZPT?
> 
> - C
> 
> 
> On Wed, 2004-02-25 at 10:48, Sidnei da Silva wrote:
> > On Wed, Feb 25, 2004 at 04:11:09PM +0100, Philipp von Weitershausen wrote:
> > | 2. Enforce http://dev.zope.org/Zope3/ZCMLStyleGuide. According to what 
> > | I've seen in checkins, people seem to have different taste with how ZCML 
> > | should be formatted, and seldomly look at the before mentioned style 
> > | guide. I've actually seen correct format being "beaufified" incorrectly.
> > 
> > I'm surprised that such a thing exists. I may not have paid enough
> > attention. However, I disagree with some of the suggested
> > formatting. I'm currently using emacs nxml-mode (plus a patch to
> > indent attributes in multiple lines correctly), and IMHO it does a
> > wonderful job at (no-brainer) indenting both ZCML and ZPT. Can I
> > suggest some minor changes to the proposed style?
> 
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope3-dev


From faassen at infrae.com  Wed Feb 25 13:21:33 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Wed Feb 25 13:19:50 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <1077732227.7540.7.camel@athlon>
References: <200402241411.57732.stephan.richter@tufts.edu>	<403CBB0D.8000108@weitershausen.de>	<20040225154824.GF15554@moria.redesul.com.br>
	<1077732227.7540.7.camel@athlon>
Message-ID: <403CE7AD.1010802@infrae.com>

Chris McDonough wrote:

>Sidnei,
>
>Do you think you could share that indent-attributes-aross-multiple-lines
>patch for nxml mode?  Also, just curious, I just started using nxml-mode
>(as a result of your email), but I wondered if you've found a way to get
>it to stop complaining about undefined prefixes for tal: and metal:
>namespaces in ZPT?
>
>  
>

Note by the way that there's a (currently unmaintained so slightly 
behind date) Relax NG schema for ZCML in the CVS:

http://cvs.zope.org/Zope3/doc/zcml/

The .rnc file will make nxml-mode magically know about all kinds of ZCML 
attributes. :)

Regards,

Martijn


From sidnei at awkly.org  Wed Feb 25 13:42:42 2004
From: sidnei at awkly.org (Sidnei da Silva)
Date: Wed Feb 25 13:43:16 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <1077732227.7540.7.camel@athlon>
References: <200402241411.57732.stephan.richter@tufts.edu>
	<403CBB0D.8000108@weitershausen.de>
	<20040225154824.GF15554@moria.redesul.com.br>
	<1077732227.7540.7.camel@athlon>
Message-ID: <20040225184242.GP15554@moria.redesul.com.br>

On Wed, Feb 25, 2004 at 01:03:47PM -0500, Chris McDonough wrote:
| Sidnei,
| 
| Do you think you could share that indent-attributes-aross-multiple-lines
| patch for nxml mode?  Also, just curious, I just started using nxml-mode
| (as a result of your email), but I wondered if you've found a way to get
| it to stop complaining about undefined prefixes for tal: and metal:
| namespaces in ZPT?

Sure. Here:
http://groups.yahoo.com/group/emacs-nxml-mode/message/422

[]'s
-- 
Sidnei da Silva <sidnei@awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher

A formal parsing algorithm should not always be used.
		-- D. Gries

From sidnei at awkly.org  Wed Feb 25 13:44:10 2004
From: sidnei at awkly.org (Sidnei da Silva)
Date: Wed Feb 25 13:44:44 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <403CE7AD.1010802@infrae.com>
References: <200402241411.57732.stephan.richter@tufts.edu>
	<403CBB0D.8000108@weitershausen.de>
	<20040225154824.GF15554@moria.redesul.com.br>
	<1077732227.7540.7.camel@athlon> <403CE7AD.1010802@infrae.com>
Message-ID: <20040225184410.GQ15554@moria.redesul.com.br>

On Wed, Feb 25, 2004 at 07:21:33PM +0100, Martijn Faassen wrote:
| Note by the way that there's a (currently unmaintained so slightly 
| behind date) Relax NG schema for ZCML in the CVS:
| 
| http://cvs.zope.org/Zope3/doc/zcml/
| 
| The .rnc file will make nxml-mode magically know about all kinds of ZCML 
| attributes. :)

BTW, how one binds that to .zcml again? I can't remember of the top of
my head.

-- 
Sidnei da Silva <sidnei@awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher

Computers don't actually think.
	You just think they think.
		(We think.)

From faassen at infrae.com  Wed Feb 25 14:25:09 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Wed Feb 25 14:23:36 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <20040225184410.GQ15554@moria.redesul.com.br>
References: <200402241411.57732.stephan.richter@tufts.edu>	<403CBB0D.8000108@weitershausen.de>	<20040225154824.GF15554@moria.redesul.com.br>	<1077732227.7540.7.camel@athlon>
	<403CE7AD.1010802@infrae.com>
	<20040225184410.GQ15554@moria.redesul.com.br>
Message-ID: <403CF695.7050807@infrae.com>

Sidnei da Silva wrote:

>On Wed, Feb 25, 2004 at 07:21:33PM +0100, Martijn Faassen wrote:
>| Note by the way that there's a (currently unmaintained so slightly 
>| behind date) Relax NG schema for ZCML in the CVS:
>| 
>| http://cvs.zope.org/Zope3/doc/zcml/
>| 
>| The .rnc file will make nxml-mode magically know about all kinds of ZCML 
>| attributes. :)
>
>BTW, how one binds that to .zcml again? I can't remember of the top of
>my head.
>  
>

I can't remember from the top of my head either..  I hacked it into a 
.emacs early on but the rng-auto-file-name-alist in there looks pretty 
horrible.

Regards,

Martjn


From stephan.richter at tufts.edu  Wed Feb 25 19:57:33 2004
From: stephan.richter at tufts.edu (Stephan Richter)
Date: Wed Feb 25 19:58:08 2004
Subject: [Zope3-dev] Re: Code cleanup day
In-Reply-To: <20040225161433.GI15554@moria.redesul.com.br>
References: <200402241411.57732.stephan.richter@tufts.edu>
	<200402251100.26248.stephan.richter@tufts.edu>
	<20040225161433.GI15554@moria.redesul.com.br>
Message-ID: <200402251957.34188.stephan.richter@tufts.edu>

On Wednesday 25 February 2004 11:14, Sidnei da Silva wrote:
> ?- Don't skip the first identation level

-1 I was against this too at the beginning, but it takes away space you 
sometimes need for long dotted names. It has not disturbed me too much since 
a while now.

> ?- Use 2 instead of 4 chars for identing attributes in new lines

-1 for the reasons Philipp stated.

> ?- Indent attribute value to the same level as the starting `"` on the
> ? ?previous line, if the value spans multiple lines

Same as Philipp...where is what violated? An example would be nice.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From faassen at infrae.com  Thu Feb 26 06:34:05 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Thu Feb 26 06:31:36 2004
Subject: [Zope3-dev] Re: [Zope3-checkins] CVS: Zope3/src/zope/app/fssync
 -	committer.py:1.23 fsbundle.py:1.5
In-Reply-To: <200402252006.22782.stephan.richter@tufts.edu>
References: <200402252302.i1PN2uWM030049@cvs.zope.org>
	<200402252006.22782.stephan.richter@tufts.edu>
Message-ID: <403DD9AD.30508@infrae.com>

Stephan Richter wrote:

>do you think your tool could also detect situations where functions are 
>imported that should be used via zapi? The getService() function is a good 
>example. 
>  
>

My tool is non-zope3 specific so extending the tool in that direction 
would not be right. But the same technology could of course be used to 
detect particular imports and give some warning according to it.

>Also, you released the import checker under an Infrae license. Would it be 
>possible for you to check in the import checker in Zope3/utilities under ZPL 
>2? This way it is much more natural to use for other people and I can reuse 
>the code for the dependency checker.
>  
>

It's released under the BSD license. The importchecker is not Zope 3 
specific, and I'd rather maintain it myself. If you want to use any code 
of it in some Zope 3 specific tool you have my permission to check it in 
under the ZPL though, or if that's not good enough I'll check in those 
things myself.

Regards,

Martijn


From srichter at cosmos.phy.tufts.edu  Thu Feb 26 06:50:29 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Thu Feb 26 06:50:53 2004
Subject: [Zope3-dev] Re: [Zope3-checkins] CVS: Zope3/src/zope/app/fssync
	=?iso-8859-1?q?-=09committer=2Epy=3A1=2E23?= fsbundle.py:1.5
In-Reply-To: <403DD9AD.30508@infrae.com>
References: <200402252302.i1PN2uWM030049@cvs.zope.org>
	<200402252006.22782.stephan.richter@tufts.edu>
	<403DD9AD.30508@infrae.com>
Message-ID: <200402260650.29875.srichter@cosmos.phy.tufts.edu>

On Thursday 26 February 2004 06:34, Martijn Faassen wrote:
> It's released under the BSD license. The importchecker is not Zope 3
> specific, and I'd rather maintain it myself. If you want to use any code
> of it in some Zope 3 specific tool you have my permission to check it in
> under the ZPL though, or if that's not good enough I'll check in those
> things myself.

Yeah, please check it in. I cannot check it in; you would have to do it.

Thanks!

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From faassen at infrae.com  Thu Feb 26 07:38:24 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Thu Feb 26 07:35:55 2004
Subject: [Zope3-dev] Re: [Zope3-checkins] CVS: Zope3/src/zope/app/fssync
	- committer.py:1.23 fsbundle.py:1.5
In-Reply-To: <200402260650.29875.srichter@cosmos.phy.tufts.edu>
References: <200402252302.i1PN2uWM030049@cvs.zope.org>	<200402252006.22782.stephan.richter@tufts.edu>	<403DD9AD.30508@infrae.com>
	<200402260650.29875.srichter@cosmos.phy.tufts.edu>
Message-ID: <403DE8C0.3010705@infrae.com>

Stephan Richter wrote:

>On Thursday 26 February 2004 06:34, Martijn Faassen wrote:
>  
>
>>It's released under the BSD license. The importchecker is not Zope 3
>>specific, and I'd rather maintain it myself. If you want to use any code
>>of it in some Zope 3 specific tool you have my permission to check it in
>>under the ZPL though, or if that's not good enough I'll check in those
>>things myself.
>>    
>>
>
>Yeah, please check it in. I cannot check it in; you would have to do it.
>  
>
There's now a ZPL licensed version the utilities directory of Zope 3.

Regards,

Martijn


From dev at projekt01.ch  Thu Feb 26 09:30:15 2004
From: dev at projekt01.ch (Roger ineichen)
Date: Thu Feb 26 09:31:56 2004
Subject: [Zope3-dev] error by calling a html page
Message-ID: <000201c3fc75$0db38d70$1e63a8c0@projekt01.local>

If I call a html page on the server 
sometimes I get the following error
but the resulting html page is ok.

...
Traceback (most recent call last):
  File "C:\projektCompiler\current\src\zope\server\taskthreads.py", line 48,
in handlerThread
    task.service()
  File "C:\projektCompiler\current\src\zope\server\http\httptask.py", line
79, in service
    self.channel.end_task(self.close_on_finish)
  File "C:\projektCompiler\current\src\zope\server\serverchannelbase.py",
line 220, in end_task
    self.close_when_done()
  File "C:\projektCompiler\current\src\zope\server\dualmodechannel.py", line
191, in close_when_done
    while self._flush_some():
  File "C:\projektCompiler\current\src\zope\server\dualmodechannel.py", line
183, in _flush_some
    num_sent = self.send(chunk)
  File "c:\Python23\lib\asyncore.py", line 334, in send
    raise socket.error, why
error: (10054, 'Connection reset by peer')
...

Does anybody have the same error or
can anybody say what's wrong?

regards
Roger Ineichen
_____________________________
Projekt01 GmbH
www.projekt01.ch
Langackerstrasse 8
6330 Cham
phone     +41 (0)41 781 01 78
mobile    +41 (0)79 340 52 32
fax       +41 (0)41 781 00 78
email r.ineichen@projekt01.ch
_____________________________
END OF MESSAGE


From tseaver at zope.com  Thu Feb 26 10:31:44 2004
From: tseaver at zope.com (Tres Seaver)
Date: Thu Feb 26 10:31:50 2004
Subject: [Zope3-dev] Re: error by calling a html page
In-Reply-To: <000201c3fc75$0db38d70$1e63a8c0@projekt01.local>
References: <000201c3fc75$0db38d70$1e63a8c0@projekt01.local>
Message-ID: <403E1160.4090208@zope.com>

Roger ineichen wrote:
> If I call a html page on the server 
> sometimes I get the following error
> but the resulting html page is ok.
> 
> ...
> Traceback (most recent call last):
>   File "C:\projektCompiler\current\src\zope\server\taskthreads.py", line 48,
> in handlerThread
>     task.service()
>   File "C:\projektCompiler\current\src\zope\server\http\httptask.py", line
> 79, in service
>     self.channel.end_task(self.close_on_finish)
>   File "C:\projektCompiler\current\src\zope\server\serverchannelbase.py",
> line 220, in end_task
>     self.close_when_done()
>   File "C:\projektCompiler\current\src\zope\server\dualmodechannel.py", line
> 191, in close_when_done
>     while self._flush_some():
>   File "C:\projektCompiler\current\src\zope\server\dualmodechannel.py", line
> 183, in _flush_some
>     num_sent = self.send(chunk)
>   File "c:\Python23\lib\asyncore.py", line 334, in send
>     raise socket.error, why
> error: (10054, 'Connection reset by peer')
> ...
> 
> Does anybody have the same error or
> can anybody say what's wrong?

This error shows up only in your debug log / sytem_error object, right? 
  It indicates that the user killed the browser before Medusa had 
finished pushing the page;  basically, you don't need to worry about it, 
except that it may be a warning sign that your pages are taking too long 
to render.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com


From hancock at anansispaceworks.com  Thu Feb 26 11:33:00 2004
From: hancock at anansispaceworks.com (Terry Hancock)
Date: Thu Feb 26 11:21:14 2004
Subject: [Zope3-dev] Interfaces in Zope 2.5, 2.7, and 3.x
Message-ID: <m1AwOFs-007o04C@mail.augustmail.com>

I have a product that uses a component/interface model
internally.  I wrote this against the "scarecrow" Interface 
module in Zope 2.5.1.

However that module has limitations.  One particular one is
what I call a "SubInterface" -- which is a special case of 
Interface.Attribute (a subclass of it) that asserts that an
object contained within a parent interface implements a
particular interface.

So, for example, a SubInterface might say that in order to
conform to interface "foo", the attribute "bar" must point to
an object which implements "Mapping" (e.g. a dictionary --
it doesn't have to *be* a dictionary, but it must act like one).

Anyway, I wrote my own interface module to do this,
extending the Interface module in Zope 2.5.1 (which lacks
this feature).  All of my code actually imports interface support
from my module instead of directly from Interface.

For unrelated reasons, though, I had to upgrade to Zope 2.7
(and someday, I imagine I'll want to consider moving to Zope 3.x).

My first attempt with Zope 2.7, though yields total breakage!

The Interface module has been extensively overhauled, method
names changed, etc. After giving up on "just fixing a few name-
changes", which seems to be woefully inadequate, I decided to
try to lift the old Interface module -- but now Zope reads the 
"__implements__" attribute and isn't happy if it isn't one of its own
interface objects!

"""
Installing Narya ... Traceback (most recent call last):
  File "./testNaryaInterface.py", line 11, in ?
    ZopeTestCase.installProduct('Narya')
  File "/usr/local/narya/z2.7.0/lib/python/Testing/ZopeTestCase/ZopeLite.py", line 119, in installProduct
    get_folder_permissions(), raise_exc=1)
  File "/usr/local/narya/z2.7.0/lib/python/OFS/Application.py", line 732, in install_product
    initmethod(context)
  File "/usr/local/narya/zope/Products/Narya/__init__.py", line 25, in initialize
    icon='www/Icon/Thread.gif')
  File "/usr/local/narya/z2.7.0/lib/python/App/ProductContext.py", line 176, in registerClass
    interfaces = instancesOfObjectImplements(instance_class)
  File "/usr/local/narya/z2.7.0/lib/python/Interface/Implements.py", line 120, in instancesOfObjectImplements
    visitImplements(implements, klass, r.append, getInterface)
  File "/usr/local/narya/z2.7.0/lib/python/Interface/Implements.py", line 90, in visitImplements
    raise Exceptions.BadImplements(
Interface.Exceptions.BadImplements: __implements__ should be an interface or tuple,
                not a instance pretending to be a Interface
"""
(Seems I'm a pretender ;-) ).

Now, I can implement a new module based on the Zope 2.7 Interface -- but
a close look at that seems to show that it, too, is rather experimental (lots of
stubs, not-yet-implemented attributes, etc).  So I'm also sort of interested in
the "interface" module in Zope X3.

It appears that some new bells and whistles have been added to the
Interface module (e.g. what's a "superinterface"?).   Any chance, I'm
wondering if "SubInterface" is now redundant?

Also, is there a general guide to "best practice" of using / learning the
Interface module?  I note there are now interfaces defined for the interface
module (cool!), and it looks like some self-documentation has been
implemented.

The biggest problem (and this seems to be the usual problem with
"self-documenting" tools) is that there doesn't seem to be a "start here"
defined anywhere.  So you wind up starting somewhere in the middle and
wasting a lot of time trying to decipher the big picture from lots of details,
which is backwards. It'd be nicer if there was a "README" to get you started
on this, maybe define some jargon, etc.  It's really hard to infer what the
overall design concept is by only looking at these details -- in particular,
I want to know what was conceptually changed from the older Interface
module in 2.5.1.

This seems to also be a problem with combining Zope 3 and Zope 2
interfaces, as was suggested by a post on the Zope3 mailing list:

http://mail.zope.org/pipermail/zope3-dev/2003-December/009023.html
(and following -- note that "__interfaces__" should read "__implements__"
in the original post).

Martijn's suggestion was to use an alternate name for the "__implements__"
attribute.  I suppost I could do that -- call mine "__narya_interfaces__", but
that sounds ugly.  In particular, I don't really want my interfaces module
to actually *conflict* with Zope's.

I also note that the post from the Zope3 list suggests that I shouldn't
really be directly assigning "__implements__", but using something called
"implements()".  Hmm. That's different too -- is there any good starting
place for understanding Zope3's "interface" module?

And how different are the Zope 2.7 / Zope X3 interface modules?  If I
re-write my module to conform to Zope 2.7, will I just have to do it
again?

Could I instead leap ahead and use the Zope X3 interface module in
Zope 2.7?

Also, since I'm posting to Zope3-dev as well -- what do you think of the
SubInterface concept?  Should I be contributing code directly to Zope X3's
interface instead of subclassing it?

All it requires is something like:

"""
class SubInterface(Attribute):
    """
    A SubInterface is an Attribute with an assigned Interface.
    """
    def __init__(self, __name__=None, __doc__=None, api=None, optional=0):
        self.__name__=__name__
        self.__doc__=__doc__ or __name__
	self.api = api
	self.optional = optional
"""

Which is what my module defines -- the trickier bit is defining a function to
recursively check SubInterfaces.  That's included too, but it breaks due to
major API changes in Interface.

Cheers,
Terry


--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com

From sf at nuxeo.com  Thu Feb 26 11:35:51 2004
From: sf at nuxeo.com (Stefane Fermigier)
Date: Thu Feb 26 12:41:00 2004
Subject: [Zope3-dev] Re: importchecker 1.0 released
In-Reply-To: <403CDC30.3070305@infrae.com>
References: <403CDC30.3070305@infrae.com>
Message-ID: <403E2067.5050001@nuxeo.com>

Martijn Faassen wrote:
> Hi there,
> 
> At long last, I've released importchecker 1.0. This tool can be used to 
> check for unused imports in the Zope 3 codebases (and other codebases, 
> presumably).
> 
> Take a look at it here (as soon as its publication status moves on from 
> 'pending'..).
> 
> http://zope.org/Members/faassen/importchecker

Great job ! Thank you Martijn !

	S.

-- 
St?fane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile).
Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps
Gestion de contenu web / portail collaboratif / groupware / open source!



From sf at nuxeo.com  Thu Feb 26 14:10:05 2004
From: sf at nuxeo.com (Stefane Fermigier)
Date: Thu Feb 26 14:10:12 2004
Subject: [Zope3-dev] Re: importchecker 1.0 released
In-Reply-To: <403CDC30.3070305@infrae.com>
References: <403CDC30.3070305@infrae.com>
Message-ID: <403E448D.5020403@nuxeo.com>

Martijn Faassen wrote:
> Hi there,
> 
> At long last, I've released importchecker 1.0. This tool can be used to 
> check for unused imports in the Zope 3 codebases (and other codebases, 
> presumably).
> 
> Take a look at it here (as soon as its publication status moves on from 
> 'pending'..).
> 
> http://zope.org/Members/faassen/importchecker

Small problems:

(in BaseBox.py):
from Products.CMFCore.TypesTool import TypeInformation
...

TypeInformation.manage_propertiesForm = 
PropertyManager.manage_propertiesForm

but:

dev2% importchecker .
BaseBox.py:42: TypeInformation

	S.

-- 
St?fane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile).
Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps
Gestion de contenu web / portail collaboratif / groupware / open source!



From MYACNDSBWOAUP at lmb.uni-muenchen.de  Thu Feb 26 19:37:09 2004
From: MYACNDSBWOAUP at lmb.uni-muenchen.de (Marcia Donovan)
Date: Thu Feb 26 19:40:31 2004
Subject: [Zope3-dev] didn't go to college - that's ok we'll give you a
	diploma
Message-ID: <DYSKRXDVONELQFSMZWSK@cc.rim.or.jp>

An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/zope3-dev/attachments/20040226/eb5a27bc/attachment.html
From philipp at weitershausen.de  Fri Feb 27 08:01:09 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Fri Feb 27 07:55:22 2004
Subject: [Zope3-dev] More in zope.app: securitypolicy and wiki
Message-ID: <c1nenj$jh0$1@sea.gmane.org>

Hello there,

I just moved two more packages from zope.products to zope.app: 
securitypolicy and wiki.

Wiki being moved shouldn't affect anyone since it's broken anyway. As 
for securitypolicy, it is now included by zope.app's configure.zcml 
file. Thus, you will need to remove the corresponding line from your 
products.zcml to avoid configuration conflicts.

Philipp



From casey at zope.com  Fri Feb 27 14:15:52 2004
From: casey at zope.com (Casey Duncan)
Date: Fri Feb 27 14:18:44 2004
Subject: [Zope3-dev] Re: More in zope.app: securitypolicy and wiki
References: <c1nenj$jh0$1@sea.gmane.org>
Message-ID: <20040227141552.34947c59.casey@zope.com>

On Fri, 27 Feb 2004 14:01:09 +0100
Philipp von Weitershausen <philipp@weitershausen.de> wrote:

> Hello there,
> 
> I just moved two more packages from zope.products to zope.app: 
> securitypolicy and wiki.

You moved wiki into zope.app? Not sure that makes much sense to me.

-Casey


From pje at telecommunity.com  Fri Feb 27 14:56:22 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri Feb 27 14:56:29 2004
Subject: [Zope3-dev] Distutils dependencies sprint at PyCon?
Message-ID: <5.1.1.6.0.20040227142938.01ea8030@mail.rapidsite.net>

Bob Ippolito and I have been talking about working on distutils dependency 
support while at PyCon.  The subject has recently come up on both the 
Zope3-Dev and Twisted mailing lists, with respect to being able to:

1) break up monolithic systems (PEAK, Zope, Twisted) into smaller package 
sets with dependencies

2) allow dependencies on other systems (e.g. Twisted using PyProtocols, 
PEAK using zope.publisher, etc.)

3) support painless install for end users (single command to download and 
install "everything needed") even at the cost of a little pain for the 
packager(s).

4) allow dependencies on packages that were packaged with the distutils, 
but *not* specifically designed to work with the dependency system.  In 
other words, if I want to depend on package X, I should not need to bug 
package X's author, I should be able to "just do it".

5) Support Python 2.2, while not requiring changes to the distutils, but 
being a possible candidate for upgrades to the distutils in 2.4.

If there's a group that would like to sprint to produce working 
deliverables for one or more aspects of this problem area (and I think 
PIMP/PackMan shows that solutions are within reach), I'd like to get some 
schedule commitments so I can plan a trip.  I wasn't originally planning to 
go to PyCon this year, but I *will* come if it means we can get this thing 
implemented.

If there is sufficient interest, let's take this to an appropriate mailing 
list (perhaps distutils-sig?) and Wiki to put together a detailed set of 
stories, as long as we can prioritize the list according to the needs of 
the folks who will be doing the development.

If you're interested in participating in such a sprint, please let me know 
ASAP, so I can make travel arrangements.  Thanks.

(Please reply to me personally rather than to the list(s); I will summarize 
and post an announcement of where to direct further discussion, if there's 
enough interest to get this off the ground.  Thanks!)



From chrism at plope.com  Fri Feb 27 15:20:06 2004
From: chrism at plope.com (Chris McDonough)
Date: Fri Feb 27 15:20:44 2004
Subject: [Zope3-dev] More in zope.app: securitypolicy and wiki
In-Reply-To: <c1nenj$jh0$1@sea.gmane.org>
References: <c1nenj$jh0$1@sea.gmane.org>
Message-ID: <1077913206.16759.290.camel@athlon>

Note that we moved securitypolicy into products out of app about a month
ago.  I'm not sure products is where it should go, but the intent was to
indicate that the security policy is a default, and may be replaced with
another implementation.  'app' doesn't feel like that sort of place to
me, but then again, I've lost track of what it was supposed to mean long
ago.  I wonder if maybe there should be a zope.default package where
default implementations of things that are meant to be completely
pluggable should go?

- C

On Fri, 2004-02-27 at 08:01, Philipp von Weitershausen wrote:
> Hello there,
> 
> I just moved two more packages from zope.products to zope.app: 
> securitypolicy and wiki.
> 
> Wiki being moved shouldn't affect anyone since it's broken anyway. As 
> for securitypolicy, it is now included by zope.app's configure.zcml 
> file. Thus, you will need to remove the corresponding line from your 
> products.zcml to avoid configuration conflicts.
> 
> Philipp
> 
> 
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope3-dev


From jim at zope.com  Fri Feb 27 15:43:29 2004
From: jim at zope.com (Jim Fulton)
Date: Fri Feb 27 15:51:46 2004
Subject: [Zope3-dev] Re: More in zope.app: securitypolicy and wiki
In-Reply-To: <20040227141552.34947c59.casey@zope.com>
References: <c1nenj$jh0$1@sea.gmane.org>
	<20040227141552.34947c59.casey@zope.com>
Message-ID: <403FABF1.2050604@zope.com>

Casey Duncan wrote:
> On Fri, 27 Feb 2004 14:01:09 +0100
> Philipp von Weitershausen <philipp@weitershausen.de> wrote:
> 
> 
>>Hello there,
>>
>>I just moved two more packages from zope.products to zope.app: 
>>securitypolicy and wiki.
> 
> 
> You moved wiki into zope.app? Not sure that makes much sense to me.

We've decided to get rid of the app/products distinction, as it is
too transitory.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From ffrhyuxc at yahoo.com  Fri Feb 27 17:04:47 2004
From: ffrhyuxc at yahoo.com (rudolfo vrtilek)
Date: Fri Feb 27 17:10:29 2004
Subject: [Zope3-dev] increase her pleasurelavajo
Message-ID: <ZQSJYUQWNONSFNUQTLZXC@yahoo.com>

An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/zope3-dev/attachments/20040227/c35ff9f6/attachment.html
From philipp at weitershausen.de  Sat Feb 28 03:48:18 2004
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Sat Feb 28 04:42:48 2004
Subject: [Zope3-dev] More in zope.app: securitypolicy and wiki
In-Reply-To: <1077913206.16759.290.camel@athlon>
References: <c1nenj$jh0$1@sea.gmane.org> <1077913206.16759.290.camel@athlon>
Message-ID: <1077958098.404055d255601@www.philikon.de>

Chris McDonough wrote:
> Note that we moved securitypolicy into products out of app about a month
> ago.  I'm not sure products is where it should go, but the intent was to
> indicate that the security policy is a default, and may be replaced with
> another implementation.  'app' doesn't feel like that sort of place to
> me, but then again, I've lost track of what it was supposed to mean long
> ago.  I wonder if maybe there should be a zope.default package where
> default implementations of things that are meant to be completely
> pluggable should go?

I know that securitypolicy was moved to zope.products a while ago. But then we 
decided that it's not a good idea to let the location of a package determine 
whether it's core Zope or something you should override, or whether it'll be 
part of the standard distribution or not.

As a result, we abolished the idea of zope.products and moved everything back to 
zope.app. We're currently flattenning zope.app (combine implementations, 
interfaces and browser views) in order to obtain individual packages with 
well-defined dependencies. To speak with Jim's words, zope.app "will be broad 
and shallow".

I know there hasn't exactly been a proposal for this, only Jim's preproposal and 
the large discussion on zope3-dev. The objective is quite clear though, sorry 
you missed it. I guess we should write it down.

Philipp


From dev at projekt01.ch  Sat Feb 28 10:08:46 2004
From: dev at projekt01.ch (Roger ineichen)
Date: Sat Feb 28 10:10:23 2004
Subject: [Zope3-dev] product installer? because of bootstrap hock
Message-ID: <000601c3fe0c$c47b1850$1e63a8c0@projekt01.local>

Dear zope3 dev members,

If somebody is developing a product with a own service and
content objects in this service. They have to install the 
service first and add content objects via TTW to this service.
Or add the service via own bootstrap class.

For Zope stuff, this is done in app.process.bootstrap.py

Now somebody is developing a product there whould be nice to have
a product installer service. 

The product installer service should do:
1. register services to the installer with .zcml
2. bootstrap the registred services
3. register content objects to the service (if needed)
   or do somthing with the content objects and service.
4. Deinstall the product in TTW (this should deinstall 
   the services and make shure next time we start zope
   we don't have broken services in zodb.)

5. Perhaps we can also install the product via TTW

I'm realy not sure if there is such a mechanism 
allready in Zope3. Perhaps I missed somthing?

Is anybody starting somthing like this? 

Or should I first develope a product like this
in Zope3 Products. That we can see it's usable?

regards
Roger
_____________________________
END OF MESSAGE


From jan at curpheymedia.com  Sat Feb 28 18:10:55 2004
From: jan at curpheymedia.com (Jan Smith)
Date: Sat Feb 28 18:11:03 2004
Subject: [Zope3-dev] Melbourne Summer Zope 3 Sprint Summary
In-Reply-To: <E1AwlR1-0007w6-No@mail.python.org>
References: <E1AwlR1-0007w6-No@mail.python.org>
Message-ID: <40411FFF.8020407@curpheymedia.com>

Hi All,

Here's a summary of the Zope 3 Development Summer Sprint held on 4th - 
9th February.

http://www.ozzope.org/2ndsprint/2ndOzSprintWiki

Jan Smith



From hancock at anansispaceworks.com  Sun Feb 29 00:27:15 2004
From: hancock at anansispaceworks.com (Terry Hancock)
Date: Sun Feb 29 00:15:09 2004
Subject: [Zope3-dev] "Sub interface"
Message-ID: <m1AxJI9-007pBSC@mail.augustmail.com>

I have researched the Wikis and ML archives regarding 
interface implementations in Zope, and have not found
anywhere the concept of a "sub-interface" which I 
implemented because I found it indispensable in my
product design.

A sub-interface inherits from Interface.Attribute, but
has an extra property specifying the expected interface
of the attribute.

This is very much inline with the idea of having method
attributes that specify the expected calling signature,
as indeed, Interface.Method lets you do.

This is much better than specifying the Attribute's type, 
for the same reason that interfaces are better than pure 
inheritance.  And also because it's much more flexible.

Needless to say, this works recursively -- a subinterface
may itself have subinterfaces specified.

In addition to providing the recursive definitions, of 
course, my module provides a verification function that 
chases down the subinterfaces and checks them, thus doing a 
more thorough interface check than is included in 
Interface.verify.  It's actually this part that breaks due 
to API changes.

I can provide detailed use-cases if they aren't obvious to 
you, but here's just a suggestion:

Consider, for example, the case of an attribute of a 
document called "license" which should implement a 
particular licensing interface, that, for example, explains 
what can legally be done with the document, and may 
actually control compliance.  The document will likely 
point to a "license object" which specifically implements 
say "GPL" or "MIT" or "DSL" licensing rules within a CMS.

You don't want this document to inherit directly from the 
appropriate license -- you want it to be represented as an 
attribute. You might even have many objects point to the 
same license object, for example.

Anyway, the reason this came up is because I wrote it as an 
extension to the "Interface" module provided in Zope 2.5.1. 
That has changed extensively, and my code is now completely 
broken in Zope 2.7 (it's beyond a few name fixes -- I need 
to just rewrite the thing.  Fortunately it's less than 100 
loc or so).

So I want to answer the strategic question of how to 
proceed with fixing this problem.  Should I:

0) Lift the 2.5 code and insert it into my product source 
tree?  (I guess not -- tried it already, this fails with a 
traceback, apparently having to do with the fact that Zope 
can't coexist with my interfaces on the __implements__ 
attribute.  A ML thread suggests the same problem occurs 
when mixing Zope 2 and 3 interfaces).

1)  Port my code to be consistent with 2.7?  (In which 
case, what exactly changed and why?  I see new interface 
declarations for interfaces themselves, which is cool, and 
some of the functions and methods changed names. I also am 
disturbed to find the term "superinterface" which I don't 
understand -- and there are other intimations of new 
concepts here which I can't find any description of).

2) Port my code to be consistent with X3?  I'd like to 
leapfrog to the newest implementation.  But this will have 
to be included in my own sources to work with Zope 2.7, and 
I'll have the same problem as with using the 2.5.1 
implementation, won't I?

3) Actually write this feature into the X3 "interface" 
module as a contribution to the Zope sources.  Seems like 
it would be useful to others, and it should be just as 
easy. For my immediate use, though, it looks like I have 
the same problem as 0 & 2 for use with 2.7.

4) Contribute it also to the Zope 2.7 "Interface" module,
which I guess would mean having it included in some Zope 
2.x release.

A cursory look at the Zope 2.7 Interface and Zope X3 
interface modules suggests that they are pretty similar, 
but not identical.  How much change has gone on? Especially 
at the conceptual level where it will mean more than just 
subbing a few names?

Anyway, I'm looking for comments or advice on how to pursue 
this.

Thanks, 
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com

From kbvscs at cyber.net.pk  Sun Feb 29 02:16:56 2004
From: kbvscs at cyber.net.pk (Tyler Barber)
Date: Sun Feb 29 00:21:04 2004
Subject: [Zope3-dev] Make more money in stocks than ever before with this
	hot pick p den
Message-ID: <7u$c0vd3548rq--6uaa4-0-1@1mm8uutt>

Wall Street Financial Times Newsletter

Specializing in Undervalued Small Cap Stocks for Immediate Breakout

We have the #1 track record for our picks in 2004:

GETC at .12		Currently .50	High .68 UP 467%
TLPE at 1.12	Currently 3.35	High 4.40 UP 293%
SWYC at .18 	Currently .71	High .81 UP 350%
DNYY at .47	Currently 1.42	High 1.85 UP 294%

Immediate Investor Recommendation
Our Hottest Sales and Earnings Play
Projected to Triple in 7 Days:

Life Energy and Technology Holdings, Inc.
(OTCBB: LETH)

Price--- 1.35

Sales Orders Received '03--- over $150 Million +300% growth vs. '02
Est. Sales Growth '04--- +165%
Results from latest 10-Q:
Total Assets--- 36.8 million vs. 16.8 million
Cash--- 23.4 million vs. deficit
Shareholders Equity--- 12.0 million vs. 2.2 million
Shares Outstanding--- 29 mill
Est. Shares in Float--- 7 mill
Proj. Value Per Share--- 3.25 -- 3.50
Rating--- Urgent Buy

LETH is thriving as an emerging world leader in the conversion of waste 
materials into electrical energy by utilizing their Biosphere Process System, 
making them the hottest undervalued stock at this price level where shares 
are ready to explode on huge investor attention.

Sales have rocketed beyond all estimates for LETH with no signs of 
slowing. The numbers continue to stack-up as sales orders for the Biosphere 
exceed $150 Million over the past year while the stock price doesn't yet 
reflect the appearance of these impressive figures on an upcoming balance 
sheet. We are not the first to uncover this phenomenon as the stock is under 
accumulation, but we are acting aggressively on this recently filed data.

The unique proprietary technology of the Biosphere fills an urgent 
worldwide need for cost-effective renewable energy sources and a 
corresponding universal need to solve critical problems in the disposal of 
waste. The Biosphere System provides the highest level of innovative 
technology while securing worldwide acceptance for a revolutionary product 
designed to significantly impact the global waste problem while 
simultaneously generating electricity. 

The Biosphere System enables LETH to draw revenue from the disposal of 
various types of waste at 5 to 7 tons per hour including such materials as:
Municipal Solid Waste, refinery wastes, agricultural surpluses or effluents, 
medical waste, industrial waste, shale oil, sour natural gas, and the huge 
market of used tires are all converted in the Biosphere Process. LETH also
profits from the sale of electricity created from the waste conversion on a 
continuous basis by generating 5 to 10 mega-watts per hour of electricity 
which is then sold to replenish the local or national grid. 

LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $20) a 
leader and one of the largest providers in environmental, mechanical, and 
electrical management consulting services primarily for the US Government 
with annual sales of $800 Million. Tetra Tech will coordinate permitting, 
installation and continuous worldwide monitoring of the Biosphere Process 
System for LETH. Tetra Tech is now in the process of obtaining Department 
of Environmental Quality permitting for the Biosphere Process in the state of 
Louisiana. This is a monumental event for LETH which opens the 
floodgates for major project revenues in Louisiana while having a parallel 
effect on LETH stock in the form of a huge near-term announcement. 

LETH has begun to catch the profit-making attention of investors by 
embracing a major foothold on the global waste problem while a major push 
for generating electricity from alternative sources continues to be the hot 
topic due to shortages and massive power failures. LETH contains all the 
ingredients for major profits as global demand to solve two crisis areas, 
waste and electrical energy, reaches unprecedented levels. We view this 
perfectly timed convergence of events as the catalyst for additional contracts 
that will perpetuate the shattering of the Company's own sales records. We 
are seeing substantial gains for early investors in a ground floor opportunity 
that carries our highest rating for short-term trading profits.

Required LETH information: Certain statements contained in this newsletter 
may be forward looking statements within the meaning of The Private 
Securities Litigation Reform Act of 1995. Such terms as "expect", "believe", 
"may", "will", and "intend" or similar terms may identify these statements 
We are not a registered investment advisor or a broker dealer. This is not an 
offer to buy or sell securities. No recommendation that the securities of the 
companies profiled should be purchased, sold or held by individuals or 
entities that learn of the profiled companies. This is an independent 
electronic publication that was paid five thousand dollars by an unaffiliated 
third party for the preparation of this company information. Be advised that 
investments in companies profiled are considered to be high-risk and use of 
the content provided is for information purposes only. If anyone decides to 
act as an investor they are advised not to invest without the proper guidance 
from a financial advisor or a registered financial broker. If any party decides 
to participate as an investor then it will be that investor's sole risk. Be 
advised that the purchase of such high-risk securities may result in the loss 
of some or all of the investment. Investors should not rely solely on the 
information presented. Rather, investors should use the information provided 
in this newsletter as a starting point for doing additional independent 
research on the profiled companies in order to allow the investor to form 
their own opinion regarding investing in the profiled companies. Factual 
statements made about the profiled companies are made as of the date stated 
and are subject to change without notice. Investing in micro-cap securities is 
highly speculative and carries an extremely high degree of risk. All 
information provided about the profiled companies may include information 
provided by outside sources, such as research reports, public filings, and 
information provided by management of the profiled company. 

jl sw kl z
 xfmp lp
e pid wgsqqcrocsl cbg
u a codf avt
z bm imfs
i b xiqpt mpau
From srichter at cosmos.phy.tufts.edu  Sun Feb 29 03:11:22 2004
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Sun Feb 29 03:12:28 2004
Subject: [Zope3-dev] "Sub interface"
In-Reply-To: <m1AxJI9-007pBSC@mail.augustmail.com>
References: <m1AxJI9-007pBSC@mail.augustmail.com>
Message-ID: <200402290311.23591.srichter@cosmos.phy.tufts.edu>

On Sunday 29 February 2004 00:27, Terry Hancock wrote:
> A sub-interface inherits from Interface.Attribute, but
> has an extra property specifying the expected interface
> of the attribute.

For this we have fields. I just checked and you cannot specify the interface 
of a field, but this can be easily done: 

class GeneralField(Field):

    def __init__(self, *args, **kwargs):
          if "interface" in kwargs:
               self._interface = kwargs["interface"]
               del kwargs["interface"]
          else:
               ValueError, "'interface' argument missing."

          super(GeneralField, self).__init__(*args, **kwargs)

    def _validate(self, value):
        try:
            verifyObject(value, self._interface)
        except Invalid, err:
            raise ValidationError("Value does not implement %s"     
                                               %self._interface.name())

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From jim at zope.com  Sun Feb 29 12:02:45 2004
From: jim at zope.com (Jim Fulton)
Date: Sun Feb 29 12:03:29 2004
Subject: [Zope3-dev] "Sub interface"
In-Reply-To: <200402290311.23591.srichter@cosmos.phy.tufts.edu>
References: <m1AxJI9-007pBSC@mail.augustmail.com>
	<200402290311.23591.srichter@cosmos.phy.tufts.edu>
Message-ID: <40421B35.90707@zope.com>

Stephan Richter wrote:
> On Sunday 29 February 2004 00:27, Terry Hancock wrote:
> 
>>A sub-interface inherits from Interface.Attribute, but
>>has an extra property specifying the expected interface
>>of the attribute.
> 
> 
> For this we have fields. I just checked and you cannot specify the interface 
> of a field,

Yes you can:

import zope.interface
import zope.schema


class IFoo(zope.interface.Interface)

   myattr = zope.schema.Object(schema=IBar)


This schema field type was added in the Winter 2003 OzZope
sprint.  It is undortunate that the keyword argument name
is scheme. This should be changed to interface, or perhaps type.

Jim


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Sun Feb 29 11:50:04 2004
From: jim at zope.com (Jim Fulton)
Date: Sun Feb 29 12:13:45 2004
Subject: [Zope3-dev] product installer? because of bootstrap hock
In-Reply-To: <000601c3fe0c$c47b1850$1e63a8c0@projekt01.local>
References: <000601c3fe0c$c47b1850$1e63a8c0@projekt01.local>
Message-ID: <4042183C.2010903@zope.com>

Roger ineichen wrote:
> Dear zope3 dev members,
> 
> If somebody is developing a product with a own service  and
 > content objects in this service.

I discourage product authors from providing new services.
Most cases where this has is done are better served by utilities.

We are activell replacing most such services with utilities.

 > They have to install the
> service first and add content objects via TTW to this service.

Or use file-system based blugins.  But, again. utilities are better.

> Or add the service via own bootstrap class.

Basically, you need to create a subscriber to DatabaseOpened events.

Because the current event system is to complex, you seem to
have to write a class.  Most subscribers are more naturally written
as functions.  The zope.app.event.function.Subscriber class makes this
easier.

> For Zope stuff, this is done in app.process.bootstrap.py

This should be more distributed than it is. There's too much
stuff in this file, and inheritence makes it more complex than it
should be.

Even if you think it makes sense to provide a new service, I question
whether it should be automagically installed by a bootstrapping process.
We do this for a few services, but not all. We happen to be getting
rid of some of the services we've done this for.

> Now somebody is developing a product there whould be nice to have
> a product installer service. 
> 
> The product installer service should do:
> 1. register services to the installer with .zcml
> 2. bootstrap the registred services
> 3. register content objects to the service (if needed)
>    or do somthing with the content objects and service.
> 4. Deinstall the product in TTW (this should deinstall 
>    the services and make shure next time we start zope
>    we don't have broken services in zodb.)
> 
> 5. Perhaps we can also install the product via TTW
> 
> I'm realy not sure if there is such a mechanism 
> allready in Zope3. Perhaps I missed somthing?
 >
 > Is anybody starting somthing like this?
 >
 > Or should I first develope a product like this
 > in Zope3 Products. That we can see it's usable?

I don't think this is necessary.  Almost all of what you describe
can be done with ZCML.

Leaving aside the fact that you need to edit products.zcml to
install a product (I'll come back to this below), your product
zcml file:

- Registeres new service types, which I discourage, and, if necessary
   provides a global service installation.

- Provides a IDatabaseOpenedEvent subscriber that does any required
   bootstrapping. Again, I think we should think long and hard about
   whether such bootstrapping is really needed.

The unstall use case in the presense of bootstrapping is an interesting
one that deserves more consideration.  I suppose that if a file-system-based
product provides bootstrapping of some sort, it should provide a facility to undo
that.  I'd rather not get into this now, though, because:

- There is a lot of other work to do, and

- I don't think that most products should do this sort of thing.

On the topic of editing products.zcml, Fred Drake is working on a prototype
for package management for Zope.  The initial goal of the effort is to support
better in-place builds of the CVS tree and Zope source and binary distributions
that are not bound by the CVS tree.  The eventual goal is to have a flexible
package-management system for file-system-based code that is part of a larger
Python packaging system.

As a part of this effort, we have decided to expant the zcml include directive
to allow file-globs in include-directive package and file attributes.  This will
allow us to have product directories that simple package installers can place files
into and remove files from, eliminating the need to edit products.zcml.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Sun Feb 29 12:17:13 2004
From: jim at zope.com (Jim Fulton)
Date: Sun Feb 29 12:17:36 2004
Subject: [Zope3-dev] "Sub interface"
In-Reply-To: <m1AxJI9-007pBSC@mail.augustmail.com>
References: <m1AxJI9-007pBSC@mail.augustmail.com>
Message-ID: <40421E99.6080900@zope.com>

Terry Hancock wrote:
> I have researched the Wikis and ML archives regarding 
> interface implementations in Zope, and have not found
> anywhere the concept of a "sub-interface" which I 
> implemented because I found it indispensable in my
> product design.

But such a concept exists, even if it didn't make it to
the docs.

> A sub-interface inherits from Interface.Attribute, but
> has an extra property specifying the expected interface
> of the attribute.

You should look at zope.schema. See especially the README.txt
file there.

...

> I can provide detailed use-cases if they aren't obvious to 
> you, but here's just a suggestion:

No need. :)

...

> Anyway, the reason this came up is because I wrote it as an 
> extension to the "Interface" module provided in Zope 2.5.1. 
> That has changed extensively, and my code is now completely 
> broken in Zope 2.7 (it's beyond a few name fixes -- I need 
> to just rewrite the thing.  Fortunately it's less than 100 
> loc or so).

...

> So I want to answer the strategic question of how to 
> proceed with fixing this problem.  Should I:

... (options snipped)

None of the above. :)

First, you should Zope 3 interfaces.  As Martijn pointed out,
this is a bit harder than we'd like it to be in Zope 2.7 and
earlier. You need to:

- Arrange to have the zope.interface package in your Python
   path.

- Get the Interfaces "facade" package from Packages3/Interface
   in the repository. You need to arrange to have this ahead
   of the normal Zope 2 interface package in the Python path.

   The facade is needed to support Zope 2 software that expects the
   old Interface API.

Make your enhancements on top of the zope.interface package.

Second, you want to use zope.schems and the Object field, which
addresses your use cases, or should address them:


import zope.interface
import zope.schema


class IFoo(zope.interface.Interface)

   myattr = zope.schema.Object(schema=IBar)


> A cursory look at the Zope 2.7 Interface and Zope X3 
> interface modules suggests that they are pretty similar, 
> but not identical. 

Right.

 > How much change has gone on?

A fair bit.

 > Especially
> at the conceptual level where it will mean more than just 
> subbing a few names?

Yes.  See for example:

http://dev.zope.org/Zope3/BetterInterfaceImplements

although even this has evolved. See zope.interface.interfaces.

> Anyway, I'm looking for comments or advice on how to pursue 
> this.

An improvement I haven't had time to pursue is to generalize the
verification framework a bit, along the lines of the attribute
verification you've mentioned. Wanna help? :)

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From jim at zope.com  Sun Feb 29 12:19:23 2004
From: jim at zope.com (Jim Fulton)
Date: Sun Feb 29 12:20:03 2004
Subject: [Zope3-dev] "Sub interface"
In-Reply-To: <40421E99.6080900@zope.com>
References: <m1AxJI9-007pBSC@mail.augustmail.com> <40421E99.6080900@zope.com>
Message-ID: <40421F1B.7080909@zope.com>

Jim Fulton wrote:
> Terry Hancock wrote:
> 

...

> First, you should Zope 3 interfaces.  As Martijn pointed out,
> this is a bit harder than we'd like it to be in Zope 2.7 and
> earlier. You need to:
> 
> - Arrange to have the zope.interface package in your Python
>   path.
> 
> - Get the Interfaces "facade" package from Packages3/Interface
>   in the repository. You need to arrange to have this ahead
>   of the normal Zope 2 interface package in the Python path.
> 
>   The facade is needed to support Zope 2 software that expects the
>   old Interface API.

I forgot to mention that Zope 2.8 will make this easier by
including Zope 3 interfaces and replacing the Zope 2 Interfaces
package to use the facade.  We will also update the software than
is includes with Zope 2 to use zope.interface.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


From hancock at anansispaceworks.com  Sun Feb 29 20:11:48 2004
From: hancock at anansispaceworks.com (Terry Hancock)
Date: Sun Feb 29 19:59:44 2004
Subject: [Zope3-dev] "Sub interface"
In-Reply-To: <40421F1B.7080909@zope.com>
References: <m1AxJI9-007pBSC@mail.augustmail.com> <40421E99.6080900@zope.com>
	<40421F1B.7080909@zope.com>
Message-ID: <m1AxbmS-007p1rC@mail.augustmail.com>

On Sunday 29 February 2004 11:19 am, Jim Fulton wrote:
> I forgot to mention that Zope 2.8 will make this easier by
> including Zope 3 interfaces and replacing the Zope 2 interfaces
> package to use the facade.  We will also update the software than
> is includes with Zope 2 to use zope.interface.

That sounds like the right thing to do then.  I suspect (though I have
not had time to prove it to myself), that Zope 3 will allow me to
cut my product down considerably, so I'm probably going to
be migrating to Zope 3.

But it's not time yet.  Thanks for the installation instructions to use
Zope 3 interfaces in Zope 2, as that's clearly what I need to do.

I gotta say though, I recoil at the distinction between "schemas"
and "interfaces".  IMHO, they're still "interfaces" -- the idea that
attributes shouldn't be part of an interface seems unnatural
to me, like some idea grafted from another language.   I approve
of the fact that they're integrated in Zope 3, though.  I guess I
can lie with it as a synonym.

But I personally reserve the word "schema" for relational databases
and XML schemas -- that's a word getting too overloaded. ;-)

One question about the schema module -- when we specify that
a field is, say, a "Tuple" are we requiring that it literally "is-a" tuple,
or that it merely "acts-like-a" tuple? (I.e. are we testing "type" or
"interface"?).  I really prefer the latter. 

Does that mean I should *always* use the "Object" field and
specify the interface as "schema", or is that merely duplicating
the schema module's code?

Thanks,
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com

From hancock at anansispaceworks.com  Sun Feb 29 22:05:40 2004
From: hancock at anansispaceworks.com (Terry Hancock)
Date: Sun Feb 29 21:53:32 2004
Subject: [Zope3-dev] "Sub interface"
In-Reply-To: <m1AxbmS-007p1rC@mail.augustmail.com>
References: <m1AxJI9-007pBSC@mail.augustmail.com> <40421F1B.7080909@zope.com>
	<m1AxbmS-007p1rC@mail.augustmail.com>
Message-ID: <m1AxdYf-007pzsC@mail.augustmail.com>

On Sunday 29 February 2004 07:11 pm, Terry Hancock wrote:
> I guess I can lie with it as a synonym.

s/lie/live/

Not some kind of cryptic slur. ;-)

Just in case anyone was thinking about getting offended.
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com