Large scale Tapestry approaches

In a previous post I mentioned some ideas that came out of my talks with the folks at Intelligent Works.

Their problem, which is not too uncommon, is that they are adding additional lines of business to their existing app. They already have about 100 pages, most of which are CRUD (Create Read Update Delete) for their existing object model.

Now they are adding new lines of business that extend their object model with new subclasses. In many cases, the high level looks very similar, and they are only seeing differences fairly low in the navigation tree. That is, a Work Order looks much like a Purchase Order (with a couple of fields swapped out), and the real differences don't crop up until you drill down to the line item level or below.

So, I came up with some solutions off the top of my head ...

Smart Components

Use the same pages, but have smart components that are responsible for editting the details of the object. These smart components, built around Block and RenderBlock, can mix-and-match a user interface on the fly, drawing appropiate components from Blocks on secondary pages.

This kind of approach means that WYSIWYG preview goes out the window, the page becomes a kind of shell whose job is to just set the stage: what object is being editted and how. At multiple layers below, the smart components are complex conditionals to provide the right UI for the particular type of object being editted.

For IW, there might be an EditAnyOrder page used for editting both Work Orders and Purchase Orders. Again, within this single page, and even within components within other components within the page, there will be dynamic logic to choose the right UI (both static and components).

This is a very powerful approach that leverages the dynamic nature of Tapestry. I'm concerned, however, that finding and fixing bugs will be too complex ... that there will be too much detective work to find where a particular text field comes from ... and too many unwanted side-effects of changes because components and code are being shared in an obscure way.

Dynamic Page Assembly

Tapestry has a bunch of hooks that allow a careful developer to extend or even replace the way Tapestry locates page and components specifications and templates. In theory (and I haven't tried this yet), you could magically "brew up" an EditPurchaseOrder page on the fly. The framework would not care that the specifications and even templates were constructed on the fly, rather than read from static files.

There could be a bit of magic involved in this ... parsing the page name ("EditPurchaseOrder") to figure out how to create the necessary page (some kind of template for "Edit", plus the PurchaseOrder type, plus specific extensions for editting Purchase Orders). What this kind of mapping would look like is more than I can come up with on my feet.

Template Driven Development

The question is: do you need to really assemble it all on the fly? If you know you are going to need an Edit page for Work Orders and Purchase Orders, can you use a templating system to do it. I've been using XDoclet at work lately, and it seems reasonable to use XDoclet to create page and component specifications from Java classes ... if you can figure out XDoclet and come up with the necessary rules, you could have a single Java class (public abstract class EditAnyOrder ....) and from that, generate more Java classes and page specifications (EditWorkOrder, EditPurchaseOrder).

Perhaps Velocity, in the guise of VPP (Velocity Pre-Processor) is more appropriate for generating page and component templates.

I tend to like this solution, because it moves the difficult decision making into the build phase. There are still lots of unknowns.

Other ideas

Long time Tapestry user Jiri Lundak has built a framework on top of Tapestry to address these issues: MetaworkX. I haven't looked at the code or design (yet -- so much to do!) but he's been at this for a while and probably has something clever up his sleeve.