The "tour" is now complete, having visited the lowest level container the Element, after coming all the way down from the overall web site Sitemap. Along the way we have seen several references to this new "mechanism" (EZA) that, for each Content Type, provides a simple way to record the Assignment information about select Elements ("Place-able" ones) as to where (and whether) they will appear in certain locations (Zones (and within Zones, "Positions")) in the presentation of the Module in a "Module Type" (i.e. a module layout).
The sample file below illustrates two concepts for the EZA: the facets of information that come together and are represented in the EZA Recipe filename; and the actual "EZA" information itself: which Elements get Assigned to which Zones (and Positions).
An important idea with the EZA is to be aware that what is being recorded is a particular "recipe," a particular preferred design, for the presentation of the content in a Content Type. From all the Elements found in a given Content Type, you could create more than one combination of presentation choices. This is even more the case when you consider putting the Content Type into some number of possible Module Types (layouts). Finally, even more permutations can be designed by the introduction of Presentation Types. All of these variants call for a naming convention of their own, and the simple (if lengthy) solution used here is to stitch each facet together, separated by hyphens (-), into a unique filename, one per recipe. (Individual facets employ the underscore (_) to separate terms within the facet.)
/mlnmdev/ezaRecipes/eza-ct11_press_release_summary-mt2col_top-pt11-recipe_1.xml
<ezaRecipe>
<filenameFacets>
<contentType>ct11</contentType>
<moduleType>mt2col_top</moduleType>
<presentationType>pt11</presentationType>
<ezaRecipeVersion>1</ezaRecipeVersion>
</filenameFacets>
<elementZoneAssignments>
<eza zone="A" position="1" elementName="date"/>
<eza zone="A" position="2" elementName="header"/>
<eza zone="B" position="1" elementName="subHeader"/>
<eza zone="B" position="2" elementName="mentionedOrgs"/>
<eza zone="C" position="1" elementName="main"/>
</elementZoneAssignments>
</ezaRecipe>
Note that the final '_1' in the filename corresponds to the <ezaRecipeVersion> element. This terse and simple digit is used as the unique descriptor to distinguish among what could be any number of combinations you might devise to place some number of Elements into a particular Module Type. That is, even (from the filename) knowing the Content Type, the Module Type (and even the Presentation Type), you still need one further distinguishing piece of information to ensure you have the correct EZA Recipe intended. In practice, usually only one EZA Recipe is devised for a given Content Type; still, using this "version number" is recommended.
In the code snippet above we saw the Elements (from the Content Type) by name (e.g. date, header, subHeader, etc. Here in the brief snippet below we see the first code that uses the EZA artifact: the 2nd transformation XSLT, the "Module Type." See the sample fuller code walk-through in the next section on the XSLT transformation pipeline, to see how this is taken into the third ML (StructureLayoutML). (Be sure to review also the use of the EZA in the 1st transformation, on that same page.)
/mlnmdev/xsl/mt2col_top.xslt <table border="0" cellpadding="5" cellspacing="5"> <tr> <td colspan="2" valign="top"> <div title="Zone_A_Col_1_2"> <xsl:apply-templates select="//eza[@zone='A'][@position='1']"/> <xsl:apply-templates select="//eza[@zone='A'][@position='2']"/> ...
For a visual depiction of the "before" and "after" concerning the use of the EZA in the 2nd transformation, see these two figures (from the "Markup Languages" page), showing the StructureML with <eza>... and the StructureLayoutML with corresponding <td><div>...
The details of this topic are covered in the "1st transformation" code walkthrough example in the XSLT Pipeline section.
Here we can reiterate what is noted there: these two special presentation mechanisms are only used when you want elements to receive a different look + feel handling in the final SiteHTML XSLT (sh01_general.xslt) from the default look + feel. Usually, most of a site's content would have no need for these "presentationStyle" and "presentationType" mechanisms. But when needed, they permit you to de-couple content not only from "default" presentation information for the site, but even from ad hoc presentation requirements. These mechanisms do this by providing a single place to record the "ad hoc" or special case presentation decision, which may then be applied to many instances of content. Any later decisions to alter that presentation information is thereby made trivial instead of complex.