template package

The ModelAnt template package provides Ant scripting access to initiate template rendering. The whole package is organized around the Template concept. Thus this page describes the Template concept, whereas any other details could be found in the ant.doc documentation.

ModelAnt Template

The ModelAnt Templates descend from the JSPs, applying the conventions:

• The Templates are files with .jsp extensions
• The Templates are stored in context root directories
• Each Template is stored in a directory path relative to the context root, calculated out of the qualified Java class name the Template wraps (see the wraps directive) by replacing each dot (.) in it with a directory separator (/).
  Example:
  The Template that wraps java.util.ArrayList objects is stored as

  <context root dir>/java/util/ArrayList/<template name>.jsp

Supported JSP standard features

• page import directive
• scriptlets
• expressions
• request, response parameters
• out local variable

Not supported JSP features

• any page directives other than import one
• <%! global declarations
• tag libraries, replaced by the object-oriented features of the Templates and model element wrapper classes
• page, pageContext local variables

Added features

• page wraps directive
• wrapped variable

The wraps directive states the class of the object this Template renders, which actually is the class of the wrapped local variable. The instance the Template renders is provided in the wrapped local variable. The scriptlets and the expressions just access the provided wrapped object, call its methods or navigate its associations. The wrapped variable is never null.

Applying a template through ModelAnt script

A Template is always applied to an object. In ModelAnt scripts the objects are held in properties as their values. Before applying a template, its context should be initialized by calling once:

<template.init root=”root directory” context=”context directory” classpathref=”classpath id”/>

Where the root directory is the directory where all context directories are collected. It could be either absolute directory in the local file system or a directory to be found in classpath. The context directory is relative to the root directory where to search the Templates from.

The simplest way to apply a Template on an object is:

<template context=”…” method=”…” file=”…”/>

where the context attribute refers the context root directory, the method attribute refers the template name. This form applies the template on the object held in this property. The absolute name of the template is <root dir>/<context>/<class dir>/<method>.jsp where the class directory is identified by replacing the dots (‘.’) with slashes (‘/’) in the qualified name of the class of the object to apply the template to.

More examples on Templates usage could be found in the documentation of template task.

Reasons for restricting JSP features in ModelAnt Templates

1.  The use of JSP declarations allows usage of attributes/fields of the JSP itself, which makes the JSP stateful, i.e. the JSP can keep their own state in instance or class attributes and this state may affect their behavior independently of the requests, not reflecting the state of the objects being rendered. This makes the stateful JSPs uncontrollable.
2. The page and session context also make the JSPs stateful.
3. The request context cares request-specific parameters and may be used as a temporary storage of specific values, that also may be used as a request-level state, but it should be considered only as a function of the request parameters. Thus, the request-level state keeping is still controllable and thus it is acceptable.
4. The use of JSP declarations allow creation and usage of methods of the JSP itself, which makes their reuse in other JSPs impossible, while imposing procedural programming within the JSP itself and allowing even complex business logic to be implemented in JSPs, making them something other than a view of the model (object) to be rendered. Thus, not supporting declarations in ModelAnt Templates does not allow implementing complex or business logic in templates and impose keeping it in the model (object) to render.
5. The <%@include file=”…”%> directive introduces clearly scripting practices, which proved not manageable in the experience of ModelAnt working with several hundreds of pages.
6. Thus, not supporting declarations, page and session contexts in ModelAnt Template makes them stateless and imposes usage of methods of the objects being rendered, this way pushing object-oriented programming in the presentation tier of ModelAnt Templates.
7. Making the JSPs stateless also makes obsolete the “isThreadSafe” directive.
8. The nature of the tag-libraries is to implement in some classes logic to render instances of other classes. This pushes procedural programming into the presentation logic of an object-oriented system. In addition the tag-libraries add various, not standardized complex scripting features and thus new languages in the presentation tier. These three paradigms just do not fit. Thus, not supporting tag-libraries in ModelAnt Templates makes them use only one language (Java) in expressing the presentation (view) logic of the template and pushes the complex logic in the objects to render, this way allowing inheritance and polymorphism (OOP) in the presentation logic. This makes obsolete any tags and directives for tag-libraries in ModelAnt Templates.
9. The JSP include() and forward() methods and <jsp:include>, <jsp:forward> are no more supported in ModelAnt Templates – they are replaced by the inherited method render(<object>) explicitly providing the object to render. This way any inclusion/reuse of a template generated contents is done by explicitly rendering an object, allowing OOP. In ModelAnt calling a template always requires an object to render, so the ModelAnt Templates are considered as added “visual methods” of the objects they render.