Thanks for the expansion - I'd already implemented James' suggestion but it
took me a while to work out I needed to inject the ApplicationStateManager.
I think your suggestion doesn't quite work for my problem because the
interfaces need to be different. My service provides an interface based on
business objects (e.g. Region getRegion()) while the state object needs to
store the object's ids/keys (e.g. long getRegionId()).
However, it seems to me that this problem that we have business objects that we
need to turn into keys and back again comes up in several places. It's
something I need to do for passing business objects via URLs (and so I
implement a SqueezeAdaptor), something I need for ASOs (as above) and it looks
like something I'll need if I mark as persistent a page property that is a
business object.
It would be easy to write an implementation of an 'ObjectIdentifier' service -
for example, a Hibernate-based implementation would be trivial.
interface ObjectIdentifier {
Class getIdType();
Serializable getIdFromObject(Object source);
Object getObjectFromId(Class objectType, Serializable id);
}
I can imagine writing a SqueezeAdaptor based on this (perhaps with an option to
bind prefixes to classes for commonly-squeezed types).
I can also imagine writing a StateObjectPersistenceManager that uses reflection
to pull the fields from an ASO, processes them through the ObjectIdentifier
(leaving primitives & unknown objects unchanged) and persists the
keys/primitives/unknowns.
Looks like I could implement a PropertyPersistenceStrategy with this too to
handle the page properties. Although I think this would ideally need to act as
a decorator for the existing services (e.g. 'businessObjects:session',
'businessObjects:client' etc.) and I can't see an obvious way to do that...
I imagine these three implementations would share a common ObjectIdentification
service to which clients could contribute their own ObjectIdentifiers.
Any thoughts on whether this is a sensible idea? I'm happy to write and share
some code but I've only just started on T4/HiveMind and wouldn't mind some
feedback before I head down a dumb path.
Paul
------------------
Paul Field
Global Markets Research IT
Deutsche Bank
news <[EMAIL PROTECTED]> wrote on 04/05/2006 16:33:05:
> Expanding on what James said and following up on a hint given by Howard
> in an earlier thread, I have been using the approach of injecting the
> ASO into services using the following approach: 1) create a proxy object
> that implements the same interface as the ASO, 2) the proxy is a
> threaded/pooled hivemind service, 3) the ApplicationStateManager is
> injected into the proxy, 4) when a method is called on the proxy, it
> looks up the ASO (which is the correct one due to the proxy being
> threaded) and passes through the method call.
>
> I inject the proxy into any service/dao that needs information from the ASO.
>
> It would be a nice enhancement in tapestry if such ASO proxies could be
> automatically created.
>
> -- Mark
>
> James Carman wrote:
> > Create a service which returns the "current" business object. That service
> > can lookup the ASO and get the key. Then, your client code just calls the
> > service.
> >
> > -----Original Message-----
> > From: Paul Field [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, May 02, 2006 11:46 AM
> > To: tapestry-user@jakarta.apache.org
> > Subject: Is it safe to inject HiveMind services into an ASO?
> >
> >
> > I would like to use an ASO that contains a business object. However, I
> > can't store the business object directly in the ASO because (a) it will be
> > serialized into the session (along with a lot of related objects) (b) it is
> > associated with a particular database session so needs to be re-created on
> > each request to ensure consistency.
> >
> > So, instead, I'm storing the key of the business object in the ASO. However,
> > that means that every piece of client code needs to know how to turn the key
> > into the business object - in my case, by knowing a data access object (DAO)
> > that can do it for them. So, here's an example ASO showing my current
> > approach:
> >
> > public class Preferences implements Serializable {
> > private long regionId;
> >
> > public Region getRegion(RegionDAO dao) {
> > return dao.getRegionForId(regionId);
> > }
> >
> > public void setRegion(Region region) {
> > regionId = region.getId();
> > }
> > }
> >
> >
> > What I would really like to do is use HiveMind to inject the DAO and make my
> > ASO something like this:
> >
> > public class Preferences implements Serializable {
> > private transient RegionDAO dao;
> > private long regionId;
> >
> > public void setRegionDAO(RegionDAO newDao) {
> > dao = newDao;
> > }
> >
> > public Region getRegion() {
> > return dao.getRegionForId(regionId);
> > }
> >
> > public void setRegion(Region region) {
> > regionId = region.getId();
> > }
> > }
> >
> >
> > So, I'd like to know if this is a safe thing to do. Assuming the preferences
> > might get serialized and re-loaded by the app server or passed around a
> > cluster, how do I make sure that the RegionDAO stays injected but doesn't
> > end up serializing itself (unless it can serialize some kind of stub).
> >
> > Thanks,
> >
> > Paul
> >
> > ------------------
> > Paul Field
> > Global Markets Research IT
> > Deutsche Bank
> > ---
> >
> > This e-mail may contain confidential and/or privileged information. If you
> > are not the intended recipient (or have received this e-mail in error)
> > please notify the sender immediately and destroy this e-mail. Any
> > unauthorized copying, disclosure or distribution of the material in this
> > e-mail is strictly forbidden.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
