templating.cfg

Hello,

The company I'm working for supports many sites so templating.cfg is quite large.
Currently, whenever developers create new templates, its only the system admins that can update templating.cfg to make the templates available - they do this manually.

To reduce the risk of them corrupting another area within templating.cfg, I thought it would be a good idea to investigate splitting up templating.cfg so that each site's templates reside in a separate XML file, that templating.cfg pulls in.

When looking into this, I found that templating.cfg referred to a DTD that did not appear to exist on the server.

e.g.
<!DOCTYPE templating SYSTEM "templating5.0.dtd>

This dtd does not exist - however, templating6.0.dtd does! I'm suprised that teamsite doesn't fall over when I select "New Form Entry".

Any ideas?

btw, I think I have been able to split up the templating.cfg by declaring the xml fragments as external entities like so:

<!DOCTYPE templating [

<!ENTITY site1_templates SYSTEM "/path/to/site1/template.xml">
<!ENTITY site2_templates SYSTEM "/path/to/site2/template.xml">
<!ENTITY site3_templates SYSTEM "/path/to/site3/template.xml">

... rest of dtd declaration here ...

]>

<templating>
&site1_templates;
&site2_templates;
&site3_templates;
</templating>

I've yet to test this on the Teamsite server, but if I load this into a browser it works.

Find more posts tagged with

Comments

Frederik

that's an interesting idea... do let us know if it works ;-)

HOWEVER, in my experience (and I last tested this in 5.5.2 - mmm, and maybe even in 6.5), you have to be careful with duplicate NAMES for categories or datatypes). Because you can only have one occurrence per category and category/datatype in templating.cfg. If there are multiple, only the first (or last?) will be seen, the other ignored...

That means that if multiple sites have same names, you can't break down your templating.cfg that easily.

HideHeader_1.rptdesign

Millie

I think the current set up is that the names are unique.
BTW I'm running on TS 6.5 on Windows (2000 and something).

I should be able to test this tomorrow morning.

The other reason for doing this is that changed templates are currently deployed on to the teamsite servers using scripts (allegedly - I suspect that the sysadmins do it by hand, because sometimes the scripts mysteriously fail .... hmmm), however templating.cfg if hacked by hand.

Our templates are version controlled in a repository, templating.cfg isn't.

Ideally, what I'd like to be able to do is create a "package" of changed files for a piece of work (that might include new datacapture and presentation templates, as well as changes to templating.cfg) and use Teamsite to *deploy-to-itself*!

So, here's the theory: after a package is built, it is deployed from our Dev Teamsite server onto our UAT teamsite server (using dev's opendeploy). After UAT, UAT's opendeploy deploys the *same* package onto the production teamsite server.

Developers use a special workflow on DEV Teamsite to deploy to UAT Teamsite. Analysts use a special workflow on UAT Teamsite to deploy to LIVE Teamsite.

There 's something quite elegant about this!

HideHeader_1.rptdesign

ccprofessional

Our templates are version controlled in a repository, templating.cfg isn't.

What you are doing sounds dangerous to me. No backup/versioning of templating.cfg?

You can create a config branch within Teamsite that stores and versions all your configs.. just an idea.

Even if your current splitting-templating idea works, can you imagine having some conflict between any two includes and having to debug?!
I would just make sure it's versioned and the admins can do what they want. If they mess up, just go to the older version and attempt the new changes again.

keep it simple

gzevin

so, did it work?

I will not be commenting on HOW templating.cfg is parsed, just am curious to get your answer.

Millie

I like the idea about creating a branch for the configs - I might just give that more thought - and ask the admins why they haven't done this (I like asking awkward questions of the so-called-experts).
Currently, the only versioning that appears to happen for the config files is good old copy-and-paste-rename (yep, that bad)!

I tested splitting templating.cfg into separate files and it works! Cool (in a geeky kind of way).

The teamsite templates are version controlled using an external tool. The plan is to version control the fragments of templating.cfg (each fragment representing the template available for each site) using the same tool.

Yes, there will be issues regarding the templates defined in 1 fragment possibly conflicting with templates defined in another fragment - but that problem exists now - all I've done is chop up 1 huge (over 5000 lines long - because of very poor regexps!) into smaller parts. Any changes to the fragments will always be tested on 2 Teamsite environments before going onto the production environment anyway - one would hope that any problems would be caught there!

In addition, whilst my team supports the vast majority of the sites, other teams support other sites. This way, the other teams can make changes to just their fragments without theoretically **** up the templates that we support - they only get to see their fragment.

Frederik

Congrats ;-) btw, did you try the same decomposition on submit.cfg & available_templates.cfg?

Screenshot-11.png

Millie

Not yet, though I am planning to give it a go with available_templates.cfg. It should work - its just a question of defining external entities and assuming that the XML parser they are using behaves by expaning the entities when the document is parsed.

Hence, any XML config file could be split up to make it more manageable.

I wonder whether interwoven have an opinion on this - something that should/not be done?

patrickm

Yes I agree, lets not forget about available_templates for workflow. That is another file which can grow and don't even get me started on datacapture.cfg for metadata. Now I have heard that (1) a future version of TeamSite may come with an admin store, like LiveSite, where all of these files can be managed, version controlled and deployed. (2) There may be a new metadata engine similar to forms publisher, so separation might be supported. Considering this, we can only hope to see further improvements to these core TeamSite config files. Great to read that your entity include works though!