Sean Legassick wrote:
>
> On 2000.11.29 22:33:34 +0000 John McNally wrote:
> > My solution
> > after a couple minutes thought is to extend or build around a TreeMap
> > with keys being the pk column names and values being the pk values. The
> > toString() could give something like 121:2:45888 as the id where the
> > separator can be set. So that the id representation does not have to
> > contain the key names I will add a String vector to the Peers that
> > defines the order.
>
> That sounds like a pretty good solution for a couple of minutes thought :-)
>
> And that would certainly address my concern...
>
> +1
>
Not a good enough solution, though, I am afraid. I am thinking the base
objects produced by torque should just implement their own getId and
setId methods. A simple example with a single column id.
public class Foo extends BaseObject
{
int foo_id;
String name;
public void setFooId(int v) {foo_id=v;}
public void setName(Strng v) {name=v;}
public int getFooId() {return foo_id;}
public String getName() {return name;}
// my proposal
public void setId(Object id)
{
// maybe add try block
foo_id = Integer.parseInt(id.toString());
}
public Object getId() { return new Integer(foo_id);}
}
The getId/setId problem can be solved easily here through torque, by
setting the JavaName attribute to "Id". (Though this is only true due to
getId being defined in BaseObject as returning an int, something I would
like to change.)
But I think the new approach is more flexible. For example if the class
corresponds to a table with two pk columns:
public class FooBar extends BaseObject
{
int foo_id;
int bar_id;
String name;
public void setFooId(int v) {foo_id=v;}
public void setBarId(int v) {bar_id=v;}
public void setName(Strng v) {name=v;}
public int getFooId() {return foo_id;}
public int getBarId() {return bar_id;}
public String getName() {return name;}
// my proposal
public void setId(Object id)
{
StringTokenizer st = new ST(id.toString(), ":");
foo_id = Integer.parseInt(st.nextToken());
bar_id = Integer.parseInt(st.nextToken());
}
public Object getId()
{
return foo_id + ":" + bar_id;
}
}
My earlier idea made it more difficult to manipulate the simple
attributes that make up the OID. The object itself, other business
objects, and the peer(s) can make use of the simple attributes, while
the ui/application layer (modules) would primarily be concerned with the
possibly composite getId/setId methods.
The one major change this entails is resetting the return type of the
getId() method in BaseObject to Object. I wanted to do this some time
ago, when I was upgrading IDBroker and BasePeer, but was hesitant to
make the change and instead added a getIdAsObject() method. I really
want the main getId method to get away from the association with the
int. There is a getIdAsInt() method that can be substituted where a
current app is assuming getId() returns an int.
Thoughts and any concerns reqarding the change to BaseObject?
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
