Hi Don,
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.
