Extensibility | XSLT inclusion

Last week we had a session with Bart who did a great job explaining SDL Tridion in the way implementers see it.

However, this meeting left me with a feeling that XSLT is one of the misused and misunderstood tools which is not popular with developers or implementers. Probably because it requires a bit more knowledge to be applied successfully.

CME supports XSLT extensibility and the mechanism itself is relatively simple. It allows you to include your own XSL transformations at the top or at the bottom of extending XSLT file.

Let`s create a simple extension to see it in action.

Some of you probably use double `minus` character instead of `dashes` creating some texts. Let`s add a format area extension which will convert `–` to `—` when you switch from source tab to design or preview tabs.

First you have to create a transformation itself, which is relatively simple for our scenario:

Then you have to configure xslstylesheetextensions section in your editor extension:

Now you have to increase a modification value in system.config, and restart IIS.

Finally, open a component with FormatArea and paste the following text into Source Tab:

 Tridion.UIBeardcore -- blog about Tridion.UI extensibility 

And switch to Design Tab.


3 thoughts on “Extensibility | XSLT inclusion

  1. Alvin Reyes

    Interesting and thanks for sharing.

    So we can configure one (or more?) XSL transformations.

    Would this run in addition to per-field XSLT richtext filters? I’m trying to understand when I’d recommend this approach and how granular would be reasonable (per CMS, per publication, only certain views?).

    Reply
  2. UIBeardcore Post author

    Theoretically it might be applied to:
    - List based view (DrillDown, DropDown, Gallery, List), where XSLT is used to generate list views representation;
    - List filters panels, where XSLT is used to generate panels view representation;
    - Publications filter panel in Tree;
    - List widgets view;
    - Field builder, where XSLT is used to render field representation;
    - Format area. Formatting rules;
    - Formatting-features default XSLT;
    - Views with list movers;
    And some views
    - Publish transaction summary;
    - Keyword select controls;

    And all xslt based transformations in extensions, such as Widgets representations in User Generated Content.

    To be reasonable, I think in most cases you`ll find simpler ways for achieving required functionality. However it might be relatively simple to modify views or extend FormatArea using XSLT extensibility. I can also imagine scenario when you would have to extend component field type representation.

    So far I`ve seen only one example. It was in ECL, when external items have had to behave in the same way as TCM items in Format Area.

    Reply
    1. Alvin Reyes

      Thanks, Alexander. I’ve shared this with a few colleagues and will keep this in mind in customer design sessions and when questions come up online.

      The ECL example is helpful, I can see how the approach makes sense when we need to transform some small parts of XML consistently and recursively (okay, so it’s not so much an question on GUI extensions, but simply “when does XSLT make sense?”).

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

CAPTCHA image

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>