A Better Alternative to Dreamweaver Templates
As a web developer and consultant, I am often involved in the upgrade or redesign process of existing web sites. Clients have had a site for a couple of years, and are now ready for something bigger, better or more feature rich. They approach the company I work for (Design IT) for a new web site. Upgrading (or even maintaining) these sites is often not an easy task, especially when they have been built with Dreamweaver and its Templates and Library features.
While in itself these features can be very useful, and allow you to create a consistent looking web site with little work, these features often make it hard to upgrade the web site. In this short article, I show you the common pitfalls with templates and library items, and show you a better alternative. While this article uses ASP for any sample code, the concepts also apply to other programming languages and web servers that support server side includes.
Love 'em or Hate 'em
If you have done any web development with Dreamweaver, I am sure you are aware of its Template feature. Loved by some, hated by others, Dreamweaver templates allow you to define the layout of all the pages in your site in a single file. Inside that file, you can define "editable regions" that can be overwritten by "child pages" that are based on the template.
If you haven't seen them before (then why are you reading this article?? ;-) ), take a look at the following snippet that shows a typical page layout for a template:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<!-- TemplateBeginEditable name="doctitle" -->
<title>Untitled Document</title>
<!-- TemplateEndEditable -->
<!-- TemplateBeginEditable name="head" -->
<!-- TemplateEndEditable -->
</head>
<body>
<div id="Menu">
Menu Item 1 Menu Item 2 Menu Item 3
</div>
<h1>
<!-- TemplateBeginEditable name="Heading" -->
I am the heading<!-- TemplateEndEditable -->
</h1>
<!-- TemplateBeginEditable name="Content" -->
<p>Content goes here </p>
<!-- TemplateEndEditable -->
</body>
</html>
In this snippet, there are four editable regions: the title (highlighted in the code snippet), the head, the Heading and the Content section.
The first two allow a child page to change the page title and add custom stuff to the <head> section of the page, like CSS styles and JavaScript.
The custom region called Heading allows a page to change the contents of the <h1> tag displayed at the top of the page. Notice that since the <h1> tags are defined outside the editable region, a child page can only change the text for the heading, not its appearance.
The final region, called Content, can be used for the remainder of the document. It is designed to hold any HTML the user wants to add because the editable region is not placed between restrictive tags as was done with the Heading.
A new page based on this template looks like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!-- InstanceBegin template="/Templates/Untitled-1.dwt"
codeOutsideHTMLIsLocked="false" -->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<!-- InstanceBeginEditable name="doctitle" -->
<title>Untitled Document</title>
<!-- InstanceEndEditable -->
<!-- InstanceBeginEditable name="head" -->
<!-- InstanceEndEditable -->
</head>
<body>
<div id="Menu">
Menu Item 1 Menu Item 2 Menu Item 3
</div>
<h1>
<!-- InstanceBeginEditable name="Heading" -->
I am the heading<!-- InstanceEndEditable -->
</h1>
<!-- InstanceBeginEditable name="Content" -->
<p>Content goes here </p>
<!-- InstanceEndEditable -->
</body>
<!-- InstanceEnd --></html>
In my opinion, there are a few issues with this page. First of all, there are a lot of additional HTML comments in the page, that add to the page's weight. While it's easy to remove the extraneous markup when you put the site in production (just choose Modify | Templates | Export without markup from the Dreamweaver menu) many developers leave the code in; either out of convenience, or because they don't know it's better to remove it.
Besides the page bloat, templates bring another, much bigger issue with them. As you can see in the code snippet for the child page, the content that must be repeated in each page (for example, the menu contents inside the <div id="Menu" /> element, is repeated in every child page. When you make a change to the template code, Dreamweaver will signal the change and offer you to update each and every page in the web site.
Now, consider a web site that has 400 pages based on the template from code snippet 1 (not an uncommon scenario). The site has been live for a while and the customer has added and changed some content, possibly through Macromedia Contribute. One day, their web manager decides she wants an additional menu item, called Menu Item 4 (the company likes consistency). Because they are not brave enough to attempt to do this with Contribute they approach you for this change.
Here's what you need to do to make the required change (assuming you don't have a local copy of the site, or have Dreamweaver installed on the web server):
- Download a copy of the entire site through FTP (that is, you need at least all the files that are based on the template. Since there's no easy way to find out which pages exactly you need to download, you probably download the entire site).
- Open the site in Dreamweaver.
- Make the change in the template file and hit Save
- Dreamweaver sees the template has changed and will offer you to change all pages based on that template. Once you click OK, Dreamweaver will change each page in the entire site.
- Once all the pages have been changed, you use FTP again to upload the entire site back to the server.
Besides being a lot of work, that might take a lot of time when you're trying to down- and upload a large site, there are also other problems. First of all, on the server, all pages have been marked as changed, meaning that backup software picks up these changes and backs them up, increasing the size of incremental backups. But more importantly, during the upgrade process, the pages in the site are out of sync and visitors may see inconsistent behavior. The homepage may have already been uploaded and shows the new menu item. Another page hasn't been updated and still shows only three menu items. This results in page flicker and inconsistent looking pages (granted, if you have a hi speed connection, this may be an acceptable risk).
The Alternative
Fortunately, the alternative is very easy: move the code for the menu to a separate ASP file and include that page in the template. This can be accomplished with minimal code. You can move the content for the menu to a separate file, like Includes/Menu.asp. The file could contain nothing but the HTML for the menu:
<div id="Menu"> Menu Item 1 Menu Item 2 Menu Item 3 </div>
With the menu code moved to a separate file, you can now update the template page with an ASP include. Choose Insert | ASP Objects | Include in Dreamweaver, or type in the code directly in Code View:
<body>
<!--#include virtual="/Includes/Menu.asp"-->
<h1>
Once you save the page, Dreamweaver offers to update all pages based on the template again. Fortunately, this is the last time it asks that because from now on, when you need to change the menu, all you need to do is change the include file. If you consider the previous site change again, where a new menu item was wanted, here are the steps you need to follow:
- Download the file Menu.asp from the Includes folder using FTP
- Add the new menu item
- Upload the file again.
Much simpler, and much quicker. As soon as the upload has finished, the changes will be applied to each and every page that includes the file Menu.asp.
Since Menu.asp is just a normal ASP page, you can also add ASP code to it. This allows you, for example, to use ASP code to determine what menu item to preselect, or add a menu item for a special offering that's only visible on weekdays between 2 p.m. and 4 p.m.
Conclusion
I am not advising against using Dreamweaver templates at all. Templates are a great feature that make it easy to create consistent looking sites. You can still use a template for the general look and feel of the page, as this is less likely to change often. If you need to change it, the download - update - upload process may work well enough. ASP includes are not a complete replacement for templates; if you build up the entire page framework with includes, your page becomes harder to read and understand, and you'll give Dreamweaver a hard time in displaying the page to you in Design View.
Being aware of the implications of templates in Dreamweaver allows you to make better decisions when to use them, and when to avoid them. Use them for layout that doesn't change often; try to avoid them for repeating content that changes often. ASP includes are much better suited for that purpose.
Where to Next?
Wonder where to go next? You can post a comment on this article.
Links in this Document
| Doc ID | 381 |
| Full URL | https://imar.spaanjaars.com/381/a-better-alternative-to-dreamweaver-templates |
| Short cut | https://imar.spaanjaars.com/381/ |
| Written by | Imar Spaanjaars |
| Date Posted | 02/15/2006 21:23 |
| Listened to when writing | Si, Mi Chiamano Mimi (Puccini) by Maria Callas (Track 7 from the album: Maria Callas: The Voice Within the Heart) |
Comments
Talk Back! Comment on Imar.Spaanjaars.Com
I am interested in what you have to say about this article. Feel free to post any comments, remarks or questions you may have about this article. The Talk Back feature is not meant for technical questions that are not directly related to this article. So, a post like "Hey, can you tell me how I can upload files to a MySQL database in PHP?" is likely to be removed. Also spam and unrealistic job offers will be deleted immediately.
When you post a comment, you have to provide your name and the comment. Your e-mail address is optional and you only need to provide it if you want me to contact you. It will not be displayed along with your comment. I got sick and tired of the comment spam I was receiving, so I have protected this page with a simple calculation exercise. This means that if you want to leave a comment, you'll need to complete the calculation before you hit the Post Comment button.
If you want to object to a comment made by another visitor, be sure to contact me and I'll look into it ASAP. Don't forget to mention the page link, or the Doc ID of the document.