Forum OpenACS Q&A: coordinating CMS (+ETP) development a little bit...

It looks like quite some people are "cooking their own soup" on CMS.

Please correct me if I am wrong on one of the following:

-We have Dan Wickstrom working on a CMS

-We have Gregor Obernosterer working on a CMS

-We have Berklee working on a CMS

-We have Jun, Dave, Lars and others working on ETP2

There are surely more!

Shouldn't we coordinate CMS (+ETP) development a little bit?


Excellent point!

Most people have from my wild guess, rolled their own CMS for client projects because time was a serious factor and the clients had very specific requirements.

Hopefully these projects noticed the content repository is a good foundation for a CMS and saved themselves some work.

I have been thinking about this the last few days and yes we need an organized effort to make if easier to implement a CMS. In the UNIX style I am interested more in small parts that I can hook togther to make a CMS rather than a huge pile of code that does everything.

Right now the CMS package in OpenACS has every feature anyone could possibly need, but it is so generalized that it is an ideal system for noone.

My plan (dream?) is to break apart the good bits of CMS into several smaller service packages that can be put together to build many different CMS systems. I haven't had a chance to evaluate how this will be done, but I definitely want to coordinate this with the community.

We should have the new web site up soon (no, I won't give a real deadline, but we do have a plan of action :) After that I would like to start a subproject to evaluate the pieces we would need to build a CMS toolkit.

ETP, CMS, etc will then become similar packages that use some or all of these tools to implement different types of CMS interfaces.

Well put...

The big problem with the original CMS is it tried to do to much (i.e. all) and ended up doing it badly...

CMS as a collection of related items is definately a good idea in principle.

Perhaps if we can get a few people to agree/design an overall framework i.e. identify the individual elements, then we'd get more of it done more quickly, possibly off the back of individual client requirements.

David, I'm not doing anything with CMS or ETP2. Are you perhaps thinking of Luke?

Dave, this sounds like something that would take about 12 months to complete. Do you realistically think you could get it done sooner?



At this point, I haven't actually looked enough at the existing code or evaluated what code we would actually want.

I think I can start the project within 12 months. Hopefully we can get some interested parties involved and begin working on it. Its a huge project, and I don't imagine it would be done before a year at all. Again this is assuming all volunteer effort. With that it might be shorter or longer depending on the amount of volunteer time available.

I think I good way to proceed would be to take one function at a time, abstract it out of CMS or write a new one, and fix CMS to work with it, or another sample UI application, so that we have some working code all the time. If we tackle the most important pieces we can possibly have a mimimally functional application in a shorter time, but a full CMS framework/toolkit will take longer.

Hmmm. Did I actually answer the questiont there?

The current structure of cms: frames and clipboard UI metaphor doesn't lend itself well to a piecemeal restructuring process.  You would need to overhaul the UI (a big job in itself), just to get started.  A better approach would be to create a new CMS package and borrow heavily from the old one.  In theory, the new one should be completely compatible with the old one, so at some point - once the functionality has been duplicated, the old one could be removed from the openacs distro.
I'm not sure I agree with Lars' assessment. Largish piece of work yes... but 12 months.... crikey.... You could develop a whole new ACS in that time ;)..

As Dave suggested a more plug-in style architecture would allow progressive development, rather than a potential big-bang development.

As for a development based on the previous one... Noooo..... there are just some pieces of software out there that should just die... horribly... and stay dead ;)


I know that there are problems with the CMS user interface, but there is alot of useful code in there. Unless we have some other code to base this work on, I would prefer not to throw everything away.

Understadn what your saying Dave, but largely the 'useful'code is really provided by the Content Repository.

After a failed bid for a project I looked into CMS code in some detail..

My scientific assessment was .... 'shite'.....

Yes, there are bits and peices I wouldn't want to write again, but nothing of any significance.

This is compunded because the actual design (such as it was) they were working to was flawed.. hence lots of the code was written with an (arguably) floored design in place.

I should add I'm not interested in arguing about the state of old code. I am however *very* interested in content management!

What I'm saying is that were a new design/approach and flexible model being propsed I and some of my resources would be prepared to put in effort to write it...

If the proposal is to re-work/develop based on whats there now... then you're on your own ;) (meant nicely)

I really would encourage a design/method/architecture that we can get people to rally around... a re-hack of bad code (that virtually everyone has lost faith in or has a horror story for) is not a good idea.... and I couldn't justify resources for that...

I expect there a few other companies with the same opinion.

Also, is the CMS (in the existing form) really what we're after?

To my mind the current CMS is almost a developer front-end to the content repository. In fact I can't think of many customers who;d really want that kind of system.

My experience has been that in terms of CMS, customers tend to want somthing more like a page/template editor than a full blown CMS...

Perhaps we should actually survey the community and try and find out what peoples 'perception' of what they need is? Might be a good start point

Yes CMS is basically a developer front-end to the CR, but doesn't ETP already fit the bill for a template/page editor?  What would be the pupose of creating a variation on ETP?

ETP is what I might consider one of the elements in an overall CMS toolkit. ETP is fine, but its very, very basic. Good though it is its not an entire CMS....

But my point is have we decided what CMS means? Is it a developer front end to CR? If so then we need something very different than if it were a usuable CMS....

I do also have to add that as a page/template editor ETP has never been sufficient as that for any project. So maybe we don't need an alternative, we just need to vamp up ETP?
It seems that ETP is trying to address the page/template editor problem space, so improving ETP seems to be the right thing to do.  Maybe ETP2 is addressing the limitations that you preceive in ETP1?

As far as a developer front-end, something in the form of the current CMS with an improved UI might prove to be useful.

ETP2 is still being worked on. I am looking beyond that to a more genearl solution. Maybe ETP2 is a big part of this. Right now to add a new content-type with custom forms, you need to build the templates the represent the page flow for that content-type. This works, but it required a developer to add attributes and the forms to edit them.

Some things ETP doesn't have and we haven't decided how to add yet: adding images and multi-part content items. Changing a template per item instead of per folder. Categorization. Related Items. Dynamic generation of forms from content_type metadata.

The other reason I want to seperate out the pieces is to make features optional. I suspect that all the custom CMS solutions all had different needs using some parts of a CMS that other solutions don't need. So my thinking was to build up a CMS out of several packages that provide the various services that you need.

If we can decide on the core features that everyone needs maybe we should work on that while keeping open the options to extend functionality through additional packages, perhaps using service contracts.

I don't agree with the comment that a whole new ACS could be completed in less than 12 months (I waited longer than that for OpenACS4.x).