Simplify, Simplify

Getting more and more interesting things done in the Tapestry 3.1 code base is getting easier and easier.

One complaint I've gotten about Tapestry 3.0 is that, even if you use all implicit style components on a page, you still need to provide an XML page specification, just to specify the page class name.

I just checked in some changes to how page class names are determined; there's now an chain of command, that starts with the page specification itself, and ends with a default page class name.

In the middle is a new workhorse: NamespaceClassSearchPageClassProvider. This short little class gets a property from the namespace (the containing application or library specification). The property is a list of package names to search, looking for the page's class. So you might add <meta key="org.apache.tapestry.page-class-packages" value="org.mycompany.myproject"/> to the application specification, and just put your page classes into the org.mycompany.myproject package. And you're done.

It's a command separated list of package names, so you can have a couple of packages to search.

I think, gradually, the XML side of Tapestry will wither. I already have plans to support JDK 1.5 annotations in Tapestry to control a lot of the things you would currently do using XML ... and for some things, the XML is still the best approach.

I suspect that in the Tapestry 4.0 time frame, we'll re-organize the artifact triumvirate (specification, class, template) such that we start with the page or component class, then locate the optional specification and template. In 3.1 (and earlier) we start with the page name, find the spec, determine the page class from the spec.