Forum OpenACS Development: Re: Parent_id for folders with no parent in acs-content-repository

Darn it - i'm in the wrong timezone!!

This discussion covers pretty much what I discussed a few days ago with Bruno M when I was explaining my vision of the new CMS package (which a few organisations are now apparently interested in  putting money into which should help accellerate it once 5.0 is released).

It's not fully described in these CMS project pages: https://openacs.org/projects/openacs/packages/cms-future/feature-list
https://openacs.org/projects/openacs/packages/cms-future/meeting-2-minutes

and they are full of stuff that won't be interesting to people who don't care about CMS.

The thrust of my idea is that normal people don't think of a website or intranet site in terms of applications, they think in terms of the site map. Given this, our new UI is actually less intuitive than the original site map (people always love the site map in demos).

So how it all links together is that the CMS manages the whole site map, and every "node" of the map can be a "content node" which can have other "content nodes" hangin off it - or an "application node" which then behaves however it likes.

All the permissions and parameters etc. are managed through the CMS site map UI, and thus the CMS in fact becomes the root application.

That's a very brief summary of my view - and it's all about user interaction. Whether to replace the site map structure with the CR structure or not really depended on how much buy in we got for the idea, but it seems to be a popular concept in theory.

PS: I'm with Don - someone else can write the upgrade scripts ;)

Mark,

This sounds very nice.

Yeah, we should write a new site-map without the failures of the old one.

I think for a groupware type situation, dropping in applications makes sense. For this situation, I actually want it to be a list of applications with checkboxes next to it, so you just check off the functionality you want in your group.

For content management, a site-map is perfect. Let's revisit that for 5.1.

/Lars

Btw, I added a short section on magic objects for site root and unmounted packages to the document:

http://www.collaboraid.biz/developer/site-map

Lars, it's not entirely clear to me why you would subclass folder_symlink from folder (although I guess I can see some justification).

We should also think about the things which currently end up with context_id null (which includes user, apm_*, acs_sc_* notification_*, and portal_*). For the service ones they could be under the service instance, but I think for users we should have another magic object to hang users off (which would let us permission people to admin user accounts via that magic object).

I would like there to be no null context_ids in acs_objects (other than the security_context_root).

Also, you say

Today, in order to find the ID of the main site, you have to query the site map for the site node with no parent, and the object_id will be the main site. Having a deliberate magic object for the site root should be slightly faster, and actually more robust, since we're guaranteed to just have one.
but I think getting at it by using the url "/" will do it w/o a db query at all (although I agree a magic object would be good to have as well).