Objective

Learn how to embellish the object tree in memory to make it more suitable for output. We'll change and add properties of the objects and add new objects to the tree.

We'll have a look at a very simple front-to-back web application that stores information on a database server, using SQL. If you don't know SQL, don't worry. It's the techniques used to generate the application that matter, not what the final application looks like.

Some Architecture

Collecting information from an HTML form and passing it through to an SQL database needs some intermediary server-side code: CGI, servlets, ASP.NET, etc. The architecture here will be a simple jsp servlet to pick up the request information and either create the response or forward it to another jsp servlet, together with a java object that accesses a database. I wouldn't recommend using this architecture for real, but I'd like to show something that works without overcomplicating things by implementing a real framework. Too many examples are so trivial as to not reflect what happens when you do things for real. I hope this strikes a happy medium.

If you are going to generate an application to a specific architecture, it's a good idea to sort out a target architecture before working out what patterns and templates need to be written. In fact if you haven't already got a working example of something written using the structure you are aiming at it's probably a good idea to first write a small working example.

Up until now we've been generating a set of simple static pages that could be accessed directly from a file server. If we use a web server, such as Tomcat, or an application server such as JBoss, we can do a lot more interactive and useful things. The example we're going to build runs on Tomcat.

Servlet code is run on a web server or an application server, so instead of a browser picking up plain static files, it sends a request through to the server, and the server will return a response. This can be a static page or the result of servlet code. A configuration file tells the server what is expected of it, depending on the URL the request has accessed.

Jsp is an extension to servlet technology, where a servlet is constructed from a script-like page. In its simplest form, a jsp looks just like an html page. When called, the text on the page is transformed into java print commands inside the java servlet code, which are then used to construct the response. So the HTML in the jsp page is served to the browser by a faily indirect route. But a jsp can do a lot more, running java code, translating tags, etc.

So the first change is to make all generated .html files into .jsp files instead, using the build.xml file under screen. Next we upgrade the main build.xml for the application to add a deploy target, which will copy the output area, including the jsp and static files to the right place on the server. have a look at the build.xml file at the top level of the example code. Because I want the name of the directory to follow the name of the site in the specification, I'll generate a properties file called application.properties and refer to it in the new deploy target.

Typically Tomcat uses port 8080 and after starting the server up, you can view the application using http://localhost:8080:/My Site/

A First Pattern

The space in the name "My Site" is a little awkward. Some browsers put a %20 in the URL which looks messy and some operating systems have problems handling it at all. So we won't use it as it stands. We'll distinguish between a site name and a site title in much the same way as we've done with the screen, title will include the spaces and name won't. Now you might think that's just another thing to add to the specification, but there's no real need for that. We can write a simple pattern that will check to see if the specification includes a name or a title or both. If it only includes one, we'll try and derive the other.

We create a file called preIncludeSpec.vm in the template sub-directory for site and use the same JeeWiz scripting as we have done with the templates.

		#if ($this.title)
		  #if ($!this.name != "")
			 #set ($this.name = $this.removePunctuationAndCapitalise($this.name))
		  #else
			 #set ($this.name = $this.removePunctuationAndCapitalise($this.title))
		  #end
		#else
		  #if ($!this.name != "")
			 #set ($this.title = $this.getCapsAndSpacesName($this.name))
			 #set ($this.name = $this.removePunctuationAndCapitalise($this.name))
		  #else
			 #set ($this.name = "DefaultApplicationName")
			 #set ($this.title = "Default Application Name")
		  #end
		#end
		

If the name is set, make sure it has no punctuation using the appropriate helper method. If the title is set, let it stand. If there is only one use the other to derive a value, and if there is neither create defaults.

It's worth noting that getting a dollar variable as we did in the templates, using say $title will look for a title variable in a number of places including local variables and properties on the current object, but if you set $title it will just set a local variable. If you want to set properties on the current object, you need to use the full $this.title.

Three Pattern Phases

preIncludeSpec.vm is a special pattern name that is picked up by the JeeWiz engine. If it is present in the directory, JeeWiz will use it to let you modify objects in the object tree. For simple things you could do the work directly in the templates, but for more complicated things, such as creating new objects in the tree, we need to use patterns.

There are three phases of tree walks available to embellish the object tree. The first, the pre-include phase or just pre-phase, we have met. That is normally used to modify an object, perhaps by changing or adding properties. The tree is walked from the top-level item, in our case site, downward. So parent objects will be modified before their children.

The final walk is called on the main-phase and the details are written into an includeSpec.vm file, which is also placed in the relevant template sub-directory. Include patterns are used for bigger changes to the tree, such as adding peer or child objects. The include walk is done bottom up, so the pattern fires for children before parents.

That's not to say that you can't add objects in a pre-include, it's just that you have to make sure everything is available that you need. It's often useful to have access to child elements, and because the final tree-walk is bottom up we can be sure that they will always be there in the include phase. Sometimes there's a problem in timing we need things to be created in an order other than the natural one. This is especially true if the object is to be placed somewhere on the tree not immediately adjacent to or below the current object. To resolve these timing issues there is another top-down walk called on the extra-phase that fires when an extraIncludeSpec.vm file is found in the template sub-directory for an object. It's also possible to define the order of sibling processing of different class types in the tree-walk.

The preIncludeSpec.vm, extraIncludeSpec and include Spec.vm files can be just the first file the engine uses. It's possible to use a #parse directive which will include other script files. It's also possible to chain script files so that they run sequentially. This is different to parsing, because new objects to be added to the tree are not accessible as objects to the same pattern, and parsing effectively extends the same pattern. By chaining patterns in the same phase, objects created in one pattern are available to the next. We shall also see that each patterns has a context, the place where objects can be created on the tree, and by chaining patterns we can create objects in multiple places during the same tree walk for the base object.

We are going to add to our list of specification objects: we have site, logo, menu, menu-item, screen, section, event and script. We will add attribute and attribute-group. An attribute holds a single item of data and could be displayed on the page or stored in the database. An attribute-group is a group of attributes which are stored together and/or displayed together. For simplicity we will implement a maximum of one attribute-group on a page. All attributes will be text fields and all will be displayed using a text box or a text area. We will put an property on the screen meta-model called attributeGroup. If this names a valid attribute group, the attributes in the group will be displayed on the jsp page generated for this screen - and more about that later. You should be familiar with the creation of a meta-model for these new elements from the last tutorial, and a version of the xml files is available for you to view in the completed example code.

We will then use an IncludeSpec.vm pattern to create a set of default pages to let us maintain data in the database, just by flagging that we want to in the attribute-group specification. This shows the basics of how we can create objects in the tree.

Creating Objects on the Tree

As well as including JeeWiz script commands, patterns can define xml specification. The root object will normally be <this> or <parent>. That sets the context as either the current object or the parent of the current object. Objects defined/specified under the context object will be created under the context object on completion of the pattern. So objects defined under <this> will become new children of the current object. Objects defined under <parent> will become siblings of the current object.

So let's say we want to include three new maintenance screens in the specification for every attribute group. One will be used to create new records, one will be used to find existing records and one will be used to update or delete existing records. We can place attribute groups directly under <site> in our specification, and the screens will be peers of the attribute groups.

So for each attribute group defined in the original specification we will use an attribute-group IncludeSpec pattern that might look something like

		<parent>
		  <screen    name ="${this.nameCapitalised}Create"
						 title = "Create new ${this.name}"
						 style="create"
						 attribute-group="${this.name}"
		  >
			 <event   name="create"
						 link-caption="Create"
						 style="create, button"
			 />       
		  </screen>
		  <screen    name ="${this.nameCapitalised}Maintain"
						 title = "Create new ${this.name}"
						 style="update"
						 attribute-group="${this.name}"
		  >
			 <event   name="save"
						 link-caption="Save"
						 style="save, button"
			 />       
			 <event   name="delete"
						 link-caption="Delete"
						 style="delete, button"
						 page="${this.nameCapitalised}Search"
			 />       
		  </screen>
		  <screen    name ="${this.nameCapitalised}Search"
						 title = "Create new ${this.name}"
						 style="create"
						 attribute-group="${this.name}"
		  >
			 <event   name="search"
						 link-caption="Search"
						 style="search, button"
			 />       
			 <event   name="new"
						 link-caption="New Record"
						 style="button"
						 page="${this.nameCapitalised}Create"
			 />       
			 <event   name="select"
						 link-caption="Search"
						 style="search, url, inline"
						 page="${this.nameCapitalised}Maintain"
			 />       
		  </screen>
		</parent>
		

Events are handled differently here than in the last tutorial. Instead of specifying a script to run on the client side, we are specifying a style that will run code on the server side. The attribute-group property will define which attributes appear on the screen, and we want that to match the attributes of the current object, so we specify $this.name, the name of the attribute object that is being used to generate the page specification. To ensure the page names are unique, we can base their names on the name of the attribute-group.

A second interesting point about the specification of style, is that style is a List. We can specify simple String lists such as styleList as a comma-separated string, instead of embedding style objects.

The consequences of this IncludeSpec may not be just the creation of screen and event objects. After all we are in the include phase of patterns. What if we've written preInclude patterns on the screens? Well they get run too. After this pattern is run on attribute-group, the screen and event objects are created, and missing pattern phases are run on them immediately. To there will be a top-down pre-include phase for the new objects, a top-down extra-include phase, and possibly a bottom-up include phase depending on whether attribute-groups come before screens in the processing order. If these patterns also create objects, they too will have their patterns run. This rarely get as complicated as it sounds as if it might, and you don't need to think about it too much. As long as you put things in the right places, everything runs in the right order.

Typically if we generate one sibling from another, we want the generated one to run last in the order. The ordering can be specified in the meta-model object as a public int method, getPositionWithinParent(). So by returning 10 for attribute-group and 20 from screen, we are sure that attribute groups are tree walked before screens.

A word of warning. You have access to $this and $parent and might be tempted to add a child using velocity syntax, such as a setter you have created in the meta-model or the setX method. If you do this, JeeWiz will not recognise the object as a tree object for any of the tree-walks, pattern or template build, but it will be accessible for use by other objects in the normal manner. There are helper methods such as createModelObject that can be used, but over-using these can lead to confusion and timing problems.

Other Useful Pattern Tricks

We have seen script and xml separately, but there's nothing to stop you mixing both. Perhaps we can create a data maintenance screen, with access to the generated data maintenance pages. We'll add that in a site IncludeSpec, but only if there are any attribute-groups.

		#if ($this.attributeGroupList.size() > 0)
			 <this>
				<screen   name="Data Maintenance">
				  <menu>
		  #foreach ($attGroup in $this.attributeGroupList)
					<menu-item  link-caption="Maintain ${attGroup.name}"
									page="${attGroup.name}Search"
					/>
		  #end
				  </menu>
				</screen
			</this>
		#end 
		

We know how to add child objects to the current object, using <this>, and how to add siblings, using <parent>, but what if we want to add an object somewhere else? Well we can set the context object to be something other than the current object using $this.setPatternRootObject. To do this we need to get hold of the object in velocity that we want to make the context.

We can work upward from the currentObject eg. <code>$this.setPatternRootObject($parent.parent)</code>

Or downward from the top using $this.topComponent, which in our case is the site, eg.

		#foreach ($screen in $this.topComponent.screenList)
		  #if ($screen.name == "index")
			 #set($index = $screen)
		  #end
		#end
		$this.setPatternRootObject($screen)
		

Or if this is something we do a lot of, we can write helper methods such as getScreenObjectByName.

<code>setPatternRootObject</code> can be used in conjunction with the <this> syntax. Although the pattern context is changed, $this refers to the current object in the tree, that is the object whose pattern is being run, not the pattern context object on which new objects are to be created.

There's a similar directive <code>$this.addPatternRootElement("this")</code>, which can be used instead of an enclosing <code><this></code> or <code>$this.addPatternRootElement("parent")</code> instead of an enclosing parent. I'll come to the reason you might want to do that in a later tutorial, but I thought I'd mention it here, because it's easy to get setPatternRootObject and addPatternRootElement confused.

Chaining patterns is done using nextPattern eg <code>$this.nextPattern("spec2")</code>, which will look for a file called spec2.vm (the suffix defaults to vm) and run another pattern following the current one.

More about JSPs

This section isn't really about patterns and you won't miss too much in the way of JeeWiz techniques if you skip it. The example uses jsps rather than html, and if you want to understand what's going on a little better and haven't come across JSPs before, I hope this section will help. If this technology is all old hat to you, I'd move to the next section.

Servlets are java classes run on the server that respond to urls by writing the response using print or write statements. This is hard work if you want to write a servlet to send what is primarily text to the browser. As I mentioned before, when an anchor or a submit button sends to a jsp url, the server creates a servlet from the jsp file (after the first time it will reuse the servlet). Because of the transformation from jsp to servlet, the normal logic of a servlet is turned on its head, and any text in the jsp is automatically turned into output statements. You have to indicate what you want to remain as code. To do this you need to bracket the code with scriptlet indicators for java statements or expression indicators if you want a value to be output into the stream of html.

There are two syntaxes available. One uses <% and %> as scriptlet brackets and <%= and %> as expression brackets. For example <%=new java.util.Date()%> would insert the current date and time into the page.

The alternative xml format uses <jsp:scriplet> and </jsp:scriptlet> and <jsp:expression> and </jsp:expression>. Even though xml is normally the way to go, the short form has certain advantages, for example it can contain less than and greater than signs without using &lt; or &gt;. For more complicated xml data, it is wise to use CDATA brackets, and that is true for scriptlets, if the xml format is used. For the same expression in this syntax you can use <jsp:expression>new java.util.Date()</jsp:expression>.

It's worth thinking back to the first tutorial where I showed you how to use JeeWiz to insert the date using java as part of the page generation. The difference is one of timing. If JeeWiz uses velocity script to insert the date it will be the date when the jsp was generated. You could use that for the copyright year for example. All users of the page would get the same date. When the jsp code inserts the date-time, it's the date and time the servlet creates the page. So every user gets the date and time they got a response to their request.

This timing issue initially complicates understanding of the code generation of jsps. You have to think about code running at three different points in time. First JeeWiz is used to generate the jsp. Think of that as generate time. Then the web or application server uses the jsp file to create a servlet which generates the page. Think of that as pre-runtime. Finally, client-side scripting can alter the way a page is displayed in the browser. Think of that as runtime. Understanding the different times you want things to run is crucial to getting the syntax right in these type of files, velocity, scriptlet or javascript. If that sounds daunting, it shouldn't - it gets much easier with practice. For the example, I haven't used clientside javascript. Which you use often boils down to when the information is available, but there's sometimes design choices to be made. For example you could show people from different countries different information on a page, by

• generating different pages then diverting the users to their own set of pages.
• generating one page with scriptlet code that tested the user on the server and sent back different html to the browser.
• generating the page with javascript that sent all the information to the browser and only displayed the relevant data, perhaps depending on a field value.

The variability is handled in each case at different times. You might decide to generate different pages for different languages; scriptlet code for security, only delivering the sections that people are allowed to see; and javascript if the user is allowed to select country to show the price of an item in different currencies.

In converting to a servlet, the jsp has other things to offer. It can manipulate the page and the scriptlet using page directives eg <jsp:directive.page import="java.utils.*" /> which adds an import statement accessible to the scriplet code. It can declare methods and initialisers, include other jsp pages, forward to other pages, initialise beans and so on. All these things can be done directly as scriptlet code, but often they are simpler and easier using the inbuilt jsp syntax. The translation into the java servlet is often available (after the page has been loaded at least once) in the server directory. For Tomcat it's in the "work" subdirectory area.

The main jsp syntax gives you:

• directives: global information for the scriptlet translation
• actions: information for the execution of the servlet (in producing the response)
• scripting: java declarations, java scriptlet code and java expressions.

In the tutorial example, I've tried not to take it too far. I've used xml style syntax where there's a large block of code, and the short syntax where I'm mixing little bits of code with HTML output. I haven't used special tag libraries or EL expression language at all.

Tag libraries add to the commands and actions available to the jsp syntax, and can be used as a tighter way of controlling scriptlet style syntax. The standard JSTL core library is readily available. There's also an expression language syntax, allowing access to bean and system properties that can be used directly in tags. It's important to decide how much use of these facilities you want in your architecture as one of the big benefits of code generation is consistency, which can easily be lost unless you make a decision as to the philosophy of your output. There's also a level of complexity that comes with increasing indirection and there's a price to pay for it. Of course, if you get it wrong the first time around that's not the end of the world as with JeeWiz you can always tweak the architecture templates and regenerate.

Completing The Example

You've already met all the syntax and elements needed to generate a realistic architecture. I admit that the example is a little bit too lightweight for my own comfort, but a more heavyweight and robust architecture would just use more of the same.

I'm generating two new java classes that come directly from the attribute groups. First there is a java bean class, instances of which hold the data that is to be passed to the database from the page and vice-versa. Second there is a services class that uses jdbc to access the database via sql. It contains methods that accept and return data beans and is called by the jsp servlets to interface with the database. Both of these are created using templates, dataBean.vm and servicesBean.vm, called from the attribute group's build.xml. I've added a package property to the specification of the attribute groups, but I should probably have created a default property (so guess what one of the exercises is going to be).

The java classes need to be compiled before they are used by the server and this is done as an ant task from a new ant target called compile in the main build.xml.

I've beefed up the screen.vm template to handle the jsp aspects and to add in new elements. The first new area on the screen is a left hand side menu, which is used in the maintenance section to select which attribute group is to be maintained. Where the central area just used to handle sections of text, it not is made up of multiple components inside an html form. At the top, buttons are shown representing events styled as "top". Next down is the are for entering, showing or editing individual fields. These are displayed one on each line. Next down is an area for a grid showing multiple records. These are only shown in response to a search, where multiple rows might be returned from the database and may include links representing events associated with a particular record - these are styled "inline". Then comes the text section we had before. Finally comes the buttons representing events that aren't shown at the top or inline.

Events styled as buttons and links can both move the flow to another page and perhaps run action code (depending on their style), but I haven't implemented submission of form data for the links, only the buttons. That's enough what I wanted, and it means I didn't have to complicate matters using javascript to trigger a form submission.

One main aspect of screen.vm functionality, the passing of data between the browser and server and from screen to screen is sufficiently discrete and contiguous that I have moved it into a separate file called screenDataProcessing.vm and parsed that file into screen.vm at the beginning. If there is data held in a bean present in the request, the values are used in the screen display. That code means that when refreshing a page or forwarding to another, all that's necessary to get the page to show the data is to put the data in the request. The grid is populated using any data in an ArrayList of data beans.

I created meta-model elements for the attribute group, attribute and event.

I decided not to show the id value that I added as a primary key on the screens. Sometimes when generating screen-based html or code, that means I only want to work with the visible fields. I created a list on the attribute group meta-model class that returns all attributes except the autokey called noKeyList. This is just so I can use it in #foreach loops without having to test #if ($attribute.autokey) quite as often.

The database is assumed to be MySql, and a table creation schema is generated at site level using a template called dbSchema.vm. We'll see in the next tutorial what we'd have to do if we wanted to generate to a choice of database. I create a table for each attribute group, with a column for each attribute in the group. So as it's not necessary to specify or decipher primary keys, an extra column is added to the table which is a meaningless unique number specified as an autokey called oid. In MySql this is an auto_increment primary key, and the database does the work of ensuring that new records are given a unique key number.

One interesting design decision is when to generate new objects from templates on another object or to add it to the tree as an object in its own right (using a pattern) and then use a template on the new object type. Contrast the way that the maintenance screens are created as objects in the attribute group patterns and then rendered as jsps using a screen template, from the data bean which is rendered directly using a template from the attribute group. For the screen we already had a sophisticated rendering and several screens are produced for each attribute group. It would have been possible, but silly, to reproduce the screen rendering for each different screen type as different templates in the attribute group directly. This also gives us an advantage: if we subsequently model a page, all the extra functionality in the screen template that we've added to handle the maintenance pages is available to our modelled pages without extra work.

It is often worth thinking about this latter point when making a decision. If you think making data beans, with getters and setters, a generally modellable item - say bean, then using a pattern to create a bean object to handle the data bean would have been a reasonable thing to do.

Finally I wrote a context template that specifies access to the driver in a format understood by Tomcat, generating META-INF/context.xml, and a general web application resource reference in the WEB-INF/web.xml configuration file.

With this tutorial lesson we can start to see how entire applications are built, including configuration and deployment. There are choices and trade-offs both as to how the final application will be structured and how that structure is to be generated. One thing is certain, though: the popular frameworks will all use architectures that are considerably more complicated that this one. And all that complexity leads to more redundancy, more classes that have no unique business knowledge built in and that can be generated from the same original specification information and all the other classes.

Summary

• If you are going to generate an application to a specific architecture, it's a good idea to sort out a target architecture before working out what patterns and templates need to be written. In fact if you haven't already got a working example of something written using the structure you are aiming at it's probably a good idea to first write a small working example.
• Reading in the specification creates a java object tree, each object having a class and a type (which are usually the same thing). The template subdirectory is named for the type of the objects and contains patterns, templates, properties and methods.
• Templates are used to create output from the objects on the tree. Patterns are used to alter, create or delete objects on the tree.
• Patterns are run in three phases: pre-phase, extra-phase and main-phase. The object tree is walked once during each phase, top-down in the first two cases and bottom up in the main-phase. It is possible to order siblings in the tree walks using
• Each object on the tree can run a series of patterns associated with each phase. The first pattern in the series will usually be in the file preIncludeSpec.vm, extraIncludeSpec.vm and includeSpec.vm.
• The same JeeWiz/Velocity scripting language used for templates can be used for patterns. It is possible to include information from other files in a pattern using the #parse directive.
• To chain patterns into a series, use the nextPattern method.
• Each pattern has a context. Typically that will be the current tree object ($this) or it's parent. Which one can either be set using an xml syntax such <this> ... </this> or it can be set using the addPatternRootElement method. If you want to set the context to be something a different object you can use the method setPatternRootObject.
• When a pattern has been read in (and before the next pattern in the series is read in), any XML specification is treated as new object specification to be added to the tree as children of the context root element. So if the parent is the pattern context, the elements will be siblings of $this.
• If a pattern creates an object, that object (and any objects it in turn creates) will always have all three pattern phases applied to it.
• If you are creating several output artefacts from a single tree object, sometimes it's valuable to generalise one or more of the output objects as being of a certain type, and create a tree object of that type using a pattern.

Exercises

The results of the tutorial will be found in %jwhome%\examples\tutorial\04webapp. If you have an older release of JeeWiz without the tutorial, you may have to download it separately from here.

1. Get the example code working. The code has been tested on apache tomcat 6 and MySql version 4, although it should work on different versions of MySql. I've tried it using the 3.1 and 5.1 versions of the connector - but these have different packages/locations, so change the properties in the system.properties file accordingly if you want to use 5.1. The connection currently is configured to use root/root, and you might want to change that here too.
   
   Versions of Tomcat earlier than 5.5 might be problematic without some code changes. The location of the tomcat server is hardcoded in the tutorial\04webapp\build.xml in the deploy target. You will probably need to modify that.
   
   Once Tomcat and MySql are up and running, you'll need to generate and deploy the application (using ant deploy), and to apply the generated sql schema to mysql to create the tables. You can create a new database or use a current one, then source the schema.sql file in the tutorial output directory.
   
   Fire up the application in the web browser, by default on http://localhost:8080:/MySite/
   
   Go to the data maintenance page and maintain one of the tables. Got to the create page and insert a few records. Go to the search page and without adding any criteria, search. If everything is set up correctly this should return the rows you entered.
   
   
2. Move package from the specification to a property. At the moment the package is specified on each of the application groups in the assembly.xml. Remove it from there and add it to the component.properties (but check out exercise 3 below). Change the name of the package to something else. Add an extra application-group of your own. Rebuild the application and check that the output has created the right sub-directories under WEB-INF/classes. If you rerun the schema for the new attribute group, it will clear any data you entered as part of exercise 1, so if you care about that just run the part of the schema for the new table. We haven't included any SQL reserved word handling so be careful what you call your elements.
   
   
3. Create a data-bean object type (with or without a meta-model), create the tree object using a pattern and use the data-bean template to generate. The data-bean should take attributes as children. You'll need to create a subdirectory with a build.xml, and a template file. You can use the dataBean.vm as a template to begin with, making any appropriate changes. These aren't necessarily fully functioning java beans, and it's not necessary to implement every aspect of java beans. These are just simple data wrapper classes.
   
   Add a pattern to attribute-group that creates a data-bean object, you'll need to copy the information from the . Make sure you remove the build.xml reference to dataBean.vm in attribute-group.
   
   
4. • For those familiar with the j2ee technology, change the architecture to use a servlet to process the input then forward the output to a jsp. Store the dataBean or dataBeanArray in the request, so it will be forwarded to the jsp and can be used to display values.
     
     
     
     
     Servlets pick up information in doGet and doPost methods. Forwarding is done by creating a javax.servlet.RequestDispatcher, passing in the jsp name, then calling the dispatcher's forward method. Servlets need to be declared in the WEB-INF/web.xml.
     
     
   • If you aren't familiar with the j2ee technology, think about an architecture you are familiar with. List out all the types of objects needed to make the application work. List all the meta-model classes, patterns and template builds you would need, together with a brief description of each. If you would be using methods, should they go in a component method, or a meta-model?