templatedata as a separate branch

Can anyone who's currently doing this enlighten me to the wisdom of keeping templatedata files in a separate branch? What are the benefits, pitfalls, etc.?

Thanks for any input!
maureen

Find more posts tagged with

Comments

Migrateduser

Maybe someone could explain the wisdom of not keeping templating components in a centralized location?

nipper

I have some problems with this.

Maybe someone who has implemented it will reply if what I say is wrong, however one key
point to me is that if I "edit" a file generated by a DCR, & the DCR was on a different branch, I
do not think it will open the correct file. This also implies that iwregen won't work since the
EAs do not have branch information in them.

Thus when I changed my TPL for a new look and feel and ran:

find . -type f -exec iwregen {} \;

(which regnerates all the files in my branch/dir) it may not work.

That would be bad.

Andy

Migrateduser

Not sure what you mean, but I think the answer really depends in part on how you approach generation. The DCT still has to exist in every branch or you can't create/edit records through the UI. If your DCT and PT code is scattered all over the filesystem, doesn't that make it hard to maintain, especially when the same DCT and TPL code exists in multiple workareas on a branch or multiple branches? I hate that, but because DCT symlinks don't work on Solaris and NTFS doesn't even offer symlinks, I usually write a custom menu item or other functionality that replicates the DCT from a dev branch to the branches that need it. Something that should ship with the product? Probably.

If you don't use iwgen/iwregen (which you probably shouldn't - they don't report bugs in your presentation template, don't let you gen to /tmp, don't let you -ocode, don't let you call a template in one branch with a DCR in another, etc.), the extended attribute storing the PT name may be wrong (I haven't tried storing a file path in this attribute - that may actually be supported). This is not the only case where iwgen/iwregen won't work. For instance, many implementations use custom parameters to iwpt_compile, and regen through the UI or on the command line won't pass these, which is bad. I always call iwpt_compile instead of iwgen/iwregen. This should always be wrapped with something that sets the DCR path, etc. appropriately. I set the PT to something that's cleary broken (like PREVENT_REGEN_pt.tpl). when I know a file has been generated with custom parameters, etc. Another option is to store the custom params as an EA and use those if they are not passed on regeneration, but generally these sub-regenerated files should not be regenerated through normal regen processes.

I know that's not a clear explanation to anyone who hasn't dealt with these issues. Depending on how generation works in your environment and how much code is duplicated, centralizing code management may not be a good option for you.

Adam Stoller

First - you might want to look at this post to see if this is something you want to register your organization as being interested in.

Second, as Nipper pointed out (and the above referenced feature request deals with to some degree) - there are some problems with trying to have templatedata (DCTs, DCRs, PTs) in a different branch from where the generated files are intended to live.

If, however, you are talking about supporting a site which is composed of both templated and non-templated assets - and you want to organize these into two branches - that's certainly possible and may make sense (depends on all sorts of variables). Going this route, the DCT/DCR/PT and generated page would live in one branch and the Word/PDF/JPEG/non-templated HTML files/etc. would live in another branch. You'd probably need to set up proxies to handle finding referenced pages in the other branch so that the virtualization of the site within TeamSite worked, but if there is sufficient reason for having this separation, then the additional configuration / maintenance can be justified.

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

nipper

I understand the senerio that John presented, when I am reusing DCRs across many branches,
it makes sense. However if you (mogoo) are using a DCR on only one branch, then it
may not be worth the headache. If you saw the code I produce you would not be too quick to
reuse it either.

Andy

mogoo

Wow, I hear ya, Andy, fish, john. Thought the templatedata branch thing might be a simple solution to our problems, but it looks like it's definitely not simple.

We have our production branch. Then there are projects that
A) can't go on to production STAGING yet, and/or

require global template changes/additions that can't be in production yet.

Let's say, for example, we're adding a new pages to a section. The new pages can't go live yet, and we need to alter the global templates, to include these new pages in the left nav.

So we do these type projects in a development branch, after copying over all the necessary templates and global files. Two months later, when the project is ready, inevitably we forget to migrate some of the changed global templates back to the production branch. And, in that 2 month span, concurrent were made in both the production and development branch.

So I was hoping that keeping templatedata in 1 branch would help make this development to production process a little simplier. I envisioned:
/production_branch
/development_branch
/templatedata_branch
-----/production_workarea
-----/development_workarea
...I thought that would solve our 2 problems (A&B) because we'd have 2 separate html staging areas (to deploy to different servers, when needed), but 1 templatedata staging area (to keep better tabs on all templates). But if it's more headache than it is worth, I guess we'll stick with the headaches we know.

I'd be interested to hear any input people have on sub-branches to help manage these issues?? Or is that just opening yet another can of worms? Smiley Happy

Thanks for the insights!
maureen

Migrateduser

I don't see many issues on this site that are not a cans of worms.

nipper

>I don't see many issues on this site that are not a cans of worms.

I tend to agree with John esp since I am not the one to fix it if there are worms.

I assume you are unafraid of the proxy settings, as you wil probably need to hack with those
to get the templated pages to view properly. Everything else looks pretty solid.

Andy

Migrateduser

Actually let me change that comment. I do see plenty of trivial solutions (FormAPI syntax, etc.), but for the core architectural issues and problems I generally don't seem to end up with solutions I consider "enterprise-class". So this site provides solutions, but does not address issues.

Adam Stoller

If the differences between production and development are in the PT, rather than in the DCT, you could use logic within the PT to determine which branch it's in and thus do different things depending on whether the DCR was in production or development.

I've tended to find that doing all templating work within the confines of a workflow - and having the workflow be responsible for generating pages (and removing that option for use outside the context of a workflow) to be a "best practice". You can do so many things within the workflow based on the branch, workarea, directory, etc. to control what gets generated, where it gets generated, how it gets named, etc. that it tends to remove all those complications from having to be somewhere else and require that users (or developers) do "this" or "that".

Ah well - maybe it was just me jumping at the can-o-worms (that's "bait" to me :-)

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

Migrateduser

Umm, good bait. I totally agree that generation controls should be in the DCR (data) and workflow (logic), not in presentation. It's pretty easy to add a drop-down to the template that lets the user select the output directory (make it readonly on save/open, so they don't generate orphans), then just name the output file the same as the DCR. Actually I like to put a field in the DCR where the user can enter the file name (maybe functionality to select/create a directory), that way I can restrict the name to web-friendly characters. And about 200 other "enhancements".

All stuff that should ship with the product. Because the more you customize, the more upgrade challenge you will face. Of course since the system does almost nothing out of the box you are in a catch-22.

Adam Stoller

The problem is that providing such a solution out of the box might not work for *all* customers. I agree it would be nice to see a bit more of this kind of stuff bundled with the product, but it's not that hard to implement on-site (spoken like a consultant?).

My customer uses a fairly nice and consistant naming scheme such that the path to a DCR under the data/ directory is the same as the path for the generated content under the root of the workarea (and several other similar places for their implementation) and they use a workflow that prompts for the directory and name of the DCR (verifying that the name neither already exists nor contains "invalid" characters) and then when the workflow generates the page from the DCR it uses the name of the DCR+extension (e.g. ".html").

There's a bit more complexity to their implementation - but the basic idea is to *drive* content creation *through* the workflow, rather than using the workflow after-the-fact. The more control you have in the beginning, the less work you need to do down-the-line to correct things.

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