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.