Tapestry 3.1 plan

[Steve Gibson <St...@cowww.com>]

Our team has chosen Tapestry for the new version of our software, and at
least half of the team is also sold on HiveMind.
 
The problem is, some of what we will be doing for our first release
(which is really our old version with some tapestry facades) will be
parallel to work being done on Tapestry 3.1. I can see this will be
costly, but I can't see any other way forward than to integrate  them
(and try to remember YAGNI) and monitor what changes are brewing in the
3.1 development.
 
Its bad enough that we are hooked on HiveMind and it is in beta,  but to
base our (admittedly small for this release) ui on snapshots of early
development doesn't sound wise to me.
 
So my question is, what would be the least cost method of hooking them
together?
 
I have toyed with a few approaches (and I have seen the HiveMind servlet
filter).
One of them that I have in a working prototype extends BaseEngine and
puts the registry instance in the Global object (in setupForRequest -
the first time). The engine has a getHiveMindService method, the Visit
(we currently have a custom Visit class) has convenience methods in it.
It all looks messy and a lot of casting (Visit,Engine,Service).
 
I am also looking at having the engine put the Registry in the Global
object still, but subclassing BasePage to have a method for retrieving
the Registry (or Module) from Global. Components that need to consume a
service could call methods on their containing page OR I could have the
page attach the service to itself as a bean (might be nicer in the OGNL
also.
 
Another alternative is to modify IEngine, AbstractEngine and BaseEngine
so that getService has two signatures:
Object getService(String name, Class serviceClass)
IEngineService getService(String name)
 
Ideas anyone?
 
Steve Gibson
Software Engineer
COWWW Software