nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

templatedata - in which workareas?

System

Hi all -
I'm (still) working on my first Templating project. I've got most everything the way I'd like it - dct, workflow, etc.

In testing the workflow, I'm starting to wonder: how should I handle my templatedata directory? Right now, I've got it privatized, so I don't submit any of the templatedata info into STAGING. I also have a QA workarea that I sync up with my primary workarea - but I'm not sending any templatedata info there either. It's only kept in my primary workarea.

Do any of you have suggestions on managing templatedata? I'm thinking I really don't want to send it into production..

Thanks,
Wally Box
Nike, Inc.

Find more posts tagged with

Comments

nipper

>In testing the workflow, I'm starting to wonder: how should I handle my templatedata directory? Right now, I've got it privatized, so I don't submit any of >the templatedata info into STAGING. I also have a QA workarea that I sync up with my primary workarea - but I'm not sending any templatedata info there >either. It's only kept in my primary workarea.
Manage templatedata as a regular asset.

Keeping it private means no workflow, versioning, etc. IMHO bad idea.

You can neglect to deploy anything in templatedata if you desire, there is no real reason to deploy the XML
unless you use an application server (TI is an example of a company that does this) but most either deploy
the pregenerated HTML or use datadeploy to shove the XML to a RDBMS.

Where would you like more details ?

Andy

Adam Stoller

FWIW - I second Nipper's comments - not versioning templatedata is "bad"
A simple exclusion filter in your OD config files will keep anything under the templatedata directory from being deployed to your production servers, a much better way to go.

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

Migrateduser

Good replies. I had concerns about putting templatedata in autoprivate which resulted in this posted thread.

The reason I did it in the first place was that I was following a general rule that, if it isn't something destined for production, it should be autoprivated. This way, I advoid getting WS_FTP logs, Dreamweaver _notes and other misc files into STAGING and Editions. Then, when an edition is cut, it's truly an edition of what's in production. Then, I don't have to write exception processing for every OpenDeploy configuration written against STAGING or an edition. A comparison deployment will become twice as complex now, but 2x an easy process will still be pretty easy.

We've ended up doing as Fish suggested: archiving templatedata but not deploying it into production.

This is perhaps an 'opportunity' for TeamSite to manage content a bit better. While the content and EAs are sort of managed separately, the versioning system considers them one and the same (try batch tagging all of the content in a workarea and then go back and see if you can do a 'list modified' to find out what work you had in progress before the tagging. Every single file is now modified) and, now that I'm working with Templating, I've discovered another set of information that's intertwined with the content - but not intended to go into production. There should be a straightforward way to work with just the site's published content.

Thanks again,
Wally
Nike, Inc.

gzevin

just adding - even though Nike apparently won't be using CC STD, it now take DCR together with the file and sumbites them together - so this is way of sumbitting DCRs has been given a better 'poiminence' even in teamsite itself Smiley Happy

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

TS 5.5.2 (moving to 6.1) Win2K

Then how about the EAs?
How should we go about setting the EAs on DCRs?
I want the DCRs to be as transparent as possible for the end users.
After the user does a generate, I'm setting the EAs only on the generated HTML.
What should be done with the DCR?
Should I copy the EAs set on the HTML to DCR and submit the DCR as part of the workflow?
How about expiry and archival? Shall I expire/archive the DCRs as well?
I'm planning to move the expired contents to another location (may be an archive branch in Teamsite). Haven't thoght what to do with DCRs.
Whats the recommended way?

TIA

gzevin

How should we go about setting the EAs on DCRs?
I want the DCRs to be as transparent as possible for the end users.
After the user does a generate, I'm setting the EAs only on the generated HTML.
What should be done with the DCR?
Should I copy the EAs set on the HTML to DCR and submit the DCR as part of the workflow

by default metadata is now also attached to DCR as well by the wizard. I personally think it's not required on 99% of cases, so I was waiting to get 6.1, so one could regex the wizard so it does not pick up DCRs.

if you are using CCPRO only,, you could (eg as I do) add an ext. task that adds DCRs for every templated file. If you run tagging CGO task on the files, DR will ome along as well.

as for the xpiry, etc - it's all yours, as per your business requirements

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Valentine

in addition to that check
autoprivate.cfg and submit.cfg

autoprivate.cfg - file that is responsible for the "privatization". If anything matches the rule in it, the file will not be submitted into the STAGING.

Adam Stoller

I highly recomment that you NOT use autoprivate.cfg to prevent DCRs from being submitted to staging - DCRs are "source" and as such they should be versioned in STAGING. You may want to exclude them from being deployed - but that's a different matter (and was recently discussed in another thread somewhere).

Setting EAs on DCRs and/or generated pages varies based on the customers requriements and the processes developed to support those requirements. There's no one-right-way of dealing with it.

My customer only sets EAs on DCRs and/or non-templated files. The workflow takes care of generating pages from the DCRs and transferring the EAs from the DCRs onto the generated pages automatically.

Other customers look at the DCR as being soley tied to the content and not the metadata and therefore have metadata set on files later in the process, after the pages have been generated, and explcitly skip requiring metadata being set on the DCRs

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