Intro to Templates
One solution to this problem is to use something called
server-side include files (SSI). SSI is a process,
supported by many web servers such as Apache, by which you
can specify a common bit of HTML in one file and then
refer to it from another file. So, in our Wizard's Widgets
example, you might put the HTML for the menu in a separate
file called menu.html:
You could then include the menu.html file in your index.html, as follows
The ordering.html and contact.html pages can also use this technique to include the menu, so the HTML for the menu appears in just one place --- in the file menu.html. When you need to make a change to the menu, you simply change menu.html, and the change will show up whenever any of the three pages is viewed, because the server substitutes the contents of menu.html into each of those file each time they are requrested.
Putting the menu code in its own file is an improvement, but there is still, however, a lot of duplicated HTML in your three HTML files. In particular the table that defines the overall layout of the page is the same in each of them. In fact, everything except for the main body text and the page heading text is identical. If you wanted to change the page layout, or anything else on the page other than the main body text, you would end up editing identical HTML in multiple places.
To remedy this you could use SSI files for all of the common HTML --- not just the menu itself --- breaking the common HTML up into chunks that you can include in the right places in each file. In our example there are two pieces of HTML that vary from page to page: the page "body" and the page "heading" text. So you could put the rest of the HTML into 3 separate files that look like this:
Then you could write index.html as
contact.html and ordering.html would be analogous to this. This way each file contains content that is more or less unique to that file, and each common bit of HTML is contained elsewhere, in just one place. So now, if you want to change the general layout of the page, you edit the files header1.html, header2.html, and/or tailer.html.
This technique still has its drawbacks, however. In particular with this arrangement it is difficult to get a single view of the HTML that specifies the overall page layout, because it is spread across the three files header1.html, header2.html and tailer.html. If you change the page layout you may have to edit all three of these files. This problem gets even more complicated if your page layout is more complicated; many situations require more than three separate files to store the common bits of an HTML page layout. Trying to keep track of an overall page layout that is spread across many files is very difficult and error-prone.
Another disadvantage of this method is that it can be difficult, or impossible, to edit the HTML files with a WYSIWYG HTML editor. It's often convenient to use a WYSIWYG HTML editor to design and edit HTML pages. Most WYSIWYG HTML editors don't understand the SSI #include directive, so you won't be able to use such an editor to edit a page that contains that directive. You also can't use such an editor to edit a file that contains only a fragment of an HTML table, and you can't preview a fragment of an HTML file in a browser. So if you're using SSI to store your page layout in separate files, then you're probably restricted to only editing your HTML files by hand, and to an awkward process of reviewing any modifications you make to your layout.
This can be especially problematic if you are a programmer creating an interactive web application and you are working with a web designer who is responsible for creating the overall design of your pages. Your job might be to simply fill in certain areas of the page with data specific to your application. The person who is creating the page design might use a WYSIWYG HTML editor to do their job. Of course it would be possible for you to take the results of that person's work and break out the common bits of HTML into separate files, but this can be quite laborious. Furthermore, when a change becomes necessary in the design, the designer will not be able to work with your "broken up" SSI files directly. Most likely he or she will produce new versions of the complete HTML files he or she gave you in the first place, and you'll end up having to repeat the laborious process of splitting the common bits out into SSI files.
Separating the HTML design and creation from the mechanics of replicating a common design across multiple pages, and/or from the process of populating parts of a page with dynamic content, is a good idea even if you're working alone. Conceptually, the presentation of information is distinct from the content of the information itself, and separating presentation from content leads to a smoother and more sustainable development and maintenance process.
So although SSI does give some advantages over using duplicated pieces of HTML, it is less than ideal. What we really need is to be able to separate presentation from content in a way that allows us to work with complete HTML files. This is where templates comes in.