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

1: Parent_id for folders with no parent in acs-content-repository

Posted by Dave Bauer on 11/15/03 10:58 PM

Currently the content repository reserves parent_id=0 for content folders that do not have a parent. For example, the -100 root folder has parent_id=0 and the root template folder has parent_id of 0.

This seems wrong. Besides these folders, parent_id should be a content repository item_id. cr_items.parent_id has a foreign key constraint on acs_objects.object_id. If we look at acs_objects, object_id 0 is an unregistered visitor.

I am looking for suggestions to fix this, or convincing that it doesn't need to be fixed.

2: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Lars Pind on 11/16/03 03:08 AM

I have a half-baked idea about CR folders, which would integrate it with the site map.

My thinking is that packages which wants to use CR for storage, but not particularly for content delivery, such as bug-tracker, I don't see any reason for the single CR folder hierarchy idea, where you have to construct a globally unique name somehow.

CR folders should hang off of site-map folders.

And in the cases where you do want to have CR folders actually reflect pages in a CMS, it'd still be most logical to use the site map for this, given that it'd actually be a site map.

So my thinking is that we should somehow merge site map with CR folders, though I'm not sure what it'd look like.

Does this spur any creative thinking with you CR gurus out there?

/Lars

4: Re: Parent_id for folders with no parent in acs-content-repository (response to 2)

Posted by Tom Jackson on 11/16/03 09:32 AM

I would think a good cr/cms would be able to represent a website. I've been playing around with a term 'Content Application'. This is simply an application that is essentially dealing with content. In contrast, a shopping basket isn't a content application, or the APM, not. But a website has all the qualities needed. In the case of OpenACS the problem is most websites contain packages which are not content applications. Integration is a head scratcher. The point may be that the cr can represent:

Actual Content -- web pages, images
Structure -- directories
Mount points (pointers to applications/packages?)
Application data.

I guess the idea would be to replace the site map with something you could pull from the cr.

If this is pursued, it would be nice to work on Don's ideas of providing a simplified content repository that doesn't maintain revisions.

3: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Dave Bauer on 11/16/03 03:37 AM

Lars,

You stole my idea again :) Although this time I have evidence :)

I have been thinking that any sort of CMS app needs to have a folder mapped to a site_node. In fact this is how the WebDAV support figures out which folder to look in for content.

Generally, I have an idea why parent_id can't be NULL. There is a unique constraint on name, parent_id and it doesn't seem that would be valid if parent_id could be Null.

The only idea I can up with was to set parent_id to the item_id if there is no parent, but I am not sure that makes more sense than the way it works now. Alternatively we could create a -99 no_parent object.

Anyway, I think that file-storage in the short term will use the 0, and we can fix it after. I should be able to release an updated file-storage package with WebDAV support shortly after release of 5.0. I hadn't tried to get it into 5.0 because at the time, it appeared my work would be later than the 5.0 release.

5: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Malte Sussdorff on 11/16/03 10:12 AM

My understanding so far has been, that we will see a change in paradigm with 5.2 the latest. Meaning, from 5.2 onwards we would have a subsite-enabled CMS system, which allows the mounting of packages to special URLs. I just see this from a user point of view, I got a site, I create my site-map, some of the items are Content Areas, some are packages and so on. Therefore I assumed that the site-map will be incorporated in a CR hierachy, not the other way round. Am I mistaken ?

6: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Dave Bauer on 11/16/03 04:50 PM

Lars,

I guess there are two ways to do this:

1) Define a root site_node folder, similar to file-storage and create child folders underneath it.

2) Create a site-node for each content folder.

I am thinking the second option would be best. It would allow easier URL calculation, as the URL of the site-node is stored in memory so you would only need to add the items name to the site node url to build a URL.

This also supports the one "thing" per package_id (or node_id) idea that seems to be preferred by some OpenACS developers.

So if we apply idea #2 to file-storage, each file-storage folder would be a seperate instance of file-storage. This creates an additional package instance object, but simplifies URL calculation.

Going even further, if the parent site_node/folder was stored in acs_objects instead of package_id, determining a URL would be quick and painless for objects that have a URL.

There are many options. I think definitely integrating site pages in with the rest of the objects is a good idea and makes OpenACS a better platform for content, learning, knowledge, etc management applications.

8: Re: Parent_id for folders with no parent in acs-content-repository (response to 6)

Posted by Lars Pind on 11/17/03 11:24 AM

I was thinking more along the lines of having a single site-map-and-content-folder hierarchy, instead of maintaining two hierarchies alongside each other.

Something like simply hanging CR items off of site-nodes instead of CR folders, and getting rid of CR folders altogether.

This leaves open the problem of packages that are mounted in several different places. The way I think we should solve this problem, generally, is that a package always has a single canonical home in the site map, and all other occurrances are symlinks to some other node.

Thoughts?

/Lars

7: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Jun Yamog on 11/17/03 05:26 AM

Hi,

For option 2 that would be very much like ETP right? I took option 1 for bcms-ui-base. Simply because there is no integration with site node and CR. But if there will be integration between site node and CR especially rename, move and copy. Then I guess option 2 is good.

9: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Jun Yamog on 11/17/03 02:59 PM

Hello Lars,

Yes content folder and site nodes does seem to have similar purpose. Or if you think about it, none CR apps use site nodes and CR apps use content folder.

Me and Rob had some discussion way back then about making a site-map app. That is able to create folders and content, also install application. See what Rob has turned modETP to, basically the external link are applications like news.

I am thinking that I don't think its needed to change the back end code. Maybe just the front end code. Basically if the application is a CR app. The site map should be able to render the sub folders. So the way I see it is that we will have a site-map front end that is able to display both CR and none CR based app. Right now site-map is more none CR app friendly. May be can have "New Content" along side "New Application"? So the new site-map will become the universal browser of the whole OACS instance. Its able to browse and install Content and Application packages. Also maybe we can have a mount option on site-map than can mount a CR folder. This is similar to what I have done with my /admin on bcms-ui-base. I basically mount/set a folder on CR which it will use.

Also a front end application will likely not break exsiting things. What do you think?

10: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Dave Bauer on 11/17/03 03:13 PM

Lars,

Exactly. That is how CR handles items in multiple locations in the hierarchy.

I am glad we are having this discussion :)

11: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Ola Hansson on 11/17/03 04:04 PM

If we decide sometime in the future to add to CR the ability to maintain "cr items light" (i.e. non-revisioned cr items), like Tom, Don and many others have discussed in the past, it may turn out favorable to merge the concept of cr items with acs objects entirely. Basically only differentiate between non-versioned and versioned acs objects, thus.

Just a spontaneous thought from someone who hasn't given it too much consideration ...

/Ola

13: Re: Parent_id for folders with no parent in acs-content-repository (response to 11)

Posted by Tom Jackson on 11/17/03 06:48 PM

Ola, I think it would be difficult to go that far. If so, we would just call acs_objects the content table and subclass directly from it. But there are other types of objects besides content. I was thinking of something similar to the parties table, where person, group, rel_segment come from. This table can hold info believed to be common to all content oriented objects.

12: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Don Baccus on 11/17/03 06:01 PM

Essentially "folder" should be an object defined by acs-kernel.

If we move further in the direction of folding "content_item" into acs-kernel for our "named object" needs, "folder" would be derived from this (as "content_folder" is today derived from "content_item").

And if necessary we could derive a special subtype of folder to match today's "site_node" type.

Along with supporting a non-revisioned form of "content_item" this would go a long ways towards unifying the two parallel object models we're dealing with, the basic acs-objects model and the glued-to-the-site-of-the-box CR object model.

Interesting things to think about ...

I volunteer someone else to write the upgrade scripts! :)

15: Re: Parent_id for folders with no parent in acs-content-repository (response to 12)

Posted by Lars Pind on 11/17/03 08:22 PM

Why would you want to derive a site_node folder from an acs-object folder? What's a use-case where you would need a CR folder or acs-object folder that isn't part of the site-map?

To me it's just one hierarchy, and that *is* the site-map. If the objects in your folders don't show up on the site, what are they doing there in the first place?

Of course, that means that if you want a structure of CR subfolders such as for file-storage, they'd also have to be part of the site map, but wouldn't it be useful to have them show up there?

(PS: Site map here refers to the site_nodes table, not the current /admin/site-map page, which I find horrible, and which we should then fix.)

/Lars

16: Re: Parent_id for folders with no parent in acs-content-repository (response to 15)

Posted by Jeff Davis on 11/17/03 10:10 PM

In a CMS you typically have content components that don't really meaningfully show up anywhere on their own other than within the CMS itself (like stock images for example). Also, content producers and editors probably want to have a flat view of existing articles,authors etc. rather than digging through the heirarchy defined on the public side. And finally, where something ends up being placed on the site may not happen until well after the content item is created. It's easier to implement a sensible presentation layer for content generation by having folders organized by content type and then mapping them into the site map

I think that was the thinking behind divorcing the CR heirarchy from the site map (well that and it was developed by the rebel code conclave).

Look at etp now. I would like to see all the etp pages, when were they last updated, are there unpublished revisions, etc. but right now it's extremely site-map-centric. You have to know where where in the site to look to find pages and there is no easy way to reuse content components.

Of course etp solves a deliberately small problem and does not claim to be a general CMS for content generation and it's certainly possible to be site-map-centric and still cater to the workflow/UI you would want for publishers and editors but there seems to be a tradeoff between simplicity on the content presentation side for simplicity on the content generation side and I think the later might be the more difficult to address.

19: Re: Parent_id for folders with no parent in acs-content-repository (response to 16)

Posted by Lars Pind on 11/18/03 12:46 AM

Jeff, we're not contradicting each other.

Stock images: Sure. Would it hurt if they're available to people with proper permissions under /cms/assets/whatnot?

ETP pages/flat view: Just because content items are available under their natural URL doesn't mean they aren't *also* available in a list view from an admin page.

Placing content: Same thing, the content item could belong to the admin UI package at first, then when you're ready, you move it to the right place.

I might be wrong, and any solution that brings us closer to where we ultimately want to be is an improvement. I just want to make sure it's given due consideration.

/Lars

14: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Don Baccus on 11/17/03 07:37 PM

Yes, I think Tom and I are on the same wavelength ... if (for instance) a site-node containing a package is considered "content". (a folder that contains other content items which just happens to map to a package rather than a versioned or unversioned content item).

object->named_object->folder
                    ->versioned_content
                    ->unversioned_content

etc ... CR extlinks and symlinks could then be mounted to the site map, too ... hmmm ...

17: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Don Baccus on 11/17/03 10:42 PM

Lars ... I'm thinking of a different way to model it, that wouldn't need a separate site node map table. If we map the current cr_folders entries to the current site map table, then the hierarchy for these objects is being maintained twice, once in the folder-parent relationship and once as a row in the site node table. There's really no need for this.

Just blue-skying ...

Jeff makes some interesting points, too ...

18: Re: Parent_id for folders with no parent in acs-content-repository (response to 17)

Posted by Tom Jackson on 11/17/03 10:56 PM

So couldn't you have a content type of 'website'. This could include other types (site-node), files, directories, etc. If a package isn't mounted on a node it wouldn't show up. Each website content item would represent one website, so you might maintain more than one site in one cr. If you could include or link to other content items easily, they could be included by reference (Can you do this now?) But the reference link (content type) would have to include information on when to publish, etc. since that is a property of the parent content item, not necessarily the referenced item. Also the item might, for instance, show up on one site but not another. But I think the key is that the 'website' type would be one way to view the data, not the only way. Obviously there would need to be administrative views as well.

However it ends up working, it shouldn't slow down the operation of the current site-note model (is this going to be cached somewhere?)

20: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Don Baccus on 11/18/03 02:22 AM

Tom, yes, that's more or less what I'm thinking though I've not thought it through yet :)

21: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Dave Bauer on 11/18/03 02:30 AM

Jeff,

Great. I am glad this innocent question had spurred an interesting discussion!

I agree that you do not want to browse to where a page is ultimately located to start working on it. This is more of a large web site model than a small web site model that ETP works for.

The old CMS package seems to support this type of operation while still also maintaining a folder/site-map concept.

This is also why we need a fleible API to build a CMS user interface. The base tools should support both of these and more user models.

22: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Dave Bauer on 11/18/03 05:39 PM

Coming back to the original question. I still need some sort of solution.

Right now, if I have two file-storage root folders, they have to have unique names. That is why they are named file-storage-12345 with the package instance object_id as part of the name.

If we use -100, 0, NULL, it doesn't matter. It would be impossible to name more than one folder "file-storage".

If would be impossible to install two package instances of file-storage called file-storage.

One solution is to special case calculating the URL of a site_node folder and pull the name from the site_node name instead.

An ugly solution would be to use a non-cr object_id as the parent_id. I had thought to use the item_id iteself as parent_id, but this fails if someone tries to add a file with the same name as the folder name, or a sub-folder with the same name.

So I am open to any solution to this problem. I guess in dotLRN the file-storage site nodes are named after the class they are mounted under so this won't necessarily cause a problem there.

So i guess the question is, should a root folder of a folder hierarchy use the cr_items.name attribute as the URL fragment for that folder the same way all other content_folders do?

23: Re: Parent_id for folders with no parent in acs-content-repository (response to 22)

Posted by Lars Pind on 11/18/03 09:31 PM

I'm not quite following what the hierarchy would look like in your examples above. I think it would be easier if you could describe the options with a little ASCII diagram.

However, would the non-CR-item parent_id be so ugly?

Why not use the package_id of the file-storage package as the parent_id of either the root folder for that file-storage instance?

/Lars

24: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Dave Bauer on 11/18/03 09:52 PM

Lars,

Main Site
    |
     -----Subsite 1
    |        |
    |         -----file-storage
    |
    |-----Subsite 2
             |
              -----file-storage

So if the parent_id is the same for all file-storage root folders, it will not allow more than one root folder called file-storage.

25: Re: Parent_id for folders with no parent in acs-content-repository (response to 24)

Posted by Lars Pind on 11/19/03 07:46 PM

Here's a write-up about my thinking on this topic (packages, site-map, folders, etc.):

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

Please read and comment.

/Lars

26: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Don Baccus on 11/19/03 08:22 PM

My first reaction is yes, this is where I've been heading in my thinking process, though I need to think about it a bit more.

27: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Mark Aufflick on 11/20/03 01:05 AM

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

31: Re: Parent_id for folders with no parent in acs-content-repository (response to 27)

Posted by Lars Pind on 11/20/03 09:04 AM

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

32: Re: Parent_id for folders with no parent in acs-content-repository (response to 31)

Posted by Lars Pind on 11/20/03 10:37 AM

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

33: Re: Parent_id for folders with no parent in acs-content-repository (response to 32)

Posted by Jeff Davis on 11/20/03 11:16 AM

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

28: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Dave Bauer on 11/20/03 02:39 AM

Mark,

Have you looked at the original CMS package? It is meant to accomplish pretty much what you suggest. Of course the UI is unpleasant and it was never fully integrated into OpenACS. It looks like we all agree that finishing that job is the way to go.

29: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Don Baccus on 11/20/03 03:33 AM

Mark - the site map still exists, the new UI means you don't need to use it as often but it's not left us!

30: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Jun Yamog on 11/20/03 06:34 AM

Hi Mark,

So what you are thinking is something similar to what me and Robert L. was thinking too? (see post above)

34: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Mark Aufflick on 11/20/03 01:05 PM

Jun, yes and yes,

Ultimately, doing away with the site node structure and replacing it with a CR structure would be neatest - but even for 5.1 that's a LOT of api breakage.

But, it's ultimately the way to go , and CMS would actually be mounted at root - ie. replace/superclass ther subsite package (or something like that - i'm more worried about how to make it work as an installable package first)

35: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Dave Bauer on 11/20/03 03:11 PM

I agree with Jeff. Querying the site map for a URL is fast, and usually easier than requirng a package_id. For example, when you include a lars-blogger in another page, the URL is a better reference in case you move the site or need to reinstall.

How does the site-node/folder idea work with my idea to give items a URL based on their name? Using they parent_id (node_id/folder_id) we can build a URL easily in Tcl without any cost and we can get pretty URL even in long lists of objects.

36: Re: Parent_id for folders with no parent in acs-content-repository (response to 1)

Posted by Jun Yamog on 11/21/03 06:42 AM

Hi Mark,

I think its possible to do it without breaking things. What we currently have is a site map that is able to mount application. The only change I see to is the ability to mount application and content.

Currently it can mount content through application packages like etp and bcms-ui-base. But it would be better that I can natively support CR. Maybe make the site map a bit more pretty. But aside from that I think its possible to have similar effect without having a lot of changes on the lower layers.