Update: January 23, 2004

What is the Design Pattern Toolkit?

This tool automates the use of the best known application development practices. An expert in the art of developing a particular class of application (such as portlet, Web service, or JDBC bean) can encode the implementation steps that take application requirements and produce a complete, working application. The result of this encoding is called a pattern. Any developer can then apply that pattern (encoding the expert's intellectual capital) and generate other similar applications.

How does it work?

The model is an implicit XML schema that describes the information that is unique to the application being generated (such as property names used in a J2EE application's Java^TM beans, HTML input forms, and HttpRequest parameters). While each application has its own unique application definition (appdef), the appdefs for a class of applications all adhere to the schema that exactly describes what information is required in order to build an instance of that class of applications. An important feature of this toolkit is that the model's "schema" definition is completely under the control of the pattern developer, so that they can both minimize the information that users must put in in order to use the pattern and ensure that it is captured in a way most natural to the target developers. This allows each development community to develop their own streamlined method to gathering requirements and developing the associated applications.

The view is a collection of templates that contain the static common content of the Eclipse resources to be generated. Embedded in each template are template tags that direct the generation and insert data from the appdef into the generated output. There is no limit to the kind of resources that can be generated, and it is possible to decompose a template into multiple parts that are composed during the generation process. This unique feature makes it possible to develop separate "subtemplates" associated with different aspects of the target application. For example, generating parameters for methods (in both their declaration and their usage in code) follows a very similar pattern and repeats again and again throughout many different templates. With this toolkit, it is possible for the pattern developer to create a substructure in the model that drives method declarations and calling sequences as separate templates that are included in the appropriate places in the overall resource template.

The controller is specified in a separate component through a set of special XML tags that control when and how each pattern template is applied. These tags can be embedded in a template file as well, enabling detailed control over the generated artifacts (even down to the delimiters that are generated between text strings). The controller also has tags that allow data from multiple appdef files to be merged, enabling users of the pattern to "separate the concerns" and get a high degree of reuse of their input data. For example, the pattern developer can build a pattern that separates out the basic flow of the architecture from the naming conventions used in a particular organization. The specific requirements for the application will change from project to project, while the naming conventions may change only from organization to organization.

Users of a pattern provide an application definition (XML file) that conforms to the pattern's model(s) and apply the pattern to generate an end-to-end application consisting of a number of Eclipse resources across multiple Eclipse projects. Once the generation is complete, the appropriate building and validation actions are performed automatically. Depending on the pattern, it may be necessary to manually edit some of the generated resources in order to get a running application. Because of the possibility for manual edits, the toolkit supports "round tripping", where sections of the artifacts can be marked such that they are not changed during the generation process.