Combined Layout Template Building Block

The Dreamweaver Region Selection Parameter Schema allows SDL Tridion template designers the ability to put the component visualization and page layout in a single Template Building Block (TBB).

The following isn't your typical* setup and follows a variation on the SDL Live Content topic titled "Designing Component visualization separately." (Valid login required, see topic under  > Implementing Content Manager > Templating > Creating an Adobe Dreamweaver Template > Designing Components > Designing Component visualization separately)

Update: *After surveying a few Tridion consultants, I doubt anyone actually does this. Feel free to see if this has applicability in your projects but in case anyone asks about that documentation, feel free to point them here for an example.

Create a Page DWT

Design the html markup for your page or see the video.

Add Page Information

Use ${Page.Title} or ${Page.Name} in place of the page's main heading (typically within the first <h1>). In practice you may need more than this basic field. Read a brief walkthrough on making assemblies or learn more on the template package from a post by "String Writer."

Create a new Template Building Block (TBB), optionally by uploading it.
Add the "Dreamweaver Region Selection Parameter Schema."
Replace the <h1> header text with ${Page.Title} in the Source tab. 

In the Template Builder, add the new TBB layout to a Compound Page Template along with the Default Finish Actions to show the heading pulled from a page.

"Home Page" in this example comes from the selected page.
It literally takes moments to start pulling data (content) from SDL Tridion.

If you also add a typical repeat region named "Components" the DWT will
render both page layout and selected component presentation.
In this example, the "tcm:7-65" is added by the specific template chosen
for this component presentation on this page.

Add Component Visualization

The following part is an unconventional, but elegant departure from a typical DWT setup.

Adding fields is easy. Selecting the repeating regions is slightly more challenging. 

Within a separate Compound Component Template, add the same "all-in-one" DWT layout TBB and match the Dreamweaver Region Selection Parameter setting to a TemplateBeginRepeat region that wraps where you want your component presentations (code follows!).

To pull the content name as a header, add ${Component.Name}. For the "guts" of the component presentation, we can use the Field Path variable which always knows it's current (XPath) location.

The "Repeating region to render" parameter will make the DWT TBB only display the templating markup and logic within that region. This gives us the option to combine DWT page and component visualization into a single TBB.

See the following Dreamweaver templating (DWT) snippet. Notice that it pulls both page and component information ("Name" for both). The TemplateBeginRepeat section does the component visualization within a component template and the RenderComponentPresentation() does the visualization in a page context.
<div id="header">

  <div id="logo">
   <h1><a href="#">${Page.Name}</a></h1><!-- ${Page.Title} also works -->
   <p> design by <a href="http://www.freecsstemplates.org/">Free CSS Templates</a></p>
  </div>
 </div>
 <!-- end #header -->
 <div id="page">
 <div id="page-bgtop">
 <div id="page-bgbtm">
  <div id="content">

<!-- TemplateBeginRepeat name="Orange Body" -->
   <div class="post">
    <h2 class="title"><a href="#">${Component.Name}</a></h2>
    <p class="meta"><span class="date">January 15, 2012</span><span class="posted">Posted by <a href="#">Someone</a></span></p>
    <div style="clear: both;">&nbsp;</div>
    <div class="entry">
     
<!-- see http://code.google.com/p/tridion-practice/wiki/IteratingOverMultivalueEmbeddedFields -->
<!-- TemplateBeginRepeat name="Component.Fields" -->
  @@Field.Name@@
  <!-- TemplateBeginRepeat name="Field.Values" -->
    <!-- TemplateBeginIf cond="Field.ContentType = 'text/plain'" -->      
    @@RenderComponentField(FieldPath, TemplateRepeatIndex)@@
    <!-- TemplateEndIf -->
    <!-- TemplateBeginIf cond="Field.ContentType = 'tridion/field'" -->
      <!-- TemplateBeginRepeat name="Field.Fields" -->
        @@Field.Name@@
        <!-- TemplateBeginRepeat name="Field.Values" -->
          @@RenderComponentField(FieldPath, TemplateRepeatIndex)@@        
        <!-- TemplateEndRepeat -->
      <!-- TemplateEndRepeat -->
    <!-- TemplateEndIf -->
  <!-- TemplateEndRepeat -->
<!-- TemplateEndRepeat -->

<p class="links"><a href="#">Read More</a>  |  <a href="#">Comments</a></p>
 </div>
</div>

<!-- TemplateEndRepeat -->
<!-- a RenderComponentPresentation is needed for the page -->
<!-- TemplateBeginRepeat name="Components" -->
 ${RenderComponentPresentation()} 
<!-- TemplateEndRepeat -->

Thank the helpful chefs at the Tridion Cookbook for the sample iterating DWT snippet. Adapt as needed or use your existing component DWT logic.

The Template Begin Repeat region with name="Components" is needed to show the component presentations on the page. It just so happens in this case, when you select the right template, a TBB renders the page's layout, and when RenderComponentPresentation is called, the same TBB renders that part (don't forget to allow the right schemas and actually select the component template for a component presentation on a page).

Create and run a separate compound component template, matching
the repeating region. Add the same DWT TBB to see it only render
the parts you marked with the same-named region. 

At this point there's not much to gain from combining the two except for possibly making it easier to develop the layout together since it's more WYSIWYG on both the HTML and visual sides. You've also saved a TBB; but possibly at the cost of confusing anyone who's looking for a separate layout TBBs for component and page templates.

Re-Use

You can optionally add multiple template repeating areas, checking for schema or template (again, through the region selection parameter) so that different templates will place content in the correct area.

For example you may have three templates:

• Orange Main
• Orange Footer
• Orange Right Rail

Each region will have something like:

<!-- TemplateBeginRepeat name="Components" -->
 <!-- TemplateBeginIf cond="ComponentTemplate.Name =  'Orange Main'" -->
  ${RenderComponentPresentation()}
 <!-- TemplateEndIf -->
<!-- TemplateEndRepeat -->

You could put the individual component visualizations next to the above RenderComponentPresentation calls, or group them at the bottom, again structurally similar to an XSLT template. Up to you.

Each of these "place holder" templates will use the same template building block, with the only difference being a different parameter setting. Your visualization for page and component will be more closely tied.

The individual visualizations will be the same as above.

<!-- TemplateBeginRepeat name="Orange Main" -->
 <!-- DWT layout for this component template -->
<!-- TemplateEndRepeat --><!-- Orange Main -->

Trade-offs

At the cost of the mental leap to realize the layouts are combined, this creates the following benefits.

Might be a good way to change XSLT CTs into a DWT equivalent. Probably not as powerful, but the structure may be familiar:

•  DWT layout is like XSLT’s template match on "/"
•  RenderComponentPresentation is like an xsl:apply- or call-template 
•  Each TemplateBeginRepeat is like an individual <xsl:template>... sort of.

This could also be useful for homepages, landing pages, or anywhere you’d want control over how schema or templates render with a specific page layout. Think "these component templates go with this page." Consider setting up folders, a naming convention, and permissions so that author X can see page template Y with component templates Y - Main, Y - Side, etc.

Apparently, we can also set DWT as a page template option in Tridion.ContentManager.config.

The best part might be a better WYSIWYG preview (especially if not using a dynamic framework like CWA or DD4T, which offers easy ways of near-perfect previews).

Major draw-back: the model is elegant, but probably not seen in typical setups. The power of modular templating gives strong .NET programmers a quick-and-easy way to handle markup in assembly or C# fragments and I suspect there are several XML, HTML, XHTML, or even XSLT being generated on the code side, rather than created with a layout TBB. This can work, but at the cost of maintainability and a ding to the separation of concerns. Your designers may not actually do DWT development, but it doesn't mean your programmers need to handle all the markup.

Thoughts? Yea or nea on the all-in-one DWT? The computer scientist left in me loves the concept, while the pragmatic implementer has struggled even pitching DWT to devs who hated XSLT.

Update 4-April, 2012:
Mr. (Frank) P. shared the sample config change mentioned above. I'm interested on who this has worked for, let me know if you've seen DWT-as-PT or DWT-as-CT "in the wild."

      <add id="7" name="DreamweaverTemplate" titleResource="lblDreamweaverTemplate" mimeType="text/x-tcm-dreamweaver" hasBinaryContent="false" contentHandler="Tridion.ContentManager.Templating.Dreamweaver.DreamweaverContentHandler, Tridion.ContentManager.Templating, Version=6.1.0.0996, Culture=neutral, PublicKeyToken=360aac4d3354074b">
        <webDavFileExtensions>
          <add itemType="TemplateBuildingBlock" fileExtension="dwt" />
        </webDavFileExtensions>
      </add>