This section describes how a simple pattern can be used to generate a set of XML-aware beans and how that pattern can be modified
A common function for client/server code is the ability to pass arbitrary networks of java objects across a remote call. This pattern takes as input the class names and property names and types (types can be other beans) and generates a set of beans that not only have getter and setter methods, but also have the ability to initialize themselves from a DOM and to be able to write an XML representation of themselves on request. These behaviors are used by another generated class that accepts a network of objects as input, sends an XML representation of those objects on a remote call (we dummy up a web service call), get an XML response back and reconstructs the returned network of objects from that XML. There are better ways to implement this function, but this exercise assumes that the developer has settled on this design as the desired pattern to repeat across multiple applications.
To begin working with the pattern,
To generate some files from the file sample.appdef, select sample.appdef from the Navigator view in Eclipse, right-mouse-button-click and select "Apply Pattern". If there is only one pattern found by the tooling then the generation will take place now. If, however, there are multiple patterns available, you will be prompted for the pattern to use. If prompted, choose "XML Bean Pattern".
The message box displayed when the generation completes shows that 10 files were generated and that the requirements file (sample.appdef) was accessed over a thousand times. This means that if you were to code the 10 files by hand, you would have referred to the requirements over a thousand times. If you were able to code to the requirements with an accuracy of 99%, you would have introduced 10 bugs into the code while you typed.
Note: The may be compile errors if the xerces jars (for XML) are in a different location on your computer than they are on mine. A simple correction to the java project’s java build path will correct the problems. You can change the pattern to produce the correct java classpath by modifying the classpath.pat template (see below).
You can change the requirements to see how the code would be generated differently. Edit and save your changes to sample.appdef. You can change the package name, class names, property names and types (just don’t put a cycle in your network - this pattern is too simple for that). Delete the files that were previously generated and re-apply the pattern. You’ll see new classes generated to the requirements you specified.
You can change the pattern.
Patterns can be deployed in a read-only form (in .patzip files) and any patzip files found in the patterns directory (specified in the patterns preference page) can be applied to an appdef file. To modify a pattern, you can import it into a pattern project in Eclipse:
Now when you apply a pattern to an appdef file, you’ll see two versions of the XML Beans pattern displayed: one is the original pattern in the patterns directory and the other (it’s name is followed by the project name in brackets) is the pattern you can modify in the pattern project. You may apply either pattern to the appdef file.
What’s in the pattern:
Since all three components (model, view and controller) are under your control, you may modify any or all of them to produce the correct pattern and applications you need. Try some of the following simple changes:
© Copyright IBM Corporation 2000,
2005. All Rights Reserved.