Designing Modular Domino Applications
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.
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:
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.
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:
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"> </td>
<td width="482" align="right" height="18">©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.
As it should be...
I like to see that more folks find out that Notes dont always handle the HTML as we want. Personally i use Dreamweaver to make the design and rip the code into Notes, as described in the tip. There are to many items in Notes that dont quite messure up for webuse, sadly enough. And Jake is right that doing it this way makes it easy to update the code, and easy to choose what elements to show on the page by just using subforms. The possibilities are endless. Until Lotus can handle HTML the way i want, ill still be doing the design in another app...
Reply
Re: As it should be...
I have personally been invlolved in this kind of development for over a year now. Another idea that I have found usefull has been to use computed text in the table attributes, most notably width. This means taht if at some point you find you have to change the size/layout of the tables, you can simply change the field value from which the computed text is derived. You can then compute spanned cells etc to ensure that your layout will change accross the site (which may contain multiple databases) consistsntly and quickly.
Please check out http://www.kidneywise.com This complicated HTML layout is used accross multiple databases. I use lookups to immitate includes that you would use in regular websites. I created a central repository for my graphics, my JS files and CSS files. I also created my standard subforms in this database. The other databases then inherit changes from this database (I do not set it up as a template as then you cannot preview the cnages through a browser), hence when I update the title section in the central repository I can then run the designer task on thhe server and update the entire site quickley. One thing to watch though is that when you update a JS file with a new function which is called from a page somewhere in the site, you can get problems when the older version of the JS file is cached either on someones machine or on a proxy server, the functions will not be available to the web page and you will generate errors. Tricky one to solve, I thought about appending a computed number to the end of the JS file name, this way if I update the JS file, I can rename it say validate02.js and then change a lookup value in the configuration database to reflect this change accross the site. I hope someone somewhere finds this usefull.
Reply
Subforms & Domino Development
I agree, using subforms to divide a page/form into blocks is a very useful technique.... but....
According to the Lotus White Paper "Maximizing Application & Server Performance in Domino" the use of computed & static subform's should be minimized. The White papers says "Loading subforms requires calculations which can slow down the opening of documents slightly".
Interesting last word I thought!!! Personally, I still use them, and have never had any problems. I thought I would just drop you a line incase you all go subform crazy!!!
Reply
Re: Subforms & Domino Development
True that it takes some serverload to open subs. But there are few options to this, you can do lookups and get the code from a document too, but this takes more power. I use a doc for "sitedata", mailaddresses, phonenumbers e.t.c. The i get this via computed text lookups. I have checked the serverload on a forum for boats in Sweden with 2500 visits a day, and the load is nothing to mention. But take care here, some lookups can really drag your server down. It would be fun to get some input on wich lookups that really creams the power...
Reply
Re: Subforms & Domino Development
I have been doing Domino Web development for almost two years now. I always use subforms and this pass through HTML techniqe. Once I designed a site that server 75,000 usera a day at its peak and the server performed beautifully. I am of the opinion that the processing you save by using pass through HTML versus letting Domino create the HTML when the page is requested far out weights the processes required to compute subforms. I use this technique often and not one of my clients has ever complained about performance.
Just my .02 worth!
Cheers, KB
PS Jake I love your site. Keep up the great work! But can you add 'wrap=virtual' to the text area for these comments? Just trying to help!
Reply
Re: Subforms & Domino Development
I must say I agree with the other two "pro-subform" opinions, but can add some perspective about "why".
All design documents are just that. Documents. Any subform called involves finding a document by its NoteID and opening it. This is all done in C and is quite fast. If the contents of the subform are almost entirely passthrough text, there is very little processing that goes on after the subform loads. What can kill performance is having many subforms that do calculations, rendering to HTML, etc.
Also, as mentioned, dblookups can kill performance as well. You might consider keeping these kinds of settings in a small set of documents and using a shared field populated with their UniqueID's or something. There are further steps to make this a maintenance-free option, but avoiding dblookups, columns, etc. is always a good idea. Fast is good. Faster is better! :-)
Reply
Re: Subforms & Domino Development
>According to the Lotus White Paper "Maximizing >Application & Server Performance in Domino" the >use of computed & static subform's should be >minimized. The White papers says "Loading >subforms requires calculations which can slow >down the opening of documents slightly".
This White Paper is at http://www.lotus.com/developers/itcentral.nsf/wdocs/f230673920a2a26085256778006d 67f8 for those who are interested.
Anyhow, I think the idea to discuss a little more app tuning is pretty good, as it might make people more aware of performance sinks right from the start (as in: stop aiming for the quick implementation and neglecting long-term usability). Maybe somebody has some neato Domno server tuning tips, too...
Perhaps all performance related stuff could be collected on a links page, pointing to the original posts and articles here and on other sites.
Reply
replacement for framesets
Something that hasn't been mentioned...
One big bonus to doing things this way is that you eliminate the supposed 'need' for doing framesets.
Modt apps that use framesets do so because the developer wants modular code--not because the user will benefit. And although sometimes arguments can be made about a few benefits, the fact that your favorites/bookmarks won't work really is bad for users.
And remember that by enabling favorites to work, you also enable users to do things like email url's to web pages instead of whatever the heck they'd do to share the info.
However, I should stop before I turn this into an argument over framesets.
Reply
Re: replacement for framesets
What about if you want e to use RTF (Java Applet) on the form? I noticed RTF (Java Applet) will not work in tables. Is there any work around for this issue? I would like to apply the modular approach, and use the RTF (Java Applet) on the form. Is this possible? Thanks in advance. Codestore is an excellent Notes resource! I only wish that I knew the site earlier!
Reply
BUG?? Re Computed Subforms:
Does 8.5.3 have a bug with subforms or am I doing something stupid:
We have a form and based on a value (parsed via query string) we want to launch the form with a specific subform. Works fine, html source shows relevant fields, javascript can reference values HOWEVER, when it gets to the WebQuerySave, the agent/script library seems unable to reference the field NOR does it save the field(s) as document property.
Specific Elements are:
appSubform (computed when composed field: Builds String based on querystring paramter.
Computed Subform: simply references this field.
IF I hardcode the appSubform to have the actual value it works fine, but as soon as I try to reference/build the name it fails DESPITE tha fact thet when output to the log, the webquerysave agent knows the value.
Heeeelp!! Please.
Just realised how old this thread is so hope this is still viewable,... here goes.
Thanks in advance.
Reply