Never mind that bug reports (and, to be fair, patch reports) for some of the other CMSes (Zope and PHP Nuke) show up on BUGTRAQ fairly frequently, whereas I don't remember seeing anything about the Perl-based CMSes mentioned above.

"No root for you!"

Update:Zope is Python, not PHP. Corrected. Still shows up an awful lot on BUGTRAQ, though. Thanks eduardo!

As a quick correction... Zope is *not* a PHP based CMS system... Zope is Python based.

A drop-down menu lets you instantiate the product, that is install it anywhere you want in your web hierarchy. You then configure each instance through the web. 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.

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.

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.

One problem if you're living in e.g. Scandinavia is that there are very few Zope developers around. Here in Sweden I think there are three (myself included, though I'm more of a hobbyist). This makes it hard to recommend customers to use it, since one emigration, one change of career and a traffic accident would reduce the number of developers to zero. So, for my customers I'm still using perl.

/jeorgen

Zope is great and I'm heartily recommending it.

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.

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.
--
:wq

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.

Have you tried fetchrow_hashref

% 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