Forum OpenACS CMS: Openacs 4.7 New CMS Planning
we definitely do not need, while leaving open a way to plug in extra
functions at a later date.
We might be able to take some ideas for features from CMS and ETP.
Anyone who has implemented a CMS, what features did the client need,
and what sort of lessons did you learn from it?
It would be nice to have some sort of UI that can be configured to read/edit db fields based on permissions - and provide a log or notification of changes. It should be general so it can apply to any custom db implementation --perhaps read the list of available tables, types etc? Okay, this is low-level CMS extended to end-users --think canned DB UI access, not a CMS for an online newspaper etc. Still, a basic UI using a db that tracks tables, fields, field-types, data-input-format-constraints/triggers, permissions etc. could be useful for many reasons --especially if configurable.
Perhaps a CMS could include remote accessibility from a client tcl/tk graphic UI accessing the db/file-tree remotely in addition to browser access ..to reduce computing burden on the primary, publishing server (for scalability)?
Things it supports include
- The ability to assign an arbitrary template to an object type
- The ability to assign an arbitrary template to an arbitrary instance of an object type
- The ability to dynamically add fields etc to content types in the CR and to define new types via the web
- It will publish content to the file system which lessens the load on the CPU
- Has the scheduling stuff that's needed
- auto-generates forms for data input
So ... how about "write a reasonable UI that exposes the existing functionality"?
I'd actually like to see the capabilities more thoroughly exposed (which means mostly thoroughly documented) and bundled as an infrastructure package, if you will (the CR may be where it belongs though it's massive enough that a separate install makes sense).
Then our CMS package could be a particular UI on top of the infrastructure, just as file storage is a particular UI on top of the content repository (or would be if its nagging little problems got rewritten).
Torben ... one thing we've talked about is a DAV interface to the content repository. That would allow the use of remote editors with CR content over the internet. It's *very* important that we have it.
Both of these things are >4.7 though, I believe, given today's decision to try to push out 4.7 in late spring. I'd say they're both starting to bubble up to the top of the priority list, though, eventually they're going to survive the triage process.
With an improved API both the CR and much of the CMS guts would start looking a lot more attractive to folks.
And of course the whole UI issue's been discussed many times before.
You can try a alpha alpha version of the CMS I am working on:
The sample site is at http://126.96.36.199: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.
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.
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.
OF did take the tree_sortkey approach in the forums package, I helped to the extent of digging out the right datatype to use (RAW). I'd like to see us do some real-world performance testing of insert/update on large tables using this technique before getting too enthusiastic about using it. It may be that the penalty in Oracle won't be so bad (PG is just downright slower at massive inserts and updates even without the additional tree_sortkey baggage).
Which ever you think is best. What we need is a way to sort on a per folder level. Plus the fact that the sorting has to be across level. Tree_sortkey does accomplish this. Here is a sample
Aside from having the ability to sort BAA, BBA and BBB on level 2. When BBA moves BBC must move with it, since its the parent node. There is also a way to sort when you relate CR items. A sort order column is an optional field. The problem with this sort order column is that it does not have notion of heirarchy. Also it is pretty redundant to relate child items to its parent again just to gain some sorting.
In my opinion a good direction to take is how to make the explicit sorting on CR on both the child-parent and relationship aspect of CR.
Oh yeah my sorting is also not good in terms of performance and may also make the tree unstable. Its similar to Luke's implementation. I only added bi directional sorting. We really need to come up with sorting since on smaller CMS site explicit sorting is needed. Bigger CMS sites tend to use date and/or categories.