5

I'm moving a tridion site from asp.net to java and I am wondering about how to handle the taglib declaration for tridion tags (ComponentLink, ComponentPresentation, etc.) at the top of the page. It seems from my research that it's generally put in the page or component template. This seems odd to me. I thought one of the benefits of tcdl tags being converted to a specific language during deployment was to keep the Content Management environment language agnostic. If I have to hard code the taglib declaration into the template I am no longer language agnostic... Granted you have to specify the page extension (jsp, aspx) in the CMS but it still seems counter intuitive. Is there an out of the box option for this that I'm missing or would I need to consider a deployer extension to inject the declarations in the page during deployment?

Improve this question

2 Answers 2

Reset to default
4

As far as I have seen, most people place the snippet at the top of the Page Layouts. I understand the point you are making by not embedding the taglib - but out of the box this functionality doesn't exist. I would actually suggest writing a 'language agnostic' TBB that either checks the extension of the page being published, or the output type of the publication target and based on that injects the respective string.

So the TBB would run (after the DWT) and see that our page is a jsp page (as an example), and then find the head of the document through a regular expression and inject the following.

<%@ taglib uri="cd_tags" prefix="tridion" %>

Update: A way to write the TBB being consistent with the OOTB TBBs (such as the Link Resolver) would be to define a custom TCDL tag, such as:

<tcdl:PageDeclaration />

and use a regular expression to parse your page's output for your custom tag, and have it swap the tag with the appropriate string. It would give you a bit more control around placement of the tag.

Improve this answer
2
  • Yeah that was the other method I was considering. I thought the deployer to try to keep that language separation between delivery and CM, but the template building block would seem to be a simpler solution.
    – Nate Niemi
    Commented Apr 16, 2014 at 18:47
  • +1 for keeping this managed independently even if still outputted by page templates. We see the same approach for other content (page meta) or functionality that's added by templates, without being hard-coded in the template's layout.
    – Alvin Reyes
    Commented Apr 16, 2014 at 18:58
2

The likelihood of there being much benefit to be had from language-agnostic templates is almost certainly small. Most people would be OK with accepting some amount of language-specific things in their templates. So even if you can manage to achieve this technically (I'm sure you can.), it's probably still more effort than dropping these declarations into the page template, and fixing it up again on some putative future occasion when you change technologies again. Even then - when you change technologies again - you'll almost certainly change some other aspects of your design, so you'll be updating your code anyway, and you'll have a project with a budget.

Improve this answer
1
  • Yeah fair point. I think keeping the language specific stuff well organized and easy to update on the CM side is more important than trying to eliminate it all together.
    – Nate Niemi
    Commented Apr 21, 2014 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.