Why should you use a tool like Patchwork?

Let's assume you're working on a website that has a simple layout with free different areas: Header, Left and Main. For each page of the website, the Main area will change. The Header and the Left areas should not change at all. The picture below shows the structure of such a very simple layout. Let's say this master layout gets displayed if you call the uri /index.html of your website:

The main layout.

The Main area will change for each page of the website. For example, if the vistor wants to see the latest news and clicks on the /news.html link, the current content of the Main area must be replaced by the News content as shown in the picture below:

The news layout.

The static way

At first let's discuss some static ways to achieve the definition of different layouts.

Duplicating layouts

The - at least at the beginning - easiest approach to replace certain areas of a website with other contents, is to duplicate the master layout and to adjust the according areas of the page. For most websites this is a very, very bad idea because of the redundancy of the layout files. No more to say here :)

Using frames

Another approach could be using HTML frames to model your layout, and yes this is a reasonable way, but using HTML frames do have several disadvantages which're very hard to avoid:

  • Wrong URI for Bookmarks - Always the URI of the frameset entry page will be displayed in the Browser's bar, not the URI of the currently selected main part. This makes it hard for the visitor to bookmark the right page like News for example.
  • Loading without frameset - If a search engine like Google for example creates an index for a page, it will create it on the content page and not on the frameset. But this causes a problem, because if a vistor finds your category page via Google and clicks on it, he will see the content page and not the whole frameset including the Left and Header area, except you involve some JavaScript to avoid this.
  • Each frame has it's own request - Last but not least, there is a big problem on the server side because the browser produces a new request for each frame in order to get the content for the frame. This makes it much more difficult for the server side programmer to handle logic for each frame. The programmer has to do the communication between frames over the session scope instead of doing it directly in one application's logic resource like a Controller, Servlet or a Flowscript.

These are not all disadvantages of using frames, but in my opinion the important ones. The cunclusion of this is: Using frames for structurizing your layout is in most cases a bad idea at all. Don't do it if there is no concrete requirement for this!

The dynamic way

You can avoid the disadvantages of using frames for defining layouts by using server sided frames instead. This means for each request the server will detect, which layouts fit together, merges them into the master layout and responses only one page to the client. This approach requires a system at the server side that allows such a merging process. One of the easiest ways could be using import statements of the underlying template engine like STL from JSP, Velocity or Cocoon's JXTemplate or CInclude meachanism. In the example below you can see a simple template that defines the Left-Header-Main layout using a table and the import statement of Cocoon's JXTemplate language:

<html xmlns:jx...>
  <body>
  <table width="100%">
    <tr>
      <td colspan="2"><jx:import uri="templates/header.jxt"/></td>
    </tr>
    <tr>
      <td width="200"><jx:import uri="templates/left.jxt"/></td>
      <td><jx:import uri="templates/main.jxt"/></td>
    </tr>
  </table>
  </body>
</html>

In this example you can see the first big advantage using server side frames instead of HTML frames: You're much more flexible to create your layout because you're not limited to rows and columns like in HTML frames. You can insert includes of other layouts at every position in the HTML file. But looking on this exampe, one can find a big disadvantage: The URI's for the includes are all hard coded. So, what happens if we want to replace the uri templates/main.jxt by templates/news.jxt? Hmm, the first idea could be to use variables instead of hard coded values like the example below shows:

<jx:import uri="${main}"/>

So, but how to get this variable $main resolved into a path like templates/news.jxt for example? The solution for this is to introduce and execute some logic before the template get's parsed, by creating a Controller for example. It's a really flexible solution but requires a lot's of work for a simple task. For each request you have to write your own new "include logic" or at l east a central parameterizable Controller which does the job. Another point against this solution is that in big pages with many includes and includes of includes you have to go thru your template files and to find out which include variables are already used and whether there are variables which're already declared or overwritten by another one? Puhh, this can make things very very complicated and makes debugging a mess on bigger web projects.

Patchwork let's you avoid all of these disadvantages and also introduces some powerful additional features like inheritance of layouts for example.