db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Holcomb <w...@himinbi.org>
Subject buildCriteria inheritance problem
Date Tue, 17 Dec 2002 00:21:20 GMT
I thought that I sent this the other day, but it appears to have 
disappeared. =)

I have three programs that all use the Turbine user management system. One 
of them is a web board program. In it the user peer class looks like this:

java.lang.Object
    |
    +--org.apache.torque.util.BasePeer
      |
      +--org.apache.turbine.om.security.peer.TurbineUserPeer
        |
        +--org.himinbi.turbine.util.TurbineUserPeerAdapter
          |
          +--org.himinbi.directory.om.BaseDirectoryUserPeer
            |
            +--org.himinbi.directory.om.DirectoryUserPeer

The issue at hand is that BaseDirectoryUserPeer makes a call to static
void buildCriteria(ObjectKey). There is no such method in TurbineUser, so 
it fails. I would just define it in TurbineUserPeerAdapter except the 
implementation needs to look like:

public static Criteria buildCriteria( ObjectKey pk ) {
   return new Criteria().add(USER_ID, pk);
}

USER_ID is a static field defined in BaseDirectoryUserPeer and so getting 
access to it in the superclass is difficult. Actually I can't come up with 
a way at all. Options I have considered:

1. abstract String getIdColumnName(). Problem is that I can't access an 
    abstract method from within a static context. I thought perhaps I 
    could create a static instance and then call the abstract method on 
    that instance, but there is no way to find out the subclass name from 
    within a static context to the best of my knowledge.

2. reflection. getClass() cannot be called from in a static context. This 
    is the reason creating an instance isn't possible using reflection.

3. special constructor. I don't control the code in the 
    BaseDirectoryUserPeer and it can be overwritten by the build process, 
    so I could do this, but it will break if I ever change the schema and 
    regenerate the Base* classes.

Options that don't actually get access in the superclass, but will work 
are:

1. Having the DirectoryUserPeer initialize the TurbineUserPeerAdapter 
    using a static initializer.

2. Defining a separate adapter for each project that accesses the Turbine 
    user management system. Each adapter can then make specific access to 
    the static fields in the subclasses.

Both of these though require redundant code every time I use the adapter. 
Does anyone know a way for me to avoid that?

Will


Mime
View raw message