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. >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. Martins' idea seemed better to me: - Separate the template based engine which creates java classes from templates from the actual persistence code. - 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). - Maybe: Refactor the templating engine to use something like JSL or XSLT to translate the templates into class files. 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... Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
