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; } } }

TPL Vs. XSLT

rpatiban

I am looking for the following info.

I wonder if anybody is using XSLT instead of TPLs.
And I wonder if somebody already evaludated TPL Vs. XSLT and have the details
Also, what are advantages using tpls over using XSLTs?

I appreciate any info. in this regard.

Thanks

Raghu

Find more posts tagged with

Comments

gzevin

I am using XSLT along with TPL, for the purpose of injection of metadata, etc.

As for the generic usage of XSLTs - if IWOV has provided some similar functionality for XSLT, as they do for TPL (in terms of API), it would have some future.

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

Mr_Cruise

I have worked with TeamSite for over five years now and recently we have used XSLT and no TPLs. We have taken this approach because we are using Cocoon on the front end to deliver/transform the content. If you were starting a fresh TeamSite set-up then I would recommend XSLT if you have the appropriate skills and time. Even if your delivery mechanism (which serves up the pages) is not using XLST at least when you do migrate to use XSLT on your front end, you will be prepared. If you use XSLT you are not so tied to TeamSite/Interwoven.

Johnny

XSLT is great for simple transformations - IE simply substituting values straight from the DCR.

As soon as you run into logic situations that require a more in depth programatic approach - TPL's become much easier to use as you can factor all your logic into a PERL block.

John Cuiuli

rpatiban

Thanks much for the responses.

Here is our situation:
Our client is using TeamSite for 2+ years. It has been never given a thought to use XSLT. The client's web environment is Microsoft technologies (Windows 2003 and .net (C#, ASP.net et.,). Recently the idea of replacing TPLs with XSLT came up. That is why I am trying to gather the info.

My understanding using XSLT
- will reduce the dependency the Interwoven Technology and we may apply the Enterprise standards as well.
- .Net Resources don't have to learn new technology to build the presentation layer.
- Changes in the presentation layer could be done by .Net developer who knows XSLT. Don't have to wait on an Interwoven resource who knows tpls.
- It is better to generate DCRs in general XML format.

Questions:
- How does the preview work with XSLT?
- As John already raised, including custom perl script could become complex task. I am not XSLT expert, but my guess would be that , it should be possible and even easy with XSLT and scripts available for that. Also, I am guessing all the dynamic scripting (database querying and other dynamic stuff ) would be do-able with ease.
- Would there be any (backward) compatibility issues?

I am not sure if I am missing any other things to consider. I appreciate all the inputs.

Raghu

rpatiban

Hi Greg,

What kind of functionality are you talking about? Is that about previewing? or anything else I am missing?

Because all the things we are doing to get the content from DCRs, I think we can do that using XSLT in much easier way, if we keep our DCRs in general xml format. what do you think?

- Raghu

gzevin

I was talking about using XSLT to parse and render metadata that is attached to the asse and inject it into the .htm or .jsp, .asp, etc file.

I will second John on the fact that IWOV's templating API is far more programmer-friendly than one of XSLT.

However, as it was also metioned before, if one starts with TeamSite 6.X and non-IWOV style DCRs, XSLT might be a good start

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

awizardly

Just be aware that XSLT has its own limitations.
Date Manipulation is horrible in XSLT as well as string manipulation and formatting is a pain, generally requiring thay you write your own tag calls in whatever language you prefer.
In order to get any realistic virtualization in the iwov interface you will probably have to integrate a transform servlet/asp/cgi into IWOV to allow the user to actually see the results of his changes.
XSLT is extremely DOM heavy, which is good and bad. Strict enforcement of tags, but then you can't do things like open ended <br>'s any more.

Benefits of Formspublisher API's
iw_ostream (Ability to output multiple files from a single generation)
Access to shell out to call scripts or CLT's
Perl 'nuff said.
Access to perl lets you do things like manipulate files and directories or in fact do pretty much anything.

In the end you may find a combination of both would be useful, just remember each tool has its own place.

Johnny

I agree regarding the pro's and con's of both tools.

I still think that templating needs to be more tightly integrated to the teamsite file system.

Because templating is executed over the IFS (and the IFS does not hold any locking information), it is possible to overwrite a file that could be locked or in another process.

John Cuiuli