Forum OpenACS CMS: Learning from what others do well

• Stellent
• Hyperwave
• Midgard / Aegir
• Zope / Plone

But I don't think it'd benefit us to use PHP since TCL is so embedded in AOLserver. It just seems wiser to use TCL like we do already plus our CR has a lot of functionality that just is not put to good use in a user friendly, functional, content-management-generic UI yet.

Midgard sounds great according some articles on it ( Getting to Know Midgard and Data-Drive Sites with Midgard ) but it also sounds like it relies heavily on being associated with apache, mysql + php. I don't think mysql will scale like postgres and definitely not like Oracle. And we of course are not using apache here.

Zope sounds great and powerful and built in Python which is object-oriented. As far as I can tell, Zope is possible to use without a webserver as it runs in it's own application server. So I guess it is a possibility to use it. But this would greatly complicate the system administration side of things (running OACS and Zope!) and basically duplicate all efforts at security/permissions/users/groups/etc. Basically at that point, I'd think you'd be talking about replacing OACS with Zope which I'm sure would be just as complicated as running an OACS site with just a different set of CMS UIs to deal with! Though on the pro-Zope side, it seems there are some good Zope books and reference articles out there.

So enough rambling, basically I think looking at the CMS UI's built on Zope (Plone) and Midgard (Aegir) might benefit us in getting our heads around building a good basic, general use CMS UI package on top of our CR. Maybe make CMS into a general TCL library (exposing CR API) for CMS functions and then build a basic CMS UI using the new CMS library... not a small task I know...

They have tutorials with Zope, Midgard, and Apache Lenya. I am attending the Zope tutorial, mainly because I have actually looked at python code before :)

I except seeing the other systems and just being with other open source CMS hackers will be very educational.

So yes, we definitely need to look at what other CMS packages do, and use them for inspiration.

Using their online demo seems like a reasonable way to get a handle on their look-and-feel.  Any volunteers?  Danielle?

I've also downloaded OpenCMS to try to get a handle on what their templates etc look like.  One thing I've already noticed is that they use .xml files to do similar things to what I did  with 4.6.2 when I added the "install.xml" facility, which allows for the autoinstallation of vertical application bundles (.LRN in particular, which sets itself up automatically during install.)

We will try to look at it more when resource permits, Talli showed Bricolage to me about a few months ago.  We certainly can get ideas on UI and/or features from this other OSS cms.

I am working on a client project where they specified Midgard/Aegir as a requirement. It was for a friend in desperation, so I dusted off my PHP brain and got stuck into it.

While there are some things that frustrate me after the clear  environment of ACS, I am learning a lot about what functionality in the API and structure is usefull for a content dominated site. Midgard has an amazingly flexible base, as can be seen by what get's bolted on top liek MidCOM.

Something very cool coming out of OSCOM is a mozilla-embedded hierarchical user interface to the content editing (I believe based on some stuff from a Zope project) - check out this url:  http://www.oscom.org/Projects/Twingle

especially view the pdf presentation:
http://www.oscom.org/attachment/72c7a5e5939d06b8545b6a41cc703144/e0b427078c9a68d4c03c8a8aab698429/Twingle_for_Developers.pdf

To get a feel for a cms structure, people with spare time on their hands will find reading the midgard manual valuable, it has a lot of schema diagrams etc. as well as function listings etc:

http://midgard-project.org/manual/en/

Midgard is object-ish, although it separates things like topics and articles, and there is a tacked-on unique ID concept that is a bit kludgy.

When I am done with this project, I am going to try to get a similar project with a slacker timeframe that will allow me to build midgard-like functionality into an OACS package. No promises, but if I can swing such a project... happy days.

Besides it gives you revisioning built in, although storing the entirity of every revision is pretty wasteful - midgard nicely stores rcs diffs of every revision (of course midgard stores binary data separately, but there is no reason why modern rcs's can't be used to store diffed blobs, especially with our base64 or whatever blob workaround, just side by side comparisons would be kind of useless...)

Hmm - as much as it seems like the right thing to do, count me out of re-implementing CR using rcs...

Russell Muetezelfeldt is working on some DAV stuff for OACS/nsd4 although with a very specific purpose to mount a read-only representation of a photo-store as an iDisk on a mac desktop. I will make sure I siphon interesting info out of him as it arises.

I just read your oscom blog - did you find out if there was any kind of comparison of the different implementations from the Zope, Miggard, and Apache Lenya workshops? I know the midgard/midcom version saw most users completed inside 3 hours - it would be interesting to compare time taken and user feedback.

Dave,

Yes CCM versioning is a bit different for OACS.  In CCM each field is versioned.  Although not strictly, like in the custom content types we have.  A group of fields are versioned together.  But its a little more complex than OACS versioning.  Also seems to require a good logic to make a snapshot of a particular version.

Here is an overview on how CCM versioning works as well as older ACS.

https://listman.redhat.com/archives/redhat-ccm-list/2003-February/msg00109.html

I've seen ns_dav, but have decided to start implementing something else for a few reasons. As far as I can tell, using non-filesystem providers for ns_dav in OACS requires writing a C provider that then calls back to TCL. I'm hoping that the CMS stuff musea are doing has as little as possible in ns_dav.so with the ability to plug in generic TCL providers but I haven't heard anything either way on that so I'm not assuming anything. My requirement is very simple - I need a read-only view of some data (stored outside the CR) that can be accessed by both PC and Mac clients as if it were on a fileserver.

Given I don't need any locking/revision control/proppatch or a whole host of other RFC 2518 stuff, I suspect I'll have something working to my limited needs before a full aolserver integration of mod_dav is complete...

Is there any documentation on writing additional providers for mod_dav floating around? AFAICT even the apache 2 mod_dav docs don't seem to cover that stuff...

With regards to the live revision join, yes I agree it's easy, and I don't particularly see a need for a cr_live_revision table, but if the points in the article are valid about the size of the unified cr_revisions table being a problem for sites with a LOT of content, a trigger maintained cr_live_revision table would be a simple way to address that which wouldn't even break any existing code (since the live revision would still be in the cr_revisions table).

But anyhow, this has become a little off-topic. When I finish the project I am working on I will try to put up a bullet point of the CMS features I see as necessity and ask for comment.