Forum OpenACS Q&A: ETP and the -100 root folder

Collapse
1: ETP and the -100 root folder
Posted by Lars Pind on 03/18/03 05:53 PM
When you use ETP on your home page, the pages under your site root (/) sit in the CR root folder with folder_id -100.

One problem with this is that other applications stick stuff in there as well, which causes it to show up at the bottom of the /etp page -- the page that lets you edit your home page. But these items have no title, so it looks kindof silly, and obviously the 'edit' links don't work.

Right now, the non-ETP-related contents are:

- a file-storage root folder
- two user portraits
- two bug-tracker root folders

It just seems wrong that my site's root pages are intermixed with various application folders.

What's the right fix here:

a) other packages should stop using the -100 root folder -- what should they do instead?

b) ETP should create its own "site root" folder, under which other folders would get created.

c) ETP should just find a way to filder out which items belongs to itself, and ignore the rest.

d) something else ...

In keeping with the posting I just made over at

https://openacs.org/forums/message-view?message_id=71087

I'm thinking why we need folders for this anyway. I mean, we at least want one CR folder hierarchy, which exactly mimics the site map, so why not just use package_id?

Then *maybe* we *also* want to be able to have CR folders for subdividing things within a package instance.

E.g. a CR folder per forum in a forums package -- even though I think packages should only have a single forum per instance, and we should use acs-subsite/ETP/Portals to give you the list of available forums and let you create new ones.

What would other examples be, where you'd want CR folders that weren't mapped to the site-map? Maybe none.

Comments?

/Lars

Collapse
2: Re: ETP and the -100 root folder (response to 1)
Posted by Dave Bauer on 03/18/03 06:06 PM
Lars,

I think ETP should mount its own folder for each site node. This should be unique to ETP, so that it does not interfere with any package folders. I am not quite sure how this can work with the existing content repostiory folders. Perhaps ETP would maintain a parallel cr_folder tree, so that we have an ETP root folder, and all the ETP managed folders live under that, so they do not clash with other content folers.

I agree, Forums needs to break out into one forum per package instance. But we need to acknowledge the issues that raises such as moving messages betweek forums instances, similar to the problem we still have moving bugs between bugtrackers. It is just a UI problem, but we need to keep it in mind.

Collapse
3: Re: ETP and the -100 root folder (response to 1)
Posted by Don Baccus on 03/18/03 06:47 PM
You're paralleling some of my own thinking, which starts with the observation that the use of folder -100 in the toolkit is one of those horrible hacks I so loath.  I haven't quite gotten my mind around it to where I'm sure of the best solution, though.

But when I have thought about it ... yes, packages should make package-instance folder for their content.  Having this map the site map, yes, there would be advantages to this but the first point is crucial.

For instance, file storage is totally messed up.  It always makes a root folder at the root, so permissions aren't inherited through the sitemap, i.e. the subsite it's moutned under.  That truly sucks.  This is why the dotLRN code makes a folder for a class then immediately revokes and grants a bunch of permissions.  Yuk.

Fixing file-storage is on my personal list of things to do, out of pure hatred for the way it's implemented.

One forum per forum package instance ... this certainly simplifies it.  In general I think this simplistic approach is right for packages, makes them simple to write and once we have subsites straightened out should help consistency.

But it increases the burden on subsite - Dave's example being a good one.  subsite will need to be taught how to gather admin information about a suite of mounted packages (service contract approach?)  But doing it once in the subsite package rather than adding custom pages to packages each in their own style etc should, overall, make life simpler if we can figure out a good way to do it.

Ditto things like the forums page that lists user contributions.  We really want that kind of stuff happening at the subsite level, if each package takes it on themselves the look/feel will undoubtably be different everywhere, given that independent groups of people are writing all these things.