Forum OpenACS CMS: Re: Openacs 4.7 New CMS Planning

Collapse
Posted by Jun Yamog on
Hi,

You can try a alpha alpha version of the CMS I am working on:

http://66.250.57.130:9080/1ic/

The sample site is at http://66.250.57.130:9080/site/

Take note that its in pre alpha condition.  Also that I am not 1iC, its a client.  The server resources is generously donated by Talli (Musea).  The first site to use it is at http://www.praesagus.com

I am still making a doc but you can download a simple doc what its current capability is.

http://66.250.57.130:9080/cms_capability.rtf

The CMS sits on top of CR.  Atleast around 50% of the api is a tcl wrapper to the db api of CR.  Also it should be compatible with the current CMS, not tested yet.

It consists of 3 packages:

- bcms (basic content management system) - this one is a bunch of API, get_foo, list_foo, edit_foo, etc.  It does most of the work

- bcms-ui-wizard - a BCMS UI implementation its the one that you see right now.

- bcds (basic content delivery system) - its /site.  BCMS is for getting content in, and BCDS is for getting content out.  Although after real world experience, I think this design has to rehashed.

Why the idea to break into 3 packages:

- developers should in theory add his/her own UI.  Based from experience UI in CMS is always client/industry specific.

- give a small set of api for developers to build the UI.  Its already what CR provides, BCMS just makes the layer higher on the Tcl level.

- the rendering of the content (BCDS) in theory (not fully implemented) should make it render a sub tree of CR.  So for example a BCDS instance will serve /mysystem/public-site folder and render that contents and merge with templates with 'public' context.

- the management of the content in theory can be any CR folder.  For example this BCMS UI will manage /mysystem/geek-section and another UI for /mysystem/wizardy-people.

There is a lot of things to be done.  I am only able to put time into on weekends.  I haven't even made a high level design doc :( .  The API needs to be changed like list_items_with_ancestors to be moved to tree_items. etc.  Installation pages so you can move the package to use another folder easily, rather than going to site-map and editing the package parameters.  Permissions, workflow etc.  But as of now my priority is to hammer out the API and produce a high level design doc.

I put this out earlier than anticipated because:

- I am excited about it (yeah I am honest about that)
- Do not want duplicate effort, sadly it already does duplicate Dave's effort into ETP2.  Although Dave already knows about this prior to this post.
- Maybe I can get some real volunteer effort.
- Ask the gatekeeper to include cr_items.tree_sortkey on OACS Oracle 4.7.  There is just no good way to implement explicit sorting.  We already have this column on PG, why add a different one for Oracle?  Lets just use the same column/structure.

Thanks.

P.S.

The code is available, although the only current use as I can see is how some functions are done.  And maybe can be used by other packages.  The code will be greatly changed so  you might end up with a dead end code.  Its not ready yet but you are free to look at it, especially if you will help me.