Sorry for the delay... life has been busy. Overall, I'm currently in favor of this... one think I've had on my "if I had time..." wish list has been to look at auto-generating a Torque based REST interface. This was one design thought I had in mind doing the XML Schema, being able to define the DB and the REST interface info in one XML file. Adding in this framework, would seem to help make that a lot easier.
OK, that said, I've looked over the docs but haven't dug into the code yet. My first concerns are that this seems to be fairly complex and that as a core part of Torque, there is a risk of overall reliability going down. I also worry that we may lose some functionality at least until it's identified and restored. There are a lot of bells and whistles that have been "baked in" to Torque over the years. I'm also concerned that this major design shift might delay other things that we've thought about for Torque 4.0. Since time will be spent testing and fixing things that come out of the new generator code. But then, having a new aspect might bring in new help/inspire folks to work on it...lol Finally, I'm sure we agree that the Torque project would not be the final place for this. I'm on the fence if it's best to "incubate" it inside the project or start it as a "Lab" project. Since it would be core to Torque, I'm slightly more in favor of doing it inside... and moving it out as it matures. > -----Original Message----- > From: Thomas Fischer [mailto:[email protected]] > Sent: Wednesday, November 11, 2009 2:42 PM > To: Apache Torque Developers List > Subject: Re: [Proposal] A general-purpose code generation framework for > torque 4 > > > Following the question of whether or not add @SuppressWarnings in the > generated source code, I have used this as a showcase for the proposed > generator, showinh how to change the generated output without touching > the > original torque templates. > The main idea is that one template-set (in this case a minimal one with > only the changed definitions) can inherit from another template-set (the > "normal" templates). Then the new templates can be plugged in at the > "mergepoints" where the original templates are plugged into each other. > This only works because the templates are relatively small each, so they > are meaningful units to be replaced or, in this case, redefined. > > I needed to make some minor changes in the torque-gf package, because I > did > not think before of the particular type of re-plugging (i.e. redefinition > of a single mergepoint). The new version is at the same place as the old > one, http://people.apache.org/~tfischer. I did not need update the > templates. > I also updated the test-project, which now generates all the base peers > with the @SuppressWarnings annotations. > > In detail, what I did in the test project is: > - I added a minimum torque-gf configuration in /src/main/torque-gf. This > contains the changed mergepoint definition, and the new template > producing > the @SuppressWarnings output > - I changed the pom to use the /src/main/torque-gf directory as > overriding > directory for the om templates: > <execution> > <id>generate-sources</id> > ... > <configuration> > ... > <overrideConfigDir>src/main/torque-gf</overrideConfigDir> > ... > </configuration> > </execution> > The "overrideConfigDir" is the "child" package, which inherits all > configuration and definitions form the "parent" in the torque-templates, > and only overrides the changed definitions. > > That's all that is needed for the non-invasive adding of the > @SuppressWarnings output. > > Thomas > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] DukeCE Privacy Statement: Please be advised that this e-mail and any files transmitted with it are confidential communication or may otherwise be privileged or confidential and are intended solely for the individual or entity to whom they are addressed. If you are not the intended recipient you may not rely on the contents of this email or any attachments, and we ask that you please not read, copy or retransmit this communication, but reply to the sender and destroy the email, its contents, and all copies thereof immediately. Any unauthorized dissemination, distribution or copying of this communication is strictly prohibited. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
