Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
Design question for complex folder setup
rwinterpacht
For our internal intranet site, we've been slated with getting a manual (all html) into TeamSite templating. We really only have two templates for this effort, one for the general page, and another for an index page, linking up the general pages.
I have even wondered if we need the index template, because if the files are generated in a folder structure that matches the manual's TOC (4 levels deep at most,) then the content delivery should be able to dynamically create bread crumbs based on the folder structure, and provide links to the general pages at run time.
Here's the REAL issue...the manual has a total of about 500 directories, so anything done at runtime needs to be pretty slick as far as creating this bread crumb trail. Also, there will be as many folders in TeamSite, so how does this stay manageable?
As far as dynamically creating the bread crumbs, or TOC, how would this be done based on folder structure? Our unix folders are all lower case, no spaces. It would be better to have an appropriate title for a folder, which could be picked up by some xml file that's also created and managed, and contains mappings for topic Titles and folders?
Anyone do anything similar, or have any slick ideas?
Thanks,
Raf Winterpacht
Household International
Find more posts tagged with
Comments
Migrateduser
I set up a system that allows users to set metadata on directories (such as title), and workflow to generate index.xml files containing the metadata for each directory and it's contents. I thought it worked pretty well for auto-generating navigation and breadcrumbs. I don't know how this would work with static HTML though (since you can't count on JavaScript in the browser) - I would instead generate XML for your content and have your webserver run XSLT on it. The XSLT could parse the index.xml files containing the directory information to create the breadcrumb. It is actually pretty easy to implement this - I used a .NET HTTP filter to do the XSLT (something like 200 lines of C#). There could be a performance impact so the compiled HTML was cached on the server.
Alternatively you could use another template or other config file where they could enter a directory name/path and a title for the directory, then have your TPLs use that DCR to create the breadcrumb, but I would avoid generating the static HTML unless the overhead of XML/XSL is not acceptable. A page that you think is static today may need to be dynamic tomorrow and you would not want to update all links to it. And if you change the look and feel (TPL) you don't want to regen every page - with XSL you can avoid that.
rwinterpacht
We don't use .NET for content delivery. We're j2ee shop running WAS 3.5/4.0, and have a content servlet that brings in content based on filters, locale, naming conventions, etc. We would have to figure something out there, but I would be very interested to see what you have for the metadata schema and the index.xml generation...
Thanks,
Raf Winterpacht
Migrateduser
I have moved on to another project so I don't have access to the code.
We set up a system for capturing metadata for directories using a normal template (not metatagger) and writing DCRs. It had normal things like title, description, etc. We used it more for navigation than breadcrumbs so we also collected things like sort priority, whether something should appear on navigation, etc. At the time of deployment to production the index.xml file would be updated with this data (parsed straight from the metadata DCRs in STAGING) and deployed. There was potential for conflict with other workflows trying to update the same index at the same time so we had to check for that condition. There was also the requirement to submit the metadata DCRs which would then update the indexes for the parent folders (if any). These three things were probably the most complicated parts.
I think it would be relatively easy to do in J2EE as well.