+1 This would be useful for other things than SOAP toolkits also. On Wed, 15 Jan 2003, Bill Schneider wrote:
> This is an excellent question and probably depends to a large extent on what > kind of SOAP toolkit you're using. Perhaps you could rig the Velocity > templates that spit out Java objects, such that they create an interface for > each data object with just the get/set methods, and the actual Torque > objects implement these get/set methods. Any copy-from-object methods in > the Torque objects would have to accept the interface rather than the Torque > type. > > Then you would define your SOAP service as accepting or returning objects > that implement that interface with only get/set methods. > > -- Bill > > > I'll need to transfer the data beans through soap serialization from the > > back-end to some front-end sites. The Torque generated classes however are > > not pure data beans. They have a save method and other functionality in > the > > super classes. They also import certain torque classes. This would mean > all > > the front-end clients would need to have the torque jar installed. It > would > > also make serialization/mapping a lot harder. Is there a way to easily map > > these classes to pure data beans (with nothing but getters/setter for > their > > properties), without manually creating and mapping these (which would > sorta > > nullify the benefit of having your classes generated)? > > > > Secondly, what exactly is the difference between Jakarta Torque and > Jakarta > > OJB? What are the pro's and con's of each and when is one recommended over > > the other? > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- ===================================================================== Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
