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)
Realigning DCRs and Templates?
ThrogMI
We've just upgraded to TeamSite 6.0 and one thing our users don't like is how complicated the new forms look. Essentially, our templates have six or seven nested levels and so when the related form appears we end up with six or seven nested boxes, which does strange things to your eyes.
Luckily, a number of these levels are now redundant so in theory we could remove them. However, A quick test has shown that this "breaks" existing DCRs as effectively we've restructured the DCT. This is a big problem because we have a lot of content in our implementation.
What is the best method of realigning the DCRs with the new DCT? In theory I can write a Java console app to rewrite the XML inside each DCR and then reassociate the new DCR file with the DCT by setting extended attributes, but that seems like a complicated solution. Are there any out-of-the-box solutions for this?
As an aside - I'm a Java developer with a dislike of Perl, so ideally I'd like to do this without having to get too bogged down in a Perl solution!
Find more posts tagged with
Comments
gzevin
unfortunately, one has to rebuild DCRs to the new look. What I'd do - is to write a script (yes, in Perl - as the best API IMHO still is in Perl - say, DCR::Node), that will read the old DCR and write off a new one in its place. Thus, you will even retain the EAs.
In order to get an idea on how the new DCR will look like, you mighyt want to create a sample one using the new DCT and then use it in your script to produce a target DCR.
Then - just rin a find comand with exec option on the templatedata directory
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
JonathonG
In the past, I have used XSLT and some sort of XSLT engine to convert DCRs from an old format to the new desired format. If you're comfortable with XSL, then this can be a fairly painless way of handling this.
Jonathon
Independent Interwoven Contractor
gzevin
well, XSLT is a go too, however it's too generic IMHO... But if one isn't compfortable with perl and is on better terms with XSLT, why not ?
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
JonathonG
I'm not sure I understand what you mean by "too generic"...could you elaborate?
Thanks,
Jonathon
Independent Interwoven Contractor
Johnny
XSLT is very good for transforming DCR's from one format to another.
It is probably alot more maintainable than a coded solution if one ever needs to go through a few iterations. That might make it worth learning.
That being said, at the end of the day, whatever it is that you are comfortable with is what you should use.
John Cuiuli
gzevin
what I mean was that XSLT deals with *any* XML, whereas the API provides you with an easy interface to DCR's XML.
However, as John said, you could still use XSLT if you wish and prefer to do so.
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU