--- Andrew Milton <akm@theinternet.com.au> 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 am.
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__"), "__dict__")) 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 product. 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. http://new.mail.yahoo.com