Forum OpenACS CMS: Learning from what others do well
At the Copenhagen discussion, it was mentioned that the ease of installation was one good thing about Postnuke. Another was its almost too pretty interface, which made use of alot of pretty icons. This is the kind of comparison I hope we can make and learn from.
It was mentioned to me that Plone and Typo3 are worth looking at.
Please do not flame the newcomer. Barbequed skin colour doesn't match any of my clothes.
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...
Not a small task indeed. But what you are telling is already in the contrib CVS. The docs are not yet there, still in word format. Have to convert to html once I think they are ok. Installation is still not out of the box, it will progress little by little.
I think other CMS solutions like Midgard, eZ, etc. has an ok UI, a lot better than what we have. In fact if someone really thinks that one of them is good, why not make a UI package something similar. Probably the best OSS CMS UI I have used is OpenCMS, looks nice.
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.)
Will report on what we find interesting.
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:
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:
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.
Right. I was at the Mozilla workshop, it was pretty interesting. Soon we should be able to start working on some sort of webDAV integration into OpenACS.
Keep us posted. I plan on looking into ways to use the content repository more consistentlyacross all packages.
I put up a short report from OSCOM also: http://www.thedesignexperience.org/oscom3/
I will try to write up some more ideas from it soon.
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.
I didn't see that anyone completed the Zope tutorial but it was more of a infrastructure issue than Zope's fault.
I haven't seen any other comparisons. I'll find links to other notes on the conference and link to those.
One interesting session was on version control in RedHat CCM. Their solution was quite different from OpenACS, but I think after seeing the presentation, the current implementation works well. An optional feature to produce diffs of text might be interesting though, I have thought about it before myself.
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.
The points about the size of a unified revisions table jumped out at me.
Storing the latest live revision of every item in a separate table would make a lot of qeries a lot simpler - perhaps it could even be an auto-updated denormalised table with a trigger on cr_revisions say cr_live_revisions...
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...
No article about relationships. You can look at bcms on the cvs contrib. It already uses relations.
In a nutshell here is how CR relations works. From what I remember we have like object_one_id (the parent), object_two_id (the related content) and relation (what their relationship is). I think there is also a order column.
Anyway for example we have article and want to relate some images on it. So the object_id of the article is object_one_id and the object_ids of the different images are object_two_ids. Then you give them a reasonable relationship like "images". You will have to add each relation for each image. So if you have the article, all you have to do is the query cr_relations (not sure, just from memory) using the article object_id as object_one_id and relation "images" you will end up with object ids of the images related to that article.
As for the live revision stuff, if you are pertaining to CCM data model is simplier. One one side it is, atleast getting the live revision. But on the other side it is not. a cr_live_revision may not be really needed. You just have to join a cr_items.live_revision to cr_revisions.revision_id.
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.
For instance the content repository does provide a generic, system-wide service. He may be confused because the CMS was originally a standalone system and he may not understand the fact that the CMS/CR split came about when it was integrated into ACS 4.x. Of course that generic facility is a bit light on Tcl API ...
The comment on its not being transparent to developers because one needs to write versioning code for each subtype is only partially correct. The insert views built for each content type handles the creation of new versions though they're inconsistently used in the toolkit. You do have to handle blobs directly but that has nothing to do with versioning, but rather Oracle limitations.