Processing flow - A CASE STUDY : GENERATING JSP

Generating user interfaces

5.4 A CASE STUDY : GENERATING JSP

5.4.6 Processing flow

The processing flow of the generator begins with these steps:

● Read the definition XML file and keep it in the DOM format.

● Create the output file.

● For each top-level container, you follow these steps:

❍ Add the XML attribute information to the context.

❍ Run the container template and store the result text.

❍ Pop the XML attribute information off of the top of the context stack.

❍ Add the text to the output file.

❍ Close up the output file.

● Each container follows these processing steps:

❍ Output any preamble.

❍ Iterate through interior fields and follow these steps:

◗ Add the XML attribute for the interior node to the context.

◗ Run the template for the interior node and store the result text.

◗ Pop the XML interior node attribute information from the context.

◗ Output the interior node text.

◗ Output the post-amble.

JSP generator

A CASESTUDY: GENERATING JSP 109 5.4.7 Designing the generator

Now that you have the requirements, the high-level architecture, and the input files, it’s time to think about the design of the generator itself. Figure 5.7 shows the UML for the UIBuilder generator class.

Rexml is used to parse the input definition files, and ERb is used to run the tem-plates with the data from the definition files.

This generator is simply a recursive template invoker. You pass the name of the def-inition file to the process_file command, which reads the definition file, invokes the container templates, and stores the output in the specified output file.

The container template is given a reference to its XML node as well as its chil-dren, so it can in turn ask the UIBuilder to invoke sub-templates.

This nested template invocation is a very powerful paradigm. It’s worth spending some time to understand. The relationship between the UIBuilder and the tem-plates is symbiotic, as shown in figure 5.8.

The UIBuilder uses ERb to invoke templates. These templates can then in turn use UIBuilder as a resource to invoke more templates. The results from these sub-templates is then integrated into the result of the host template.

The generator reads the definition file, and then uses the UIBuilder class to invoke the first template, which then invokes all of the appropriate templates for the nested fields. The result of the first template result is stored as the output of the gen-eration cycle for the given definition file.

In this design, the generator is simply a generic framework. The real intelligence of the system is contained within the templates.

+process_file(infile_name)

+process_template(in name, in node) +each_node()

+process_nodes() UI Builder

Rexml

ERb Figure 5.7

The UIBuilder class

UIBuilder

ERb

Template

Figure 5.8

The relationship between the UIBuilder class and the templates within the generator

The UIBuilder class

The UIBuilder class is at the center of the JSP generator design. It is responsible for:

• Reading the definition file

• Managing the file tag by creating the output file

• Invoking the top level of container tags

• Handling any nested template invocations that are required by the templates The UIBuilder context

Templates in the UIBuilder framework are like functions in a programming lan-guage. They take arguments and return values. Templates get their arguments through a context variable, and their return value is the text of the template.

For example, take this node:

The edit template is shown here:

<edit name="<%= context[ 'field' ] %>" value="<%% myBean.get<%= con-text['field'].capitalize %>() %%>">

The edit template needs the name and field attributes from the XML. The template obtains these through the context variable. The context for any template consists of the attributes of the XML tag that invokes the template. In this case, the context has both name and field, both of which are defined as middle by the XML.

Nested context

The case study JSP generator implements a nested context. The nested context sent to the template is the sum of all of the parent XML nodes, with the most recent values taking precedence.

Figure 5.9 shows examples of the context at each level of the XML tree in our form definition file.

</container>

</file>

name => 'form1.jsp'

title => 'Edit Name' name => 'edit_form' title => 'Edit Name' bean => 'NameBean'

name => 'first' title => 'Edit Name' bean => 'NameBean' field => 'first'

A CASESTUDY: GENERATING JSP 111 At the top level only name and title are defined. As we get to the container, we add the bean value, and the value of name changes to edit_form because container is the nearest tag that defines the value. Then we go into the edit tags, where we add the field value, and redefine the name value to first, then middle, and finally last.

The advantage of a nested context is that, should the edit form, for example, need to know the bean name, it gets the bean value because it inherits that value auto-matically from its parent.

Listing 5.1 contains the code for the JSP generator.

require 'rexml/document'

@templates_directory = "templates"

@context_stack = []

@output_file_name = doc.root.attributes[ 'name' unless( @output_file_name )

print "#{file_name}: No name attached to the file element.\n"

exit -1 end

@output_full_name = "#{@output_directory}/#{@output_file_name}"

begin

@out_file = File.open( @output_full_name, "w") rescue

raise "Could not create #{@output_full_name}"

end

Creates the main public entry point

t

@out_file.write( process_container( node ) ) end

}

pop_context() @out_file.close() print "#{file_name}\n"

end private

def process_container( container )

process_template( container.attributes[ 'name' ], container ) end

def process_template( name, node )

context = push_context( node ) template_full_name = "#{@templates_directory}/#{name}"

begin

raise err #, "There was a problem interpreting template #{name}"

end

pop_context() erb_result

end

def each_node() current_node = get_current_node()

result = ""

nodes = current_node.elements nodes.each() { |node|

A CASESTUDY: GENERATING JSP 113

@context_stack.each { |values|

values.each { |key,value|

node.attributes.each() { |key,value|

values[ key ] = value;

}

@context_stack.push( values ) build_context()

print "No input file specified\n"

exit -1 end

q

_The_{out_file} variable is the output file handle. output_file_name is the name of the output file, and output_full_name is the full pathname of the output file.

Adds a level to

w

These two instance variables store the location of the output directory and the templates directory. If you derive from this class, you can specify new locations for these values.

e

This code initializes the context stack. The context stack is an array of hash tables. As context hashes are added, they are pushed onto the stack and then popped off as the XML tag processing is completed.

r

_{node_stack} holds an array of references to the all of the nodes before the current node.

t

process_file is the main entry point for this class. file_name contains the name of the definition file. It is the job of process_file to read in the definition file, run the templates, and store the output.

y

_{each_node} is one of the methods that a container can use to deal with interior nodes. each_node runs each interior node and passes the text back to the template.

The template can then wrap this text in some more HTML before going on to the next interior node.

u

process_nodes processes each node in the container and returns the text of all the nodes concatenated together.

i

push_context is called whenever you invoke a new field or container. It adds the attributes of the new XML node as a new layer in the context. When you’ve finished with the XML node, the layer is popped off by calling pop_context.

o

pop_context pops one layer off the context stack.

Of course, the UIBuilder class is worthless without the set of templates that build the output code. The first template section of the code covers the templates used to build a query table.

First, we need to go back to the definition file that sets the requirements for our query table:

</container>

</file>

This XML doesn’t have any comments in it, but there is no reason it couldn’t. You should treat definition files just like source code. They should include comments that describe the purpose, the author, the revision history, and so forth. XML allows for this using the  comment standard.

The definition file shows us that we’ll use two templates: table_page and column. The table_page is referenced by the container tag, and the column template is referenced by the column tag. Remember that the design of this generator

A CASESTUDY: GENERATING JSP 115 specifies that anything that isn’t explicitly a “container” (excluding the file tag at the top) is a template reference, wherein the name of the tag is actually the name of the template. So the column tag becomes a reference to the column template.

Listing 5.2 contains the code for the table_page template.

<jsp:useBean id="myBean" class="<%= context[ 'bean' ] %>" scope=request></

jsp:useBean>

q

The template uses the local context to specify the bean, in addition to setting the title of the page.

w

_The_{each_node} iterator is used to build the header for the table. Then you use process_nodes() to fill in the interior of the Java table iterator, which builds all of the <tr> and <td> nodes of the table.

The next template used in this example is the column template, shown here:

<td><%%= result.get<%= context['field'].capitalize %>() %%></td>

This is a simple template that creates a single JSP <td> tag builder.

The capitalize method on Strings in Ruby uppercases the first character in the string and lowercases the rest of the string. If your field has camel case characters (e.g., myValue), be warned that capitalize may not give you the result you expect. If you have this problem, you should write your own routine to handle your case-sensitivity variants.

The <%%= is the ERb method for specifying <%= in the output. The %%> sequence creates %> in the output.

Now, here’s the output of the generator for the definition file:

<jsp:useBean id="myBean" class="NameBean" scope=request></jsp:useBean>

<html>

<head>

</head>

<body>

<table>

<tr>

<th>First</th>

<th>Middle</th>

</tr>

% ResultSet result = myBean.query();

% while( result.next ) {

<tr>

</tr>

% }

</table>

</body>

</html>

In the production code, you will likely need to add URL argument handling to the templates so that the resulting JSP can send query parameters to the bean. Depending on your application architecture, you could hard-code these parameters into different types of page_templates, or you could migrate the URL parameters into the defi-nition file and then have the page_template respond to those by generating the URL-handling JSP.

Another goal of the generator is to build HTML forms. An example HTML form definition is shown in listing 5.3. The edit_form template (listing 5.4) creates a page of form controls.

</container>

</file>

Listing 5.3 Form template code

A CASESTUDY: GENERATING JSP 117

<jsp:useBean id="myBean" class="<%= context[ 'bean' ] %>" scope=request></

jsp:useBean>

q

The template uses the context to get the bean and to set the title for the HTML page.

w

The template also uses the @output_file_name class member of the host UIBuilder object. It can do this because the binding of the UIBuilder object is sent to the ERb template. This binding includes the context hash, but it also includes anything in the current scope of execution, such as member variables. If this design does not suit you, one alternative would be to use specially named values in the context for elements like the output filename.

Now, here’s the code for the edit template:

<edit name="<%= context[ 'field' ] %>" value="<%% myBean.get<%= con-text['field'].capitalize %>() %%>">

This simple template uses the context to build the HTML for the edit control and to build the JSP that sets the value of the field at runtime.

The output of the JSP generator for this form definition should look like this:

<jsp:useBean id="myBean" class="NameBean" scope=request></jsp:useBean>

We deliberately simplified this example; in a production environment you will need to include field validation, page-level security, and URL-handling code.

For this generator, let’s use the system test utility (described in appendix B) with the following definition file:

<test cmd="ruby uigen.rb definitions/table1.def" out="output/table1.jsp" /

</ut>

The first time you run the JSP generator, you want to create a set of known good out-put. The known good output is a copy of the output that you certify as perfect. To create the known good output, run the following:

% ruby ../ut1/ut1.rb -m -f ut.def ruby uigen.rb definitions/form1.def definitions/form1.def

Known good kg/form1.jsp stored ruby uigen.rb definitions/form2.def definitions/form2.def

Known good kg/form2.jsp stored ruby uigen.rb definitions/table1.def definitions/table1.def

Known good kg/table1.jsp stored

Of course, you should inspect the known good output files to make sure they are really

“good.” Then you can make whatever modifications you like to the generator and rerun the tests:

% ruby ../ut1/ut1.rb -f ut.def ruby uigen.rb definitions/form1.def definitions/form1.def

ruby uigen.rb definitions/form2.def definitions/form2.def

ruby uigen.rb definitions/table1.def definitions/table1.def

No test failures

At this point you can be reasonably sure that, as long as your tests covered a reasonable gamut of functionality, your system is still performing well after alterations.

TECHNIQUE: GENERATING SWINGDIALOGBOXES 119

5.5 T

ECHNIQUE

:

GENERATING

S

WING

In document Code Generation in action (Page 137-148)