> > Obviously, that is not the most elegant way to do it. You could add code
> to all
> > those classes which basically boils down to the following in TurbineUser:
> > public String getAddress1() {
> > return (String)data.getUser().getPerm(TurbineUserPeer.ADDRESS1);
> > }
> >
>
> You should extend TurbineUser and add methods like the above to it.
>
> > The problem with doing that, however, is that to get to it from RunData,
> you'd
> > have to cast the value returned by getUser(). For example:
> > TurbineUser turbineUser = (TurbineUser)data.getUser();
> > String address1 = turbineUser.getAddress1();
> >
>
> I do not see anything that inelegant about the above. I would give it as
> the standard way to access methods in a XUser that are not in the User
> interface.
>
Yeah, you're right. I didn't mean to make that sound like an unrecommended
technique.
> > > Or is it better to use Torque to produce these components?
> > >
>
> Not a bad way to go either (assuming Torque is generating business objects
> now). But it does not get around the casting issue above.
>
It does generate the OM classes - see ../torque/XMLSchemaToObjectModel. However,
the real trick is adding the functionality required by the User interface, which
it doesn't do (and is probably outside the scope of Torque).
--
Christopher Elkins
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
