ACS CMS 4.x has some strengths which make it very appealing. At the
same time it has some serious flaws which bring it close to
unusability - I have to admit it took me a few weeks until I truly
understood how it works and from what I saw on this forum and on
arsdigita cms forum I am not alone. Since it may be that openacs 4.x
will have a new CMS, I would like to present my thoughts on the acs
cms.
What is your opinion on ACS CMS 4.x?
Features
The CMS has a reach set of features. Besides basic editing/publishing
tasks, it has a few other nice things. Probably the workflow feature
is the most powerful (and a little bit underused ?).
What I feel is lacking a little is the ability to categorize content.
Keywords are good, but not enough.
Data Model
The CMS may be regarded as an data processing + ui over the acs-
content-reporistory data model. I think one of the biggest strengths
of the CMS is exactly this data model.
It is simple, yet powerful, offerring a good basis for future
developement. There are very few things I can think of, which cannot
be supported.
One minor thing I find lacking at this level is a proper support for
multiple languages.
Data Processing
The data processing is as good as it can get. It consists of a series
of scripts & procs which update the database. Sometimes some
abstractions may be missed, sometimes the abstractions get lengthy,
but using this paradigm one cannot do much better.
User Interface
Here the cms team failed big time. It is nice to hear 'the cms is
very good, you just have to customize it to make it work'. In real
terms, this means you are likely to recreate almost all of the cms
scripts and reuse some procs if lucky.
The most blatant error: the lack of separation between metadata and
operational interfaces. It is very confusing when the ui puts item
editing and content types editing at the same level - items are
operational, types are metadata and it may take sometime until one
figures that it will never see a content type on the site, rather
altering a content type will have subtle reflections on the process
of item editing.
Having tasks instead of goals is again a little bit troublesome. I am
still wondering sometimes 'what should I do next ?!' or 'where do I
find this function ?!' even if I have come to know a lot about CMS
and its internals.
I find the clipboard and rather unfortunate metaphor - it is
debatable if it's widespread desktop usage is based on its intrinsic
value or is just a habit (I feel draganddrop much clear). In a web
environement we don't have drag and drop, but we may do a lot of
things with 'select object select action' paradigm if information
flow is well organized.
And yes, frames are bad.
Documentation
Unfortunately, the documentation of the CMS is plain bad. It is very
hard to figure out how things really work and often one have to read
tons of code to understand how simple functions may be accomplished.
If you don't believe me, try to figure out how to add custom mime
types handlers...
I also find that the examples (cms-news-demo) are a little bit too
simplistic and definitely insufficient.
The data model (acs_content_repository) documentation is much better.
I would probably like to see a more clear separation between metadata
and operational levels.
Implementation
Well, we are in front of a typical case of schizophrenia. Even if cms
(and acs-templating) are built as parts of acs, the team designed
them as independently as possible, building their own interfaces
which often duplicate main acs functionalities. For instance, I feel
very strange mixing two db interfaces, the db_??? of core acs and
template::query (pervasive in cms) of acs_templating. I could handle
that, but my experience tells it can lead to subtle db bugs, like
beginning a transaction with a db_transaction, call some cms proc and
find out that the latter one uses a totally different db handle.
Another complain is improper design of functions - I have seen some
procs which are required to perform three different things and find
out which one to do by a mix of command arguments (again that mime
type handlers).
Also some functions sometimes get lenghty. To write a small variation
may lead the programmer in a big mess of code duplication. I could
suggest some study of proper oo style with extremely thin methods.
Another bad design practice is to mix at some points the ui procs and
the data processing procs. I feel very stupid when I have to populate
a dummy form (ui element) in order to call 'item add_revision' (data
processing proc) which takes its parameters from a form, not from
normal arguments.
ACS Integration
The good news are at the data-model level. Everything is subtype of
acs_object, acs_type & friends.
As I already said, at implementation level the integration is bad.
Another bad thing is the CMS is a singleton, making hard to delegate
a part of the site to an independent publisher. If we remember where
all started - web collaboration - we may feel that the 'co' part is
somehow getting lost in the shadows.
Conclusion
- Features are good
- The datamodel is good
- The ui is very bad.
- The documentation is bad.
- The acs integration is medium.
