[Zope] Subclassing Folder
Mon, 03 Jun 2002 11:16:15 -0700
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"?
> 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.
>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
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.