--- Andrew Milton <[EMAIL PROTECTED]> wrote:

> I'm having a hard time working out what your problem
> is.
> "If anything, the Zope developers have given us too
> much. In an attempt to protect us from ourselves,
> they have severly limited what we can do."

That's my fault.  I can see a problem and I get so
focused on how to fix it, that I don't spend adequate
time making sure everyone's on the same page that I

> That's not something I've ever heard of being an
> issue before. The fact is you can subclass just
> about anything in Zope, and publish just about any
> other type of object.
> Perhaps if we knew what you were limited by, the
> discussion would go a lot smoother.

Okiedoke.  Let's take some typical problems that I've
encountered in the last couple of years with Zope, and
I'll walk you through my thought processes.  Perhaps
that will help you see the frustration that I think a
typical programmer feels with Zope.

[1] Suppose I've got a gallery of images and I want to
organize these so that the user can see the most
recent additions to the gallery.  I can access an
image pretty easily, for example:

grumpy = getattr(container, "grumpy.jpg")

The edit view of grumpy.jpg shows me the Last Modified
time, so I know this information must be stored
somewhere.  I check the docs for methods I can call on
class Image and its ancestors, File,
ObjectManagerItem, and PropertyManager, but I still
don't see anything about the Last Modified time.

Now I try to investigate it by poking around in
Python.  I write some code to look at any properties
that might have been saved for me, but not documented:

return grumpy.propertyIds()

['title', 'content_type', 'height', 'width']

No good.  Perhaps there is a member that I need to
call, but someone overlooked it in the documentation:

return dir(grumpy)

Error Type: NameError
Error Value: global name 'dir' is not defined

Hrmmm.  No good.  For some reason, my basic diagnostic
tool has been disabled to protect me from something. 
I don't suppose I could find this information myself?

return repr(grumpy.__class__.__dict__)

Line 2: "__dict__" is an invalid attribute name
because it starts with "_".

Okie... perhaps if I prod more subtly?

return repr(getattr(getattr(grumpy, "__class__"),

Error Type: Unauthorized
Error Value: You are not allowed to access '__class__'
in this context

[2] A user wants to buy a print of an image in the
gallery.  He's a new user, so I get account
information and add it to my user list.  Now I want to
log him in from a visually appealing web form.  I know
this is possible, because I've seen other applications
do this.

However, I can't find any mention of this in the docs.

[3] I'm writing a program to give web access to a
program that is normally controlled with a
command-line interface.  To let the web user do all
the things you could do from a CLI, I will want to
call various programs, look at the contents of various
files, etc.

It's my server, and I know there will be no malicious
code added, but yet, Zope stops me at every turn in an
effort to protect me from myself.  There are
mechanisms where I can create portals to code in
actual files that can access these things, but by the
time I'm done, I've written so many of them, that Zope
hasn't really made my life any easier at all.

[4] I have some full-resolution images that I want to
allow people to download if they have paid the license
fees.  Very few companies actually do this, so I'm
content to add users manually and upload the images
that they want manually.

I create directories for the users and try to give
only them permissions to view the files in there.  To
be frank, this is a "chocolate mess".  How do I give
them the folders?  How do I give them the files?  The
docs are no help so I temporarily make the user an
admin (the haven't been told the password yet, so I
feel safe) and I take ownership for them, then I
change them back to regular users.

This still doesn't work.  Zope is convinced that they
own the files, but for some reason it still wants them
to authenticate.

I walk away frustrated and angry.

[5] I have a neat idea for a Zope product so I start
coding it up.  I find some bits and pieces on the web
and try installing them, only to find that parts of my
product have a name collision with parts of their

I could go on, but hopefully I am making my point
clear enough now.  I'm not looking for the answers to
these problem.  I am trying to express how a typical
user feels when working with Zope.  They walk away
with two general notions:

[1] The documentation is not complete.

[2] Zope is actively trying to stop me from
succeeding, or finding an alternative solution.

> Some of your discussions shows a distinct lack of
> knowledge of how Zope works, so your problem seems
> to be, you don't understand Zope,

Agreed.  I know that Zope can do these things, but the
documentation doesn't want to give up Zope's secrets.
In most cases, such a problem would be only an
inconvenience.  One of the reasons I love Python so is
that it lets me solve my problems in different ways.

Sadly, Zope is dead set against this.

> so you want to replace it with something that does
> the same thing, just in a way you understand it.

Basically, yes.  I want a tool that doesn't try to
protect me.  I want the full power of Python when I
make my web pages.  I do not want someone trying to
protect me, or that makes me jump through hoops to get
there.  I want Zope's few great features without all
of its restrictions.

Is that more clear?

> Yet other parts of your discussion show a
> frightening lack of knowledge of web development
> environments in general.

Please don't be mean.  I've been a programmer since
1979.  I've done a lot of things in this last 27
years.  If I can't make a tool dance and sing within
two years of picking it up, then the chances are that
the tool itself isn't measuring up.  If there is
something specific you want to address, please do.

> The fact of the matter is, PHP and friends have
> greater market penetration, because "people" want to
> do things the 'easy' way.

Exactly.  The whole point of a tool is to make it easy
to get from point A to point B.  PHP presumes that the
code is to be trusted and doesn't stand in the way. 
Zope presumes that the code is suspect and is
desperate to keep me from getting to point B.  The end
result is that I end up not using what Zope can do
because I do not want to deal with the roadblocks it
puts up.

> That is mixing presentation and logic all in some
> horrid markup. Engineers appreciate the way it
> separates these things, and makes it hard(er) to
> have ugly templates. PHP "programmers" are a dime a
> dozen for a reason, "anyone" can do it.

No offence, but that sounds like a statement from an
ivory tower.  I want a good separation of code and
template.  However, I don't see why I should have to
suffer to get this.

> Zope is a different beast, if you don't have good
> engineering habits, you're not going to get very far
> using Zope.

I think you have far too much faith in Zope as it
currently stands.  Incomplete documentation is the
norm for OSS, but in most cases, this isn't such a big
deal.  Most products don't try to protect you, so you
can easily find out the name of a function that
someone forgot to document.

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to