[Zope] Subclassing Folder

[Dan Shafer]

At 12:13 AM 6/3/2002 -0400, Chris McDonough wrote:
>On Sun, 2002-06-02 at 20:38, Dan Shafer wrote:
> > That chapter has so many typos and apparently out-dated information in it
> > -- much of which has been noted in the file but not yet fixed, apparently
> > -- that a newbie like me stands zero chance of understanding how to create
> > a meaningful Zope product in Python.
>
>Pointers to this outdated info and these typos in the form of comments
>to that chapter would be appreciated.

I have made several such comments in the document itself and will continue 
to do so.

>BTW, I presume you mean developer-contributed comments when you say
>"noted in the file"?

Yes

>  don't understand how this is a bad thing.

The notes aren't a bad thing. It just seemed like quite a few of them raise 
issues that aren't resolved in any edits to the text but which don't 
contain answers in themselves, so if you don't know what the answer 
is,  you're sort of stuck. For examples:

On page 5, "XXX is this true? I thought that any ExtensionClass.Base can be 
acquired. The Implicit and Explicit just control how the class can acquire, 
not how it *is* acquired." I have no idea what that means, but it makes me 
wonder if the code examples that use Acquisition.Implicit, e.g., are going 
to work. And if they don't, how would I know?

On page 11, there is a set of comments about stuff related to Registrar, 
but as far as I can tell, no resolution.

On page 12, following the addForm() function listing there is some 
discussion about changes the code may need, but nothing definitive from the 
author(s) of the text to indicate if those corrections are right, or 
whether the 2.4 stuff also applies to 2.5, etc.

IOW, what I'm saying in brief is that for someone like me, who is a decent 
but not world-class Python coder who is very comfortable creating Web 
*sites* with dynamic pages in Zope/DTML and who is a fairly experienced 
object thinker and designer, the docs are just confusing enough at key 
points to make it very difficult to know what to do. Since many of these 
comments go back to last fall, I just sort of hoped that someone in 
authority would by now have gone through them and responded, fixed things, 
etc. As it is, the document is perhaps just a bit too "raw" for someone of 
my experience level.

>  Yes,
>there are inconsistencies in the documentation, but isn't it better to
>be able to read them inline than to have each reader rediscover them
>fresh, given that we (ZC) really haven't been provided with the
>resources to update the canonical docs in some time?

Yes. And I really do understand that updating this doc is probably not a 
high priority at ZC. But where we have user-supported Open Source software, 
the absence of any clear source of knowledge and support for this process 
is a major obstacle to success for people like myself. (Again, let me say 
it clearly: I love Zope and Python. I do not *want* to give them up or 
learn other tools and platforms if I can avoid it. And I have worked harder 
at mastering Zope than any other platform I've approached in the past 7 or 
8 years. But for whatever reason, things just don't "click" for me.)

> > Zope appears to be very strong for building object-oriented dynamic Web
> > *sites* but not for creating Web services or applications.
> >
> > Am I wrong here? SOmeone please unlock this door for me if it can be
> > unlocked. Alternatively, confirm my worst fears and I'll just find other
> > ways to build these things I need to create.
>
>What are you trying to build and specifically what isn't working for
>you?

Well, there are quite a number of projects and I don't want to clutter the 
list with specs. One of the projects I ended up figuring out how to do 
without creating a product, by making extensive use of Python scripts and 
built-in Zope objects (folders and DTML documents/methods). I don't like 
the factoring I ended up with and I may re-do it at some point, but for now 
it seems to be working. On that one, however, I set out and spent a *lot* 
of time trying to make it first as a product using ZClasses because I think 
in terms of objects. Several people in the Zope community warned me *not* 
to use ZClasses for anything more than very simple-minded stuff.

This particular conversation arose from a request I made asking how I could 
create a new type of folder object. I have a repetitive process in which I 
create a new folder (or copy an existing one in another case), give it some 
content that varies only slightly from folder to folder, create a document 
inside that folder, give it some content that varies only slightly from 
document to document. It struck me that if I could somehow subclass a Zope 
folder so I could just add a new folder with the new material in place and 
apply some Python scripting, I could save myself a bunch of time. So I set 
out only to learn how to make a new *type* of folder. I figured a ZClass 
would work. I was advised to create a "simple Python product" instead. In 
trying to do so, I was working my way through the ZDG Chapter 3 stuff and 
finding the issues I raised above. I was also finding that there seems to 
be no such thing as a "simple" Python product. To its credit, the first 
page of Chapter 3 of the ZDG warns about this. "In comparison with through 
the Web products [by which I assume is meant Zope products using ZClasses], 
filesystem products (presumably relying on Python) require more overhead to 
build." That turns out to be a major understatement in my efforts so far to 
create a Python Product.

>- C