A Docbase Form Template

A user creates a Docbase record by means of a web form. The form isn’t served statically, though. It’s generated on the fly from a template. After all that discussion in the last chapter about the virtues of dynamically generated but statically served pages, why should we generate this form? The technique helps us to constrain inputs, enforce controlled vocabularies, and divide the responsibility for completing different parts of the form among different people.

Example 6.1 shows the template for the ProductAnalysis input form.

Example 6-1. ProductAnalysis Input Form Template 

<html>
<head>
<title>Product Analysis Report Form</title>
</head>

<body>

<center><b>Product Analysis Report Form</b></center>

<form method="post" action="!ACTION!">

<table cellpadding="4">

<tr>
<td align="right"><b>Assignment Date</b></td>
<td align="left">|assigndate|</td>
</tr>

<tr>
<td align="right"><b>Due Date</b></td>
<td align="left">~duedate~</td>
</tr>

<tr>
<td align="right"><b>Analyst</b></td>
<td align="left">~analyst~</td>
</tr>

<tr>
<td align="right"><b>Company</b></td>
<td align="left">~company~</td>
</tr>

<tr>
<td align="right"><b>Product</b></td>
<td align="left">~product~</td>
</tr>

<tr>
<td align="right"><b>Title</b></td>
<td align="left"><input name="title" size="40"></td>
</tr>

<tr>
<td align="right"><b>Summary</b></td>
<td align="left"><textarea name="summary" rows="2" cols="50" 
wrap="virtual"></textarea></td>
</tr>

<tr>
<td align="right"><b>Full report</b></td>
<td align="left"><textarea name="fulltext" rows="3" cols="50" 
wrap="virtual"></textarea></td>
</tr>

<tr>
<td align="right"><b>Contact info</b></td>
<td align="left"><textarea name="contact" rows="3" cols="50" 
wrap="virtual"></textarea></td>
</tr>

</table>

<p><center><input type="submit" value="submit"></center></p>

</form>
</body>
</html>

I wrote this template by hand, but you could also produce it using an HTML editor. Either way, the crucial idea here is to separate the concerns of a designer, who worries about the form’s content and appearance, from the concerns of an implementer, who wires the form to a scripted handler. In this scenario, the form’s author and its implementer need only share a common vocabulary of markers, or replaceable elements, that invoke special functions when the template is processed to produce an actual HTML form.

There are three kinds of replaceable elements. The code that processes the template looks for patterns that match these marked elements and replaces them as described in Table 6.1.

Table 6-1. Docbase Input Template: Marked Elements and Replacements

Pattern

Replacement

!ACTION!

The CGI path to this docbase’s instance of submit.pl—for example, /cgi-bin/Docbase/ProductAnalysis/submit.pl.

|function-name|

The result of a Perl function, mapped to function-name. For example, |assigndate| might map to the Perl function getDate( ), which might return the value 1999-04-12. On the form this element renders not as an input field, but rather as a computed static value. In order to transmit this value to the form’s handler, the form generator also tacks on a hidden field, for example, <input type="hidden" name="assigndate" value="1999-04-12">.

~variable-name~

The script that generates the form can override this slot with a supplied constant. For example, a manager who assigns a report on Internet Explorer 5.0 can use the form generator to replace ~product~ with the static text Internet Explorer 5.0. As in the case of a computed value, this preassigned value appears as static text on the surface of the form. The form generator also adds a hidden field, which transmits the value to the form’s handler. By default, when a slot isn’t overridden in this way, the form generator replaces ~product~ with the HTML code for an input box, like this: <input name="product" size="40">.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset