Ideally, your state objects should be as simple and small as possible
-- if for no other reason than to make sure your app can cluster if
required. Also, if you're using a service then you're probably
performing business logic and a state object is probably not the best
place for this. I'm talking about session-scoped ASO's here and not
global ASO's. I could see injected services making more sense in a
global ASO but it still seems like the wrong architecture.
In any event, to get this functionality in a clean way Tapestry/
HiveMind would have to support re-injection on deserialization as you
mention, and I don't think that is or very likely will be supported
(not to discourage you from looking -- I could certainly be wrong).
I'm not sure if you're also asking about general Tapestry/Spring
integration, but I recently switched from a custom solution based on
the info at http://wiki.apache.org/tapestry/Tapestry4Spring to
Howard's tapestry-spring plugin (http://howardlewisship.com/tapestry-
javaforge/tapestry-spring/). I literally just ripped out my old
stuff, dropped in the tapestry-spring jar and was up and running. I
don't think the plugin is any "better" than the solution on the wiki,
but having only 1 jar vs a few classes and HiveMind wiring is nice.
If you can outline why you need to inject services into your state
objects in the first place, maybe I can offer an alternate solution.
The (rather large) application my team is working on at the moment
uses Spring beans extensively in Tapestry pages and components and
I've never had the need or desire to inject them into state objects.
Not to say that there couldn't be a legitimate reason to do it, I
just haven't run into it yet.
-Ryan
On Aug 14, 2006, at 1:42 PM, Michael Prescott wrote:
We've got an application state object into which we're injecting some
beans from Spring. Over time we've tried a number of approaches to
this.
Under Tapestry 3, we'd cobbled this together with some code in a
pageBeginRender() listener in a base page class. The pages had access
to the Spring context more directly, so as each page started to
render,
it would "manually" inject the Visit with a number of these beans from
Spring.
This smelled a bit, so under Tapestry 4 we moved to a model where
we're
injecting via Hivemind. We have a StateObjectFactory which pulls what
we need out of Spring as Visits are created.
The problem is that this approach is incompatible with persistent
sessions: the beans we're injecting from Spring are all trussed up
with
proxies and aspects, so they're not in the least bit serializable. It
would be lovely if the framework could handle this for us, so that we
could just use @InjectSpring right inside state objects, and the
framework would take care of re-injecting as necessary (e.g. when the
deserialized value is null).
Maybe keeping this sort of stuff out of state objects is a good idea.
It's a natural factoring, given what we're doing, but this seems to
make
it inadvisable.
Anyone else had to deal with this?
Thanks,
Michael Prescott
Ryan Holmes, CISSP
[EMAIL PROTECTED]
ph. (213) 626-0026
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
