Designing Modular Domino Applications

Jake Howlett, 17 June 2001

Category: Miscellaneous; Keywords: form view layout html

It is becoming increasingly important for databases that form part of a website, be they part of an Intranet or Internet site, to have a common look and feel across all their pages. In the case of an Internet site it is often the basis of a customer's first impression of the company. It goes without saying that, for this reason, it needs to have both a professional and consistent look.

How do we achieve this in a site that consists ultimately of a single Domino database? The professional look is a matter of opinion and well beyond the scope of this article. However, IMHO anything that is clean and simple tends to do the trick nowadays. What I am about to describe is how to make the site's layout consistent throughout and how to do so in a manner that makes future changes simple to implement across all the views and forms.

Designing in Notes does not lend itself to the notion of a template for any particular page. The norm seems to be that we have to create all the tables and common design elements for each form and reproduce them in each one. This is all very well until the design of a particular element changes, meaning somebody needs to go through every form and make the change to each element.

Consider the layout of CodeStore. Whether you are in a view or a document you should notice that they both share many of the same features while parts remain particular to each. For instance, both contain a search box and a list of areas on the left-hand side, whilst only the views contain the view navigation area with the next and previous links and only the form contains the "Options" table.

So how to go about designing Domino applications in a manner that befits this type of design. The two key features used are Pass-Thru HTML and Subforms. Making use of the way in which HTML is written we can split the page in to blocks of code that can then be plugged together as and when needed. This code can then be placed in to Subforms that can be placed on to forms where they are required to tailor the page to its requirements.

Let's show how this works in more detail using an simple example.

Image

In this example we have laid the page out using a main table with two further tables embedded in it. The "main" table has three rows and two columns. The first row is spanned as one column and contains the "header" table. The second row has the "links" table in its first column and the main content of the page in the second. Finally, the third row contains a simple message, consistent across the whole site.

So, how do we go about plugging this in to Domino? First thing to do is copy the HTML source for the page from the Editor that you used to plan (or "comp") the layout. Paste this in to an empty form in the Domino Designer. Remove the unwanted <head>, <body> and other tags from the top and bottom that we don't need. All that's left should start and end with <table> tags, as below:

Image

Notice in the above screen-shot that we used the "Text" menu to mark all the HTML as Pass-Thru HTML. I prefer to do this rather than create things like tables within Notes. This way we have complete control over what gets sent to the browser. No more weird or spurious code generated by the Domino server.

Now we need to break this down in to modules. The idea is to make everything apart from that which is likely to change between different forms in to modules.

The first module will be the start of the "main" table and the first half of the "header" table. The code for this is shown below:

<table width="600" border="1" cellpadding="4" cellspacing="0">
<tr>
<td colspan="2">
<table width="100%" border="1" bgcolor="#CC3300" cellspacing="0">
<tr>
<td><b>Modular Domino</b></td>
<td>
<div align="right"><i>

The reason I stopped here is that the next part is the text that reads "homepage". Obviously this will change on each form and so we don't want it in our modules.

The next module serves three purposes. First it completes the "header" table, then the first row of the "main" table and finally it starts the second row and its first column. The HTML code for this is:

</i></div>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td width="102">

By now you may be thinking, "what are these modules you are talking about?". Well let's take the above two and see what to do with them before continuing. With the first, take the Pass-Thru HTML and paste it in to a Subform. Call this Subform "Module1-FirstRowStart" or something that will make sense to yourself and other developers. Do the same for part two and call it "Module2-SecondRowStart". Also, you may find it handy at this point to add some hidden coloured text to the beginning and end each of each subform so that you can see where they are, start and finish. By now the form should be starting to look something like that below.

Image

Notice that in between the end of Module1 and the start of Module2 there is some text that is placed directly on the form. This is the text that can change. Notice also that I have called this form "Template". That is because when we have finished putting it together we will simply copy and paste it each time we need a new form that uses this layout. Let's continue splitting the page in to modules. The next is the start of the "links" table.

<table width="100" border="1" bgcolor="#FF9933" cellspacing="0" cellpadding="2">
<tr>
<td><a href="#">About Us</a></td>
</tr>
<tr>
<td><a href="#">Contact Us</a></td>
</tr>
<tr>
<td><a href="#">Products</a></td>
</tr>
<tr>
<td><a href="#">Downloads</a></td>
</tr>

Notice that I finished the "links" table before the final </table>. This lets us add rows to the end as and when we need to using blocks of code like the one below:

<tr>
<td><a href="#">Support</a></td>
</tr>

The power of segments like this is that we can use Computed-Subforms to work out what rows we want to add depending on things like whether the user has logged in or not, whether the document is in edit mode, if the user is an administrator, etc

When we have done adding extra rows we need to end the "links" table. Then we need to end the first column of the second row and start the second column. We can do all of this in one module, like the one below:

</table>
</td>
<td width="482" valign="top">

It is at this point that we are in the main area of the form. This is where you are likely to want to add things like fields and submit buttons (or embedded views if it's a view template). It is often a good idea to turn Pass-Thru off for the part between these two modules. See below:

Image

The final module ends the main cell and the second row. It then adds the third row, which we assumed, was fixed. All that is left then is to end the "main" table and all is done.

</td>
</tr>
<tr>
<td width="102" height="18">&nbsp;</td>
<td width="482" align="right" height="18">&copy;Copyright to anyone who feels it is worth it, 2001</td>
</tr>
</table>

We now have a form that can be used as the basis for all others within the site. Simply copy and paste this one and make the necessary changes wherever needs be.

Hopefully by now you are getting a feel for how powerful this method can be. If you are lost then I suggest reading again. This method really is worth learning. I suppose you could compare it to using Server Side Includes (SSI) on other platforms. The power of which is that when you need to change the layout you only need do it in one place. This coupled with the use of Cascading Style Sheets (CSS) wherever possible lends itself to a site that truly is modular.



Download: If you want to have a look at a simple database that uses this method then you can download it from the link just below the end of this article.