Please note: this topic is currently under construction. It is possible that the styling approach described in this chapter will be replaced by some other approach in subsequent versions. (Further comments at the end of the chapter)
DbForms comes with a simple yet powerful method of template-processing. This mechanism was designed to ease and speed up development. In summary, it is based on the following requirements:
It should tidy up the HTML/JSP code. In other words, it should act as a kind of macro-engine replacing complex code by simple statements. This makes the HTML/JSP-code easier to read, understand and maintain.
It should be easy to use. Application-designers using predefined templates should not need to do any complicated coding. They should just specify which template to use and eventually specify attributes for customizing the templates this leads to the next point:
Templates should be dynamic, not static. Templates should be able to retrieve and process attributes provided by the application -designer. Furthermore, templates should be JSP pages themselves, to provide maximum flexibility.
New templates should be easy to create. Transforming a good-looking HTML/JSP code into a valid and working template for use by DbForms-applications should be a matter of a few minutes, not hours! This should ensure growing repositories of powerful DbForms-templates which are available to other DbForms-developers (whether inside a company or even better as a contribution to all developers)
Including existing templates into the JSP view is according to the goals described above an easy task. There is only one custom tag,
db:style tag, that needs to be facilitated for this purpose:
<db:style
template="templateName"
paramList="param1='value1',param2='value2',. . .,paramN='valueN'"
part= "begin" /
>
This tag may or may not include a body. Its attributes are:
template [required]: this refers to the name of the template to be used
paramList: a parameter-list used to specify rendering properties for the template.
part: the part of the template (i.e. begin, end)
Imagine a simple login box. The code for such a form could resemble the following:
<html>
<body>
<db:style template="center" part="begin" />
<db:style template="sourceforge" paramList="width='300'
bg='steel3.jpg'" part="begin"/>
<form method="POST">
<table align="center">
<tr>
<td>
<b>Username: </b>
<br>
<input name="j_username" type="text">
<br>
</td>
</tr>
<tr>
<td>
<b>Password: </b>
<br>
<input name="j_password" type="password">
<br>
</td>
</tr>
<tr>
<td align="center">
<br><input type="submit" value="Log in!">
</td>
</tr>
</table>
</form>
<db:style part="end"/>
<db:style part="end"/>
</body>
</html>
Remarks
Note the bold printed <style> tags. The use of these tags make up the difference between the screenshot shown in Figure 17 and the other one in Figure 18
As you may notice, one template (sourceforge) is nested into the other (center).
Another thing you may notice is that the sourceforge-template (which I have taken from the popular open-source development site sourceforge.net) defines a parameter-list while the other template does not.The parameters declared in the parameter list are written in JavaScript-style using single quotes, but the quotes may be left out (they are tolerated to make parameter lists easier to read) The important thing however, is to separate each param-value-pair by a comma.
There exists (optionally) one template-directory for each web-application. This directory should be dedicated exclusively to templates. The location of this directory is specified in the web application deployment descriptor (web.xml) using the context-parameter templateBase (see following example)
<context-param>
<param-name>
templateBase</param-name>
<param-value>mytemplates</param-value>
</context-param>
If there is no such entry in web.xml, then the default directory
templates will be used.
The directory entry is relative to the root of the web-application (absolute directories are not allowed)
This base-directory contains all templates accessible by the application. Each template has its own subdirectory. In the example above, the subdirectories sourceforge and center would exist.
A template usually consists of two files: One file to be included/rendered when the start of the style-tag is evaluated, and another file to be included/rendered when the end of the style-tag is evaluated. The starting file has to have the suffix _begin.jsp, the ending file has to have the suffix _end. The names of both files start with the name of the template (and the directory they are contained in)
In the example above, the following structure exists:
ourWebApp/templates/
ourWebApp/templates/sourceforge/
ourWebApp/templates/sourceforge/sourceforge_begin.jsp
ourWebApp/templates/sourceforge/sourceforge_end.jsp
ourWebApp/templates/sourceforge/images/
ourWebApp/templates/sourceforge/images/steel.jpg
ourWebApp/templates/sourceforge/images/nail.jpg
ourWebApp/templates/center/
ourWebApp/templates/center/center_begin.jsp
ourWebApp/templates/center/center_end.jsp
As you may have noticed in Listing 18, there can also exist other resource types (image-/jsp-/html-files) in addition to the mandatory
*_begin.jsp and
*end.jsp files. These files may be statically or dynamically included by the templates-stubs.
center_begin.jsp
<table width="100%" height="100%">
<tr>
<td>
</td>
</tr>
<tr>
<td>
<center>
center_begin.jsp
</center>
</td>
</tr>
<tr>
<td>
</td>
</tr>
</table>
As most readers will agree, there is not much to tell about the code above. In this example, a table gets rendered which centers all elements it embeds (for instance the login-form).
a few snippets from sourceforge_begin.jsp
<%@ taglib uri="/WEB-INF/taglib.tld" prefix="db" %>[...]
<table cellpadding="0" cellspacing="0" border="0"
width
="<db:templateParam name="width" defaultValue="99%" />">
[...]
<td background
="<db:templateBasedir/>images/tbar1.png" width="1%" height="17">
[...]
<db:templateParam name="bg" defaultValue="steel.jpg" dir="images" />" >
[...]
This example shows the usage of two custom tags supporting templates.
<templateParam> parses a specified parameter from the paramsList-attribute of the calling JSP.
<templateBasedir> supplies the base directory to use. This is important to make sure all resources (ie: images) are found.
More information about these tags can be found in the description of the custom tag library and in on-line examples.