SDL Tridion XSLT Variables for Linked (Multimedia) Component

While Cleaning My Desktop... Tidbit #1

I share a lot, but surprisingly, I still have too many tidbits and side projects that I'd like to get out to the community. Here's another long-overview due (and marginally relavant) post on XSLT. Dominic Cronin might call these types of blog posts "notes to self" and I've posted about this kind of Secondary Memory.

So here's some starter XSLT variables I've used when transforming source Tridion Component XML and referencing a linked Component. With modular templating you'd normally use something like the Get Extension (DGX) to be able to reference related Components. Otherwise you would add these Components to the package.

But with the older style XSLT templates, or anytime you had access to the content model while using XSLT, we used the document() function against the other component's namespace. This is one of the places where you'd be glad you always gave a Schema a good namespace.

XSLT referencing another Component

<xsl:for-each select="//namespace:link_to_multimediacomponent">
<xsl:variable name="COMP" select="document(@xlink:href)/tcm:Component"/>
<xsl:variable name="DATA" select="$COMP/tcm:Data"/>
<xsl:variable name="CONTENT" select="$DATA/tcm:Content"/>
<xsl:variable name="META" select="$DATA/tcm:Metadata"/>
<xsl:for-each>


You could also use the same approach when referencing the Component that's being rendered by the XSLT template. You can see an example in my "Inspect Component Details" post:

<xsl:variable name="Content" select="/tcm:Component/tcm:Data/tcm:Content" />

You could then reference Xpaths starting from $Content.

<xsl:apply-templates select="$Content/*" />

With a few variables, you've made selecting something as easy as remembering its path based on the source XML. But then this isn't Tridion per se, but just XSLT's variables.

Thanks for letting me reminisce. XSLT + Tridion brings me back to the "old days" on the forum, where I feared the likes of power forum users like +Dominic Cronin or +Jeremy Grand-Scrutton. Maybe Dom will forgive me for referencing W3School. :-P

Min, Max, and Everything in between

You can better understand a content model using two numbers for quantity: minimum and maximum. Data modeling might refer to the cardinal relationships between data tables, but in terms of an enterprise CMS we're mostly interested in how many elements can exist (this content type or text in this location, on this page, etc):

Let's look at:
  • Min
  • Max
I have these in the example "mobile-first" page type breakdown from my last post. But it could also apply to any managed elements such as fields, images, regions, selectable options, or websites (think Tridion BluePrinting).

Modeling Split-Style Labels and Headings

I'm working on a CMS design with text labels that look like:

SPECIAL
DEALS

BUY
NOW

ON-SITE
SPECIALS

PRODUCTS &
SERVICES

Pretty simple, right? How would you model this in Tridion?

Does Experience Manager work with Responsive Web Design?

This question was posed to my team recently: "Do you get a responsive view scaled to your screen in [SDL] Experience Manager?"

My response had three points:

  1. This has more to do with the HTML and styles than Experience Manager (XPM).
  2. XPM only adds borders on the wrapping container element (tag) for the Component Presentation and fields.
  3. As the borders resize and move, the XPM borders should move.
Of course "should" wasn't enough. So let me further qualify the answer to "does XPM work with Responsive Web Design?" with "yes, to the extent that your mark-up keeps the borders and the XPM field comments intact."

Luckily I had an environment to "prove" my point.

My colleagues had already set up this environment, a relative to Electridion Training (not to be confused with the Reference Implementation), based on a Bootstrap responsive template.