3

Tridion's uses as a "technology-neutral" (markup) language to manage Content Delivery features such as:

  • BinaryLink
  • PageLink
  • DynamicComponentLink
  • ComponentPresentation

See Reference for Server Controls Custom Tags and TCDL tags (requires login).

I understand this means we can request DCPs using .NET, Java, or the CD Web service and get things like DCPs and dynamic links correctly resolved at request time.

We've had a few questions and comments related to TCDL with REL (see 1 and 2). I think the general question would be:

Does the syntax or format matter for REL when Content Delivery returns its response? Can REL handle XML (or even text) based DCPs?

I'd guess that over the CD Web Service, the format doesn't matter but .NET requires ASCX and Java needs JSP (as set in a Template's Output Format)?

Improve this question

2 Answers 2

Reset to default
4

I am pretty sure you can publish whatever weird content you like and as long as it contains valid TCDL/REL it will be parsed by Content Delivery before returning it via the ComponentPresentationAssembler or Page equivalent. I think the output format of the dynamic template must still be REL though - its no good setting it to Text or XML, putting some TCDL syntax in there and hoping for the best...

Be careful though, this does not necessarily mean that REL be used in any output format. For example I had the idea to use REL in some JSON DCPs, however this did not work as links are always output as HTML, so I would get a nasty <a href="blah">link</a> in the middle of my JSON.

For this I would have to create my own REL tags which output just the link URL, but even this didn't feel 'right' as the un-processed JSON I was publishing could not be valid JSON, as the REL syntax is XML, so in the middle of my JSON I would have things like <tcdl:UrlOnlyLink ../>... yuk!

Improve this answer
3
  • Did/would you "bake" the change for that setup? So in your templates you would have faked JSON ({}) tcdl references that get published to tags (<>)? I wonder how namespaces would apply.
    – Alvin Reyes
    Commented Jul 31, 2014 at 18:31
  • The published JSON was just invalid JSON, which became valid after the REL/TCDL got resolved on content retrieval
    – Will Price
    Commented Aug 1, 2014 at 7:38
  • Ah, as yucky as invalid XML. :-)
    – Alvin Reyes
    Commented Aug 3, 2014 at 0:33
3

Be careful about using REL when publishing ASCX or Java Taglib markup. REL is meant to be used when storing content in the DB, however ASCX and Taglibs need to be published to the filesystem in order for the application server to execute them. Otherwise your ASCX/Taglib markup will simply be rendered as a non executed string of markup.

Also on the syntax bit, it does matter. I've run into issues where if the the link tcdl tag is rendered with attributes carried over to a new line and indented (for code readability), the REL parser chokes. So make sure the tcdl tags are all on one line with no '\n' characters in between.

Improve this answer
6
  • Thanks, Nick--good point on avoiding REL with .NET or Java. Though I have seen hacks to get past the filesystem restriction (which I won't point out here). :-)
    – Alvin Reyes
    Commented Jul 31, 2014 at 18:24
  • Alvin, it's not about .net or java, rather it's about where you store your Tridion item, DB or filesystem. If your item (page or DCP) is stored and retrieved from the DB, then use REL. If on the filesystem, then make sure to use format of the technology type (aspx, jsp scripting, etc).
    – Nickoli Roussakov
    Commented Jul 31, 2014 at 20:03
  • You can use REL in FS DCPs, and (with a bit of extra work) JSP/ASCX in DB DCPs (see for example: erichuiza.blogspot.nl/2013/07/… and yatb.mitza.net/2012/12/…)
    – Will Price
    Commented Aug 1, 2014 at 7:39
  • Will, are you saying that REL's purpose is not to allow easy dynamic content resolution when storing it the DB?
    – Nickoli Roussakov
    Commented Aug 2, 2014 at 16:11
  • 1
    REL was introduced to enable content retrieved using the oData webservice to have dynamic functionality embedded. A (nice) side effect of this to have dynamic functionality in database stored DCPs even when requesting them in a web app and not via the oData service
    – Will Price
    Commented Aug 4, 2014 at 9:13

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.