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

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.

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?

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 ;)

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.

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.