Forum OpenACS Development: Virtual urls in CR / File Storage

Don suggested in an email that what I tried to accomplish with my patch (see the thread linked to above) might already have been solved in the index.vuh file in the content repository.

The index.vuh file in CR requires that the content-types/items are associated with a content_template, though, so file-storage would have to be changed to accomodate content templates.

Is this an implementation we would like better than my proposed patch?

Any thoughts on this?

The CR provides the ability to attach a template to a content type or content item (which overrides the type's template, which is treated like a default in other words.)

I don't know if it makes sense to use the content folder's template on a content item, though ... because a content folder's template ought to be written to render the folder itself not normal content.

So offhand I think the hierarchy content_item->content_type->generic default makes sense.

You can see where this is headed ... a bunch of display code in file storage, its portlets, etc could be generalized to be attached to the CR itself using the CR's template mechanism.  The folder-chunk template could be reduced to calling some CR API to blend the folder with its template.  Changing the look and feel of folder display for folders in a particular package then just becomes a matter of associating a new template with that package's folder items rather than writing new code.

We want to be conservative in our expectations for OpenACS 5.0 but preliminary pushes in this direction (if people think it makes sense) could probably be implemented in the two-three month window we have available.

Thoughts?

Current heirarchy of getting the templates was more or less dictated by client.  Although I think its logical.  Here is the scenario.  User makes a new article, normally that article is in a section/folder.  That article normally should use the section/folder template, with out the user bother to explicitly set it.  We can either implement the scenario as how I have implemented it.  Or

- upon creation of article we use the same template for the section/folder to the article as the initial template.
- when user changes a section/folder template we need to change all items under it.  Some form of a trigger or something.

There is a problem with solution 2.  For example the user explicitly wants to use a particular template for an article.  If he/she changes the template for the section/folder, then we need to keep track which items where explicitly given a template.  If not then the user will have to go back to each item that had a different template, which was changed to the new section/folder template.

In the CMS I am working I would like to atleast have the following heirarchy.

content_item->parent_item->content_type->generic (note: still working on it)

Although I think a different situation may call for a different heirarchy, I guess it depends on the client needs.  One can always change the behaviour of BCDS (display) package or even maybe use another CR app to display.

I have seen some posts of you making FS to be a generic browser in CR.  It seems we are headed in the same direction.  Not exactly sure if we are duplicating efforts.  Anyway what are you thoughs about this?  I think I better HTMLized my overview doc and place it in the package docs as well.

I suppose your suggestion is better.  I will try to look on how to best implement this mechanism.

I currently having problem in converting my word Doc to html.  If someone has time maybe they can help in making them to docbook format.  The are just 3 docs as of this time.