Consolidating data directories for multiple DCTs

Most of our branches have at least 2 or 3 different DCT's, usually a standard index page template and a content template. Some also have lists and specialized templates as well.

One of the big usability issues we've come across is that each template has it's own data directory which seems redundant and inefficient. When using the browse option in editing an index page DCR to link in other templates, users have to browse up to /templatedata and then back down to the particular template the DCR belongs to.

In addition, many of our branches with lots of content use directories underneath the data directory, so creating the directories under all of the available templates is a pain.

Has anybody ever been able to create a single data directory for templates that could be shared for all the templates in a branch?

Find more posts tagged with

Comments

Adam Stoller

Has anybody ever been able to create a single data directory for templates that could be shared for all the templates in a branch?

This won't work with the current implementation of Templating (and it's very questionable whether this will change) as each DCR is directly associated with the DCT that can be found by traversing down (../..) the directory tree.

In theory, if the system used the already existing EA (TeamSite/Templating/DCR/Type=category/data-type) as long as the DCT existed in that branch it should be possible to locate the correct DCT to render the data contained within the DCR - but it doesn't, so you can't.

The alternatives are: (1) set a better initial directory for the browse tool; (2) use some form of search/query tool to search for applicable DCRs and then select one from the resultant list, rather than browsing through a directory tree structure.

This last alternative might become more feasible in the next release of TeamSite which is supposed to have some enhancements for searching within the system ... but that's not guaranteed and doesn't help you in the here & now...

When using the browse option in editing an index page DCR to link in other templates, users have to browse up to /templatedata and then back down to the particular template the DCR belongs to.

Why do you need to do this? Why not have the index generated programmatically? Perhaps use EAs on your DCRs to indicate whether they are available for appearing in an index or not - or something like that.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Dwayne

As far as I know, what you're asking for isn't possible in the current architecture. Sounds like fodder for a feature request.

One thing that you might be able to try: (warning - even if this works, I don't know if it's supported)

If I remember correctly, you're running on a Solaris platform, right? Given that, you might be able to replace the data directory with a symlink to the "real" directory. That should accomplish what you're asking for, with some caveats:

You're "breaking" the standard TeamSite model, so you never know when wierd stuff might jump up and "bite" you.
All DCRs would show up in the "open" dialog box for all DCR types, since, as far as I know, the system doesn't filter that list by EA, but only by directory.

If I'm mis-remembering, and you're on Windows, then that isn't even an option. Windows shortcuts don't work enough like symlinks to function for this purpose, and the NTFS equivalent that would do it, junctions, aren't supported by the IFS.

--

Current project: TS 5.5.2/6.1 W2K

mike_jaixen

<i>When using the browse option in editing an index page DCR to link in other templates, users have to browse up to /templatedata and then back down to the particular template the DCR belongs to.

Why do you need to do this? Why not have the index generated programmatically? Perhaps use EAs on your DCRs to indicate whether they are available for appearing in an index or not - or something like that.<i>

Long running battle with our designers; we have never been able to come to a consensus on how to automatically maintain those index pages, especially in terms of ordering the links. Everytime we thought we had a solution, we found another exception. Finally, we threw up our hands and said we'll do it manually through a DCT until we can get a consensus.

Sym links might be an option (since we're on Solaris), but I'm afraid of what will break, plus the configuration would be cumbersome as we move forward. I was curious if anybody else had found this setup restricting, or if it was just us.

jbonifaci

Why not just write your own browse that doesn't require the users to go all the way up to templatedata to get back down to a different data. Lets say you have 3 category/datatypes called catA/typeA, catB/typeB, catC/typeC. When the user clicks on your custom browse, it would display 3 directories:

catA/typeA/data
catB/typeB/data
catC/typeC/data

This would be the highest level it would go to. That way they just select which kind of template they are looking for and it jumps right into the data folder. This, or something like it, should be simple enough to create. You could also just have your browse start at the data directory level, and have a drop down on the top of the screen for the user to select a different cat/type and it would jump to that data directory.

All of these are fairly simple solutions to implement and should make it much easier on your users.

Johnny

Here is a little left wing option:

It wont suit all situations, particularly:
- if you manually select from multiple PT's.
- You regularly manage a large set of template types which are fairly complicated.

What you can do, is embed your 'content-types' into one.

With a little form api / metadata and containers, you could group your fields into different containers for your different types.

Then based on the content type chosen from a field, your main PT driver selects the appropriate PT to handle that selection.

It is a little bit off the track in terms of how TeamSite makes you think about content break up, but it can make things a little simpler for your users at the cost of more planning up front.

Like I said, it wont always be appropriate, but if done correctly, it isn't very hard to revert it back with a little migration script.

I would never look into options like this (that appear different to the TS approach), unless:

-its really well thought out against the expected use, (pro's vs con's)
-there is a clear way it could be brought back into the TS approach if ever needed.

John Cuiuli