With this chapter subsection on "Modules," we have arrived in our top-down tour of the hierarchically arranged objects that make up our website (again, from outermost Sitemap, down to atomic Element) at what is probably the best understood, most intuitive building block of the entire structure. Arguably, each of the objects we have been reviewing has served as a "building block" in its turn (Site Sections make up a Sitemap; Pages make up Site Sections; etc.), but it is with the Module, or "page component," or "fragment," that most site visitors—and site developers—best grasp the obvious relationship of the component parts (Modules) to the whole (Page). This is most likely because the "whole" with which we spend most time is the Page, and so to consider its decomposition into Modules comes most naturally to us.
Basic Unit for Content . A key concept concerning the Module is that it is the container for the unit of content that by definition is all "of a piece," that is a "whole," that is stored entire in a single location (file, or database record). Contrast this with its parent the Page, which of course can be made up of many Modules concerning a variety of information topics; or, contrast it with its child the Element, which by definition is but "a piece" of a larger whole, and cannot stand (or be stored) on its own.
It is in fact the container "unit" at this level, the Module, that gets processed from source content XML (raw "Tree") into a page component of finished HTML (presentable "Rectangle"). To be explicit: at the Page level we simply assemble processed Modules; we do not process from source XML to finished product HTML at the Page level.
Zones. The previous chapter subsection ("Site Pages") treated the placement of whole Modules into "Zones" on the Page Layout. Therefore, our concern with Modules here is less with "where they go" in their container (that's been covered), and instead more with "where does what they contain go." What Modules contain are Elements (the next "object" in the hierarachical descent of our "tour"). Where they go is into particular Zones within the Module's own (smaller-scale) "Layout."
Like Page Layouts, Module Layouts too have "Zones" which conceptually are rectangles, and in code are implemented as table data cells <td>s and <div>s. A key distinction is that at the Module level these Zones (rectangles) do not nest. Each Zone inside a Module is a container that directly holds Place-able Elements, and never holds another "Zone" (whereas at the Page Layout level a Zone may directly contain Modules, or it may contain other, nested Zones).
A second key distinction (from Page Layouts) is that the content for many Modules will be contained in the very straightforward Module Type called 'mt01.' This is simply a single rectangle (pictured below). You could say it represents "one column, by one row." (This is to be contrasted with the highly unlikely case of a Page Layout ever being made up of but a single rectangle. A single rectangle for the "body content" part possibly, yes, but not for a page entire.)
And so, with the establishment of Elements, and of the Zones into which they are placed, it remains to make (and record somewhere) the association between them—the "Assignment." This is just what the "EZA" Recipe (Element-Zone Assignment) does. But before we discuss and describe that mechanism (documented further below), we here will discuss and describe the nature of the Module "Types" that implement the various possibilities in Module Zone design.
Module Layout "Types". The variety of Module Types, as seen in the figure below, covers the logical extent of possible permutations in the arrangement of rectangles (module "zones") inside the overall rectangle for the Module container.
As can be seen, with the exception of the default "mainstay" 'mt01', these permutations have everything to do with the need to support multiple columns. The reason for this basic distinction is fairly straightforward. The overarching principle in web page presentation of nested rectangles is that, in the end—in the innermost nested rectangle—the blocks of actual content will follow a "flow" that could be described simply as "straight down." It behaves like gravity. Block upon block of marked up content will simply stack up, within a given rectangle. It requires other, specialized positional markup (e.g. <table><tr><td> constructs, (or, the more advanced use of CSS Positioning)), to get these blocks of content to appear adjacent to one another ("across" horizontally, as in multi-columns, vs. simply "vertically" straight down, as in a single column). The Module Types (seen below) are used to create the necessary <table> constructs to achieve this.
XSLT. Final note: interestingly, the implementation of these <table> constructs occurs not in a "Module Layout" file per se (akin to a "Page Layout"), but instead in the processing code found in the 'mt' series of the XSLT stylesheets: /mlnmdev/xslt/mt*.xslt. These are the transformation sheets used on the second "hop" (transformation), going from the StructureML (Markup Language) to the StructureLayoutML. These XSLTs simply put the "Place-able Elements"—which are at this point no longer marked up in BusinessML but have been transformed (1st "hop") into the "ca. 1994 HTML" that is StructureML—into the appropriate <td> cells in the overall Module rectangle. These XSLTs do not alter in any way the markup of the Elements; they simply move the Elements to the right table cell (according to the "recipe" in the "EZA" file).
Figure 3.33. Module Types, Columns
Module Types, Columns: mt01, mt2col_top, mt2col_bot, etc.
This figure shows the variety of layout permutations possible within the Module rectangle. In essence, these consist of varying numbers of columns, and columns "spanned" (colspan) on top or bottom or both.
The naming convention for these types is fairly self-descriptive: mt3col_top signifies the Module Type for a 3-column module with a span across its top.
![[Note]](images/note.png) | Note |
|---|---|
mt01 and "Stacked Rows". The "grayed" area in the top row shows three rectangles that are mere variations on the 'mt01' Module Type—which is the basic Type of "one row, one column," or what amounts to really nothing more than just a single rectangle. These grayed-back examples are actually stacked rows, which in all cases can be simply reduced to stacked Place-able Elements in a single column. This further demonstrates the principle that it is only when there is a need for multiple columns, or a colspan, that a Module Type other than 'mt01' is called for. | |
| Note |
|---|---|
Four Column Variations. The grayed area in the bottom row shows four rectangles that are example variations on the 'mt4col_topbot' Module Type—"four columns, with a colspan on both top and bottom." As can be seen, a good deal of variety in visual layout can be expressed within the basic "vocabulary" of columns and colspans. The corollary to this would be that you can see how upon careful analysis of an apparently very complex Module Layout, you can "reduce" it down to one or another of these basic Module Types, as seen in this figure. No matter how complex, they will "boil down" to one or another of these Types. | |
Cohesive Unit of Content. To reiterate here at the close of this section what was stated at its outset: keep in mind that within the overall rectangle of a Module all content inside it is coming from a single content source, a single "BusinessML" file ("module"). These Module Type layouts are not to be confused with the kind of use a Page Layout is put to: housing different component parts that come from differing sources. No, here at this level we are working with a perhaps sometimes complex presentation (multi-columnar, spanned, etc.), but always for a single source of information, of content.