First of all, thanks to you both for responding. I was afraid the bluntness of my comments would elicit nothing but rejection of the ideas.
"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote: >Stephen Haberman <[EMAIL PROTECTED]> writes: > >>maintainable code), Torque would require either: > >>- Huge amounts of evolution to incrementally fix/refactor all of the >> relatively messy issues with it (and no unit tests to help you go >>by). To me this would result in such a bandaged mess as to make it >>not worthwhile. I don't think the amount of work is huge. Most of the code changes that I think are necessary should go in BasePeer, and we could write unit-tests as we go along. >>Or: > >>- A complete revolution starting with a new architecture complete >>with the stuff like PreparedStatements, etc., and filling in the >>gaps with rewritten and/or refactored existing code. Again, I don't think we need a revolution, just evolution. The basics of the system are sound, it just seems as if it was written like a prototype. >Martins' idea seemed better to me: > >- Separate the template based engine which creates java classes from > templates from the actual persistence code. I'm not entirely sure what you're proposing here, but I think you're suggesting keeping the save() and related methods out of the OM objects entirely. It would definitely make more sense to me if the save() methods were static methods on the Peer instead, but there are implementation details that would need to be resolved. I think as long as the Peer and the OM are in the same package, the OM could provide simple hooks for the Peer to do what it needs. >- Scrap the persistence code and replace it with OJB (or something > else; I have a 90% ready implementation based on player > (http://player.sourceforge.net) which uses really lightweight > objects and a pluggable selection / criteria code but I never really > went to finish it. Any takers? :-) But I guess, there are about a bazillon > self-rolled persistence layers out there). I'm not in favor of simply replacing the existing persistence layer with any other persistence layer out there. There are so many APIs out there that it's hard to make sense of them all and compare and contrast them. Why bother? Torque should be self-sufficient if it has any chance of surviving on its own merits. If Torque is at the mercy of bugs in another API, it's less viable. And worse, it will probably have to resort to inefficient convoluted code to work with ANY other API that had different design goals. As it stands today, the only reason to use Torque is if you're already using it. Thus breaking compatibility is a major concern. The parts of the system that most developers are using must be retained. I believe that does not include the methods on the Peers that return Village Record objects. As long as the Criteria and the Peers work the same way, I think we can change the underlying Peer code and see big performance and code maintenance improvements. > >- Maybe: Refactor the templating engine to use something like JSL or > XSLT to translate the templates into class files. Why? The big selling point of Torque to me is the ease of using Velocity templates. >Where Torque _really_ shines is the auto-generation of the Peer/Object >classes from an XML file, which makes it easy to use. Everything else >is pretty much refactorable... Absolutely. - Chris __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
