Preparing for XML. Living with modules

he closer you stick to the above guidelines, the easier it will be for you---as well as for anyone else---to maintain and update the site. There are no exceptions to the disappointing rule stating that on any site, design tends to degrade and lose consistency with time, unless its original designer is kept on staff and daily engaged in tightening up weak junctions and fixing ubiquitous holes.  Modular HTML is one of the best barriers against the creeping design anarchy in frequently updated sites.

In accordance with the goal of separating content and presentation aspects that the modular approach seeks to achieve, a modularized site can be worked with in two distinct modes.  In the "content mode," you can edit and update the site's text part, while its modules are left intact or are copied over as new content is added.  This job requires no design skills and can be easily performed by anyone, provided that the designer has pointed out the do's and dont's of this process to the person responsible for the content of the site.  It is especially worth noting that no WYSIWYG HTML editors can be safely used to update a modular site, as they are notorious for breaking the internal structure of HTML and adding their own stuff to the code (Macromedia's Dreamweaver is a notable exception).

Needless to say, before getting to work on marking up the main bulk of the site's content, the designer should make sure that the modules he's developed are well tested and flexible enough to accommodate a fairly diverse content.  However, it is likely that some of the problems with modules will come up only halfway through site redesign, or even after the new design has been up for some time.  For example, you might discover that your heading module behaves erratically when the text of the heading exceeds some specific length.  Editing the site in "presentation mode" is to be undertaken only by the designer himself, or under his direct supervision, and certain rules should be observed when doing this.

The most important taboo of the modular technology forbids you to ever change any single copy of a module manually in your HTML editor.  Even if the modified module renders the same in the browser, but contains some seemingly unimportant deviations such as extra spaces or line breaks, this may prevent the module from being automatically recognized and updated in the next round of global search-and-replace.  Since HTML does not allow you to store "master copies" of all modules in style files, you have to copy them over and over again---and therefore, you can only edit all copies of your modules throughout the site simultaneously.

One difficulty you are likely to encounter is that modules are usually several lines long, while common text editors, even if they can search and replace in multiple files, limit you to one-line patterns. One of the tools offering multi-line as well as multi-file search-and-replace is Allaire HomeSite, a popular HTML editing package.  HomeSite also provides the important feature of regular expression search which allows you to account for the insertion of variable text or tags within the modules.  Another option in this situation could be to compose simple awk or perl scripts to effect global changes in all HTML files of the site.

There are other tools intended to facilitate working with modules. You can use Server Side Includes (SSI) #include declarations to instruct your Web server to insert modules stored in separate files before sending out the HTML files to the users. This may sound like a good solution, but one disadvantage is that you need to actually upload your files to an SSI-enabled server to see how they work with all the modules in their places. (Also, several SSI instructions in each document would take up a lot of server resources to process.) Macromedia's Dreamweaver can store pieces of code in its "libraries," but this feature lacks support for variable content. For example, in order to imitate a heading module like that in my example, you will need to create two separate library items, one for the part of the code before the text and another for the closing sequence of tags.