At the moment I'm working on a data entry system that has quite a few
(>50) data entry forms that all virtually identical. Each of these
needs to be able to work with the appropriate Peer objects for the data
entry form. This is a problem with Torque, as most of the useful
methods (getMapBuilder / doSelect etc) are static methods which can't be
called generically without reflection.
Reflection is bad... well not so much bad, but means that you end up
having errors at runtime rather than compile time where they should be.
So I've created a whole lot of classes which are effectively adapters
that have non-static equivalents of the static Peer methods. But this
is tedious and in my opinion could be part of Torque anyway.
As an example consider table Example, with a BasePeer => BaseExamplePeer
We would then create
public class BaseExamplePeerAdapter extends BasePeerAdapter {
public List doSelect(Criteria c) throws TorqueException {
return BaseExamplePeer.doSelect(c);
}
etc etc
}
Torque would also produce a template ExamplePeerAdapter for user code.
Usage:
Now, these classes can be passed around and the behaviour of other code
isn't hardwired to a specific table.
eg.
public List search(BasePeerAdapter a, String columnname, String value)
throws TorqueException {
Criteria c = new Criteria();
c.add(columnname, value);
return a.doSelect(c);
}
My questions are:
1. Have I gone and reinvented the wheel? (I don't see anything like this
in Torque as yet)
2. Does anyone have any preferences for names of these adapter classes
before I submit patches for them?
Regards
Ben
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
