|
in reply to Content management system recommendations?
I recommend taking a look at Zope.
Not as a solution, but merely as an example of how to
offer content management. Zope uses Python, and even
though it can be configured to use Perl (somewhat), it was
really meant to be used with Python.
Personally, i would rather use Everything or slash.
But, taking a look at Zope will not hurt, just to see
another way of doing it.
jeffa
L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
F--F--F--F--F--F--F--F--
(the triplet paradiddle)
|
Re: (jeffa) Re: Content management system recommendations?
by perrin (Chancellor) on Jan 16, 2002 at 00:43 UTC
|
People always say to look at Zope, but it is a pretty sad excuse for a CMS. The basic install just gives a way to edit HTML pages through a browser. They have started to make some progress on this, but the features I expect out of a CMS (flexible data model with object relationships, data independent of presentation, scheduling of content, etc.) are not there. | [reply] |
|
|
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!
--
:wq
| [reply] |
|
|
As a quick correction... Zope is *not* a PHP based CMS system... Zope is Python based.
| [reply] |
|
|
Zope is great and I'm heartily recommending it. I has some idioms in it's design that you may or may not like, like a reliance on multiple inheritance (that they call "mix-in classes"). But the truth is that they have put a lot of thought into the design of Zope, and it just plain works. Zope uses plug-in applications called "products". A product is some python classes that make up an area of functionality, either a full fledged application (like a web log or publishing system) or a building component for a larger application (LDAP authentication, rating system, Internet Explorer WYSIWYG editing of HTML in forms). 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
| [reply] |
|
|
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.
| [reply]
[d/l] |
|
|
|
|
|
|
|
|
| [reply] |
|
|
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.
-Blake
| [reply]
[d/l]
[select] |
|
|
