Thanks, but I don't want the applets to see Torque interfaces, nor chew
up connections. I'm keen to keep them 'thin' and keep the business logic
and database tiers on the server. They must, however, gain access to
bean heirachies that represent my data model.
I think that I'll have to customise my BaseObject derivatives with
set/get methods that read and return beans, respectively. Ho hum.
Perhaps this would be a useful feature in later generations of Torque?
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 8/8/01, 2:06:43 AM, Andres Portillo <[EMAIL PROTECTED]>
wrote regarding Re: Torque<->javabeans for client side data:
> This is not just specific to Torque, but if you are planning to
deploy
> your applets in an Intranet (no firewall issues), you can use the Torque
> classes inside your applet (I know they can be used in standalone apps,
so I
> suppose they can be used inside applets), in this way your applet will
> communicate with your DB using JDBC.
> You have to be careful regarding the scalability of this approach,
since
> each applet will use one DB connection at least, you can run out of them
very
> quickly.
> andres
> Jason Grant wrote:
> > I have an number of applets that are served up via turbine/velocity
> > templates, and require access to the getters/setters on my [nested]
> > Torque om objects. My first reaction is to write a parallel set of bean
> > classes for passage to the applets via serialization - this way, the
> > applets do not see Torque interfaces. A problem with this approach
> > however, is that the marshalling code for om<->bean conversion promises
> > to be tedious to write and maintain.
> >
> > I suppose I could also write an ant task to generate the code for me
> > (like TorqueObjectModelTask), however this seems like overkill too.
> >
> > Is there a less painful way to make Torque data available to the applets?
> >
> > Thanks.
> >
> > J.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> --
> =============================================
> Andres G. Portillo D.
> Software Engineer
> Veratech (www.veratech.com.mx)
> =============================================
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
