Ups, I knew I forgot something on the list. This was in my mind but did not make it into the email. As you wrote, the problem of static methods is that you cannot override its behaviour. The beauty of static methods is that invocation is very simple.
The idea would be to have a static Wrapper class, which holds a singleton of the class with the implementation, and which passes all its static calls to the implementation class. There would be a setter of the singleton in the static class, so the backing class would be exchangeable. So one can use the static class if simple invocation is wanted, and the implementation class if maximum flexibility is needed. Thomas [EMAIL PROTECTED] schrieb am 30.11.2006 11:58:25: > Is there any chance we can make the Peer classes non-static? > Currently it's hard/impossible to override/extend these without making > generator changes. Perhaps have some form of central "registry" to > hold these classes so that they can be globally looked up but > also replaced/extended if desired. > > The other suggestions are all very good - especially removing village. > > Thanks > > Joe > > On 29/11/06, Thomas Fischer <[EMAIL PROTECTED]> wrote: > > > > Now that the first Torque RC is outit is time to think about what we'd > > like > > to do as next version. Personally, I'd like to propose the following: > > > > - Next version should be 4.0. There can be major changes in the version, > > but the 'look and feel' should change as little as possibl. The idea > > would be that one can recompile one's Torque 3.2 or 3.3 project with the > > new Torque version and it should run with minor changes only. > > > > - Switch to Maven 2 as build system. Maven 2 has much better multiproject > > support than Maven 1, so building will be easier. > > > > - Simplify the repository structure: No svn externals any more. This would > > mean that all Torque components can only be released simultaneously, but > > as we have done so in the past anyway and compatibility problems would > > arise if we would'nt do so, this should not be problematic. > > > > - Use Java 5 style generics and enumerations. One can use compiler > > settings to produce pre-1.5-executable class files. > > > > - Kick out village. Village is bad. See the issue tracker for details. > > This would mean: create the sql to insert / update objects ourselves; do > > the Torque type / SQL type mapping of variables orselves; create objects > > directly from jdbc result sets. > > > > - Use the Criteria object only to hold query data and another object to > > hold update data. Criteria should not extend Hashtable any more nor > > sahould it implement the map interface, cause query data is not a Map in > > any sense (e.g. the same column names can appear more than once in a > > criteria) > > > > - Criterias should not be modified any more inside queries. Of one needs > > modification, one can copy the criteria. > > > > - Disentangle Query description and SQL creation code. In my eyes, it > > would be ideal to port the MVC paradigm to the SQL creation: The criteria > > is the model (what do I want to query), the view would cretae the SQL from > > the Query, and the controller would be the Peer class which executes the > > query. > > > > - Use a column object to hold the column name in the runtime instead of > > Strings. So one could remove all that distributed guesswork of "what is > > the table name, do we have a schema name or not" etc. This would also have > > the advantge that a String is clearly a value and not a column name. > > > > - Make the generator more generic. I'd like to turn the generator into a > > generiy code generation tool, which can be used to create all sort of > > code, not just database access code. I'm currently working on a proposal. > > > > Any opinions ? > > > > Thomas > > > > --------------------------------------------------------------------- > > 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]
