As far as plugging in different persistence mechanisms, one of the thoughts I had about Fulcrum and it's user security service is that even though you can provide your own implementation of the user/peer classes, it's heavily biased towards using a Torque-generation solution.
Which actually isn't that bad, but what if Torque could also offer, say, a JDO interface? I've been briefly researching OJB lately and I'm impressed that they have several different ways to talk to their internal core, one of them being JDO. What are the current feelings about JDO? Would it be desirable for Torque to implement it as then services like Fulcrum could use a truly standard (?) way to talk to persistent objects? Fulcrum could then ship with the default Torque-generated JDO compliant classes but let users plug in completely different implementations. - Stephen > -----Original Message----- > From: Brekke, Jeff [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 22, 2002 12:36 PM > To: 'Turbine Torque Developers List' > Subject: RE: refactoring the om templates into separate classes > > Sounds interesting. I like to concentrate on developing my objects and how > they behave and sprinkle in persistant storage later. > It might be interesting to have torque generate an interface layer and then > one implementation based on torque internals. This way all the torque could > really be hidden from the user of the interfaces. This may also provide the > ability to generate a mock implementation for testing code that uses these > objects. Or even some other persistance mech, xml, serialzation, etc. > > ===================================================== > ============ > Jeffrey D. Brekke Quad/Graphics > [EMAIL PROTECTED] http://www.qg.com > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
