Didn't accuse you of saying it ;-)

You can't create a custom data model in Zope (say, a categorized catalog of your favorite books with relationships to their authors) without programming in Python. A real CMS does not require programming just to do basic data publishing.

You can actually, with through-the-web ZClasses. But you don't want to. It gets kind of messy.

Hierarchical storage is still storing object references in properties (attributes) of other objects.

The problem with Zope's hierarchical data structure is that it has a hard time modelling anything that isn't hierarchical. Think of my previous example of a catalog of books. You would need book objects and author objects with a many-to-many relationship. There is no obvious way to do that in Zope, at least not without custom Python programming.

For such simple things you don't need python programming. Just use the template language DTML and the web-editable SQL methods. That is how I did euliberals.net (which is just a hobby project). As a side note, I like to put things into an RDB but I do have some oo-fanatic colleagues who prefer to use messaging back and forth with catalogs to keep track of certain attributes and combine things, etcetera. My development cycles however go way shorter when pushing as much as possible of the processing and data into SQL. Think of the ZODB (Zope object databse) as one more dimension to think in. One of the boons of object orientation in general is that you can think spatially, which is easier for many people than to think in "flat" subs and libraries.

It doesn't make sense to compare Zope to Perl. You should compare Python to Perl and Zope to things like OpenInteract, Apache::PageKit, and Apache::ASP. I'm guessing that this perl you were writing was not using a framework like those.

No, I wasn't. My customers want to stay on web hotels, so no mod_perl. I'm rolling my own with HTML::Template, Lincoln Steins user_manage and DBI/mysql, and it's actually working now. I have looked at different perl solutions, but haven't found one that is easy enough for what I want to do. Of course, one can always argue that I haven't looked deep enough, or at the right one etcetera, and that criticism would probaly be true. But I don't want to spend time doing a lot of tweaking and configuration just to get things going, or just to evaluate things. I don't want to have a lot of dependencies that fork out into unknown waters. Zope can be installed easily under Linux and dead-easy under Windows. You just drop things in and they work. There are web hotels that give you a complete Zope/Apache/Mysql (php, perl) combo with "root" (FreeBSD jail) for $50/month. I use it. You move your Zope stuff from your Windows development machine to the live web site in minutes. And between different web sites. It just works. I've done it. Repeatedly. Virtual hosting is doene by pointing the domain to the IP and then tell the virtual host monster object (yeah, that's the name they've given it) through-the-web in what folder object the site should start. I set up a new domain with a collaboration area with file upload and download, a wiki, user management, and then billed the customer one hour's work. They were happy.

One of my colleagues, a Java expert, complained about the field of knowledge one has to cover today to be an expert. My reflection is that one has to limit oneself to a certain way of doing things (e.g. the Zope way, The Macintosh way, The EJB way). This is difficult in a small company, with no support staff. That's just my view and may not map with yours, or other people with a deep knowledge in the field. It all depends on what knowledge you start with. Zope works out of the box, and gets things done fast.

Perl is great, and I use it all the time. If there is, or will come, a great perl-based solution I'll happily use it. I'm not learning a new language (python) for fun. I'd rather stick with perl. And perl is still great for thinking out of the box, tying different systems together.

/jeorgen

One of my colleagues, a Java expert, complained about the field of knowledge one has to cover today to be an expert. My reflection is that one has to limit oneself to a certain way of doing things (e.g. the Zope way, The Macintosh way, The EJB way).

Actually, I don't think this is necessarily true. If you're just starting out (and I'm not saying you are, just stating a point) then it seems that way. But many languages in wide use today are similar enough to one another that the same patterns make sense no matter which one you pick. Of course there are differences, but if you think about problems (and frameworks) in a design fashion then there are many deep similarities that you can carry from language to language, project to project.

For instance, my day job is almost entirely Java. While we're using a particular application method with servlets I'm curious about other ones and was reading some of the higher-level documentation for Struts on my way home from work this evening. (I also am in idea-acquisition mode for the next version of OpenInteract, but don't let that leak :-) Some pieces of the framework are almost exactly the same -- they have different names, interfaces, but the meaning and motivation are alike. Many apps like this are guided by MVC ideas and principles that transcend languages.

Chris
M-x auto-bs-mode

You can actually, with through-the-web ZClasses. But you don't want to. It gets kind of messy.

That was what I tried. Unfortunately, it had the problem I mentioned with not being able to capture object references except for container relationships. That was a deal-breaker for me.

I don't think the Perl frameworks I mentioned are any harder to learn than Zope for someone who knows Perl, but the lack of mod_perl would be a problem. One thing you might look into is using SpeedyCGI. I think it will give you the performance you need for these tools without the need for recompiling Apache. You would need to get the framework you chose to work under it, but anything that currently supports CGI would be fine (Mason, Apache::ASP). Some authors would probably be willing to port to SpeedyCGI if it would improve their chances of working on low-cost ISPs ("web hotels" as you referred to them).