Hi all,
As we all know, Tapestry employs lazy loading of pages/components/resources/etc all over the place in order to achieve performance. This is very good and how it has to be (in my opinion), but it has one unfortunate implication for developers -- errors can be spotted only when a particular feature is used at runtime, rather than at compile time. Worse yet, Tapestry is in general much more modular than frameworks like JSP, which makes it far more likely to reach and load certain code only in very specific and possibly rare situations. The practical problems that appear as a result can probably be summarized as the following:
- There is a greater "round-trip-time" for fixing problems in Tapestry, than say in Java: develop-compile-run-test-modify, rather than develop-compile-modify. A mistaken syntax of a component spec or an incorrect componentID would require running and testing to discover and fix, even though they are very simple bugs.
- Some problems may be caught only when the code reaches QA, or in the worst case, the customer. One example could be a template for a rarely used locale of a rarely used component. QA would probably need to have a rather exhaustive test plan to be able to spot that.
One way to resolve some of those issues is to use an automation tool like Spindle to generate and modify Tapestry components. Another one is to be able to validate as much as possible of your application at compile time, rather than at runtime.
In my spare time over the past week I developed just such a tool. It is a Java application at the moment, but can be very easily integrated with Ant, and as such it can become a part of your compile cycle. From personal experience, it can help out a lot in some situations. I ended up finding problems in apps written a while ago that I thought were working perfectly.
The "validator" performs the following tests on your Tapestry application:
- Tests the Application Specification integrity
- Tests the Component Specifications integrity of all components, starting from the ones defined in the Application Specification (pages and aliases), and continuing down the tree
- Tests the correspondence between bindings and parameters of embedded components
- Checks whether the Java classes referenced by the components are available
- Tests the validity of the bindings (at the moment only inherited bindings -- see below)
- Tests fully all templates for all locales. Locates all templates in the same location as the component specification, irrespective of whether it is on the file system or in a jar. Parses them and validates them in the same way as Tapestry.
- Tests all defined beans. Checks their Java classes and initializers.
- Tests the defined assets (private assets only at the moment)
I will release the source code publicly under an open source license (probably LGPL) soon, hopefully in a week or so.
For the moment, if you are willing to beta-test, please email me and I will send you a copy of the application and the source code.
In case you are interested, the following problems require further attention and assistance:
- Provide ability to avoid class loading in case the application uses special static initializers
- Provide ability to perform some sort of property path validation (one level deep, at least; more if the result is Tapestry-specific and hence known, e.g. components.* or assets.*). I have left that for later because I am not sure yet how to deal with the possibility of custom property helpers. Any suggestions would be welcome.
- Improve error reporting -- not fully consistent and not internationalizable yet
- Add a native Ant interface, so that the validator can function as a task within Ant's JVM
- Think of a good name :-)
Looking forward to your feedback,
-mb
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
