Note that I didn't say "Zope is a big bag of suck." I said it's not a content management system, and it's not. It's a framework for building applications. So is OpenInteract. In fact, the only thing mentioned above that meets my definition of a content management system is Bricolage.

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.

Zope uses plug-in applications called "products".

So does OpenInteract.

User management and session mangement is built in, the database methods return rows with each column value tagged by it's column name, something I'm still to find in the DBI module.

That would be $sth->fetchrow_hash(). There are also dozens of object-relational mapping tools for Perl/DBI. There's one called SPOPS that is bundled with OpenInteract, and then there's Tangram, Class::DBI, etc.

All your objects (instances of products, data, users) are stored in a hierarchical database where they can address each other in a funny kind-of-inheritance-based way called acquisition. At first it is bewildering, but it makes it so easy for objects to call each other. In perl I usually store objects in slots (Atributes) of each other. This becomes messy.

Hierarchical storage is still storing object references in prpoerties (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.

Sure, there are some design decisions done in Zope that you have to follow and that you may or may not like, but development is about 3x faster for me in Zope than in Perl, and I've done a lot more perl than zope.

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.

Note that I didn't say "Zope is a big bag of suck."

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).

My problems with Zope are unrelated to its design:

1. It's written in python, which makes it more difficult for me to extend to suit my needs (as I'm rather less than familiar with python).
2. Historically, security-wise, it has more holes than a shotgunned Swiss cheese. Unless they've re-written it from the ground up, I'm not going to trust it on my network with my data.

the database methods return rows with each column value tagged by it's column name, something I'm still to find in the DBI module.

% pelrdoc DBI
[snip]
 `fetchrow_hashref'
            $hash_ref = $sth->fetchrow_hashref;
            $hash_ref = $sth->fetchrow_hashref($name);

           An alternative to `fetchrow_arrayref'. Fetches the
           next row of data and returns it as a reference to a
           hash containing field name and field value pairs.
           Null fields are returned as `undef' values in the
           hash.

           If there are no more rows or if an error occurs, then
           `fetchrow_hashref' returns an `undef'. You should
           check `$sth-'>`err' afterwards (or use the
           `RaiseError' attribute) to discover if the `undef'
           returned was due to an error.

           The optional `$name' parameter specifies the name of
           the statement handle attribute. For historical reasons
           it defaults to "`NAME'", however using either
           "`NAME_lc'" or "`NAME_uc'" is recomended for
           portability.

           The keys of the hash are the same names returned by
           `$sth-'>`{$name}'. If more than one field has the same
           name, there will only be one entry in the returned
           hash for those fields.

           Because of the extra work `fetchrow_hashref' and Perl
           have to perform, it is not as efficient as
           `fetchrow_arrayref' or `fetchrow_array'.

           Currently, a new hash reference is returned for each
           row.  This will change in the future to return the
           same hash ref each time, so don't rely on the current
           behaviour.
[download]

-Blake