Try this...

In hivemodule.xml:

<service-point id="daoprovider" interface="com.yourcompany.ISessionDAOProvider">
   <invoke-factory>
      <construct class="com.yourcompany.impl.SessionDAOProviderImpl" />
   </invoke-factory>
</service-point>

ISessionDAOProvider.java:

public interface ISessionDAOProvider {
   public ISessionDAO getDAO();
   public boolean getDAOExists();
}

SessionDAOProviderImpl.java:

public class SessionDAOProviderImpl implements ISessionDAOProvider {

   private static final String DAO_KEY = "DAO_KEY";

   /**
    * HiveMind provides you with a proxy for the real request so that every time
    * you call a method on it it gets routed to the request that is associated
    * with the current thread.  magic...
    */
   private HttpServletRequest req;

   public SessionDAOProviderImpl(HttpServletRequest req) {
      this._req = req;
   }

   /**
    * retrieves the DAO from the session, creating it if it doesn't exist yet.
    */
   public ISessionDAO getDAO() {
      if (!exists()) {
         // ideally the implementation class would be specified externally...
         req.getSession().addAttribute(DAO_KEY, new SessionDAOImpl());
      } else {
         return (ISessionDAO) req.getSession().getAttribute(DAO_KEY);
      }
   }

   public boolean getDAOExists() {
      return req.getSession().getAttribute(DAO_KEY) != null;
   }
}

Wherever you need the ISessionDAO, just inject the daoprovider service
and call getDAO...

It's not ideal because you are sort of rolling your own persistence,
but it achieves the goal of hiding the implementation of the dao, and
I don't know of another way to do that.

-Mike

On 3/16/06, Adam Zimowski <[EMAIL PROTECTED]> wrote:
> How could I do this? I don't know Hivemind very well, yet because it's
> integrated with Tapestry I highly prefer it over Spring IOC. Any
> chance you may have an example?
>
> On 3/16/06, Mike Snare <[EMAIL PROTECTED]> wrote:
> > By the way, if any tap developers are reading this, it would be great
> > if you could declare an interface for an ASO similar to the way you
> > can for a service...
> >
> > -Mike
> >
> > On 3/16/06, Mike Snare <[EMAIL PROTECTED]> wrote:
> > > That will work, but doesn't enforce your intent on other developers
> > > (they would be free to inject the ASO as a SessionDAO and not an
> > > ISessionDAO).  Perhaps a better way would be to create a service whose
> > > sole purpose would be to retrieve an instance of the ISessionDAO from
> > > the ApplicationStateManager, which can be auto-wired to your
> > > ISessionDAORetriever service.  Noone would then know the type.
> > >
> > > -Mike
> > >
> > > On 3/16/06, Adam Zimowski <[EMAIL PROTECTED]> wrote:
> > > > Silly me :-)  How simple and elegant !  I've been thinking in the
> > > > spring context, yet Tap/Hivemind make it so simple..
> > > >
> > > > Thanks!
> > > >
> > > > On 3/16/06, Kristian Marinkovic <[EMAIL PROTECTED]> wrote:
> > > > > hi Adam,
> > > > >
> > > > > @InjectState("sessionDAO")
> > > > > public abstract ISessionDAO getSessionDAO();
> > > > >
> > > > > works fine too; i'm using it with tapestry-spring
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >              "Adam Zimowski"
> > > > >              <[EMAIL PROTECTED]
> > > > >              .com>                                                    
> > > > >   An
> > > > >                                         "Tapestry users"
> > > > >              16.03.2006 14:11           
> > > > > <[email protected]>
> > > > >                                                                      
> > > > > Kopie
> > > > >
> > > > >               Bitte antworten                                        
> > > > > Thema
> > > > >                     an                  POJO dependency injection 
> > > > > (with
> > > > >              "Tapestry users"           interface) into TAP4 
> > > > > application
> > > > >              <[EMAIL PROTECTED]
> > > > >              karta.apache.org>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hi there,
> > > > >
> > > > > I'd like to inject my DAOs from Hivemind as an interface such that my
> > > > > app is not aware of implementation. I only know I can do this:
> > > > >
> > > > > <contribution configuration-id="tapestry.state.ApplicationObjects">
> > > > >  <state-object name="sessionDAO" scope="application">
> > > > >   <create-instance class="data.dao.SessionDAO"/>
> > > > >  </state-object>
> > > > > </contribution>
> > > > >
> > > > > Then, in my class I'd do:
> > > > >
> > > > > @InjectState("sessionDAO")
> > > > > public abstract SessionDAO getSessionDAO();
> > > > >
> > > > > I have a few problems with this:
> > > > >
> > > > > 1) I'd like to inject an interface ISessionDAO, not the concrete
> > > > > implementation.
> > > > >
> > > > > 2) Question: will Hivemind give me a singleton? I don't want my DAO's
> > > > > be a bunch of short lived objects. I'd like to be sure they are
> > > > > singletons. I think they are because the scope is application, but I'm
> > > > > not sure.
> > > > >
> > > > > 3) I'd like to be able to inject it to other POJOs, not just Tapestry
> > > > > derived objects (pages, components, etc). I probably could use
> > > > > Registry object, but I really prefer to do this with annotations? They
> > > > > are so elegant.. Does Hivemind has annotation support ?
> > > > >
> > > > > As always, I appreciate your help up front.
> > > > >
> > > > > Regards,
> > > > > Adam
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > 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]
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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]

Reply via email to