2

Using multiple layout TBBs in a modular template makes multiple Output items in the Package, which I understand act as a stack of text/html items named Output.

Is it a bad idea to use this modular templating feature to manage various presentations for a given modular template? I suspect the TBB that chooses which Output to keep would be rather "hackish."

In other words, is there a way to choose a layout TBB at publish time?

Alternatively, using a single layout TBB, we can use conditional logic to show/hide certain markup.

<!-- TemplateBeginIf cond="somecondition" -->
Do something...
<!-- TemplateEndIf -->

The use case would be minimizing localization of templates across websites, devices, or other channels. We do this easily with fields saved in config components or publication metadata--I'm trying to find the equivalent for markup managed in the CMS (edit: without localizing templates to be clear).

5

The only time I used stacked DWT TBBs in a compound template was when I needed to iterate over nested lists.

I would use 2 DWT TBBs:

  • the first one would only contain the markup for the 'inner' loop;
  • the second for the actual output;

There would be a C# TBB in-between the DWTs that processes the first DWT (the inner loop markup) and prepares some variables in the package. The second DWT would then execute and it would include the results prepared by the C# TBB.

Using a similar approach, one could choose which DWT to include in the final output. However, note that all DWTs will be executed, potentially resulting in a performance hit.

There is no way to include a DWT inside another DWT (at least not by using OOTB DWT TBB syntax).

Regarding minimizing template localisation -- I don't think I would ever localize templates. Instead, I would probably:

  • parameterise the TBBs (including DWT TBBs) such that I could reuse them in different contexts by simply changing a parameter/metadata;
  • implement Content Delivery logic to change the generated markup (coming from the same TBB) on the Presentation server based on the targeted channel, device, media...;
  • Cool. I can see how the string array package feature can help with a 2 DWT approach. For "nested" DWTs inside each other, we could configure DWT as a template itself, though I haven't heard many that do. Good point on CM performance--I'm thinking delivery will be big in the "omnichannel" contextual future. ;-) – Alvin Reyes Dec 4 '13 at 4:39
  • Indeed - it's possible, and I know people who use intermediate TBBs to copy Output to another variable. Still - having to do so is a bad smell. If you're in this kind of trouble, you should probably be rethinking your design (including your choice of mediator) – Dominic Cronin Dec 4 '13 at 6:53
  • Is it the dependency on the extra layout TBB or maybe on order that stands out to you, Dom? – Alvin Reyes Dec 5 '13 at 3:41
1

It is sometimes appropriate to have multiple Output items in the package. For instance, Outbound E-mail does this when sending Mailings. The first Output contains the plain-text variation and the second contains the HTML variation. The two are then combined into one depending on the Contact's preferences (plain-text only, HTML only, or multi-part which contains both versions). It's always the last Output item in the package that will be used, by the way.

I would generally discourage the use unless you actually have two representations of the output, as mentioned above.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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