I am all for adding this, the one problem I see is that I think torque
is supposed to be independent of turbine and fulcrum (I need to solve a
dependency on fulcrum.intake, maybe there are others). A simple way
around this is to not declare that the generated classes implement
interfaces in other packages, and force the application programmer to
declare it in the empty class if they wish to use the tool. This idea
sucks though, so maybe there is a better idea. Another (and this does
not seem ideal either) is to create some commons repo of interfaces.
The ApplicationTool (pull), Retrievable (intake), and Recyclable (pool),
etc. do not share anything in common that I can see though, so not sure
why they should be ripped out of their associated packages.
If this can be solved, the code looks good. I would suggest storing the
ParameterParser in an attribute as it is the only thing in the RunData
that is used and this is made more clear and efficient by not
referencing the RunData. I also prefer the name getXXXFromParameters()
as I tend to think of Context as having to do with a TemplateContext and
you are pulling the info from request parameters.
john mcnally
Age Mooy wrote:
>
> Hi,
>
> After handcoding the same kind of OM query pull tool again and again for my last few
>projects, I decided to
> look at the Torque code to see whether I could generate this straight from the xml
>schema. Texen/Torque turned
> out to be easier than I thought so now I have a pretty decent pull tool generator
>that does this:
>
> - Create org.mycompany.myproject.om.tools package
>
> - For each database Foo, generate
> BaseFooQueryTool.java
> FooQueryTool.java (empty extension).
>
> - In BaseFooQueryTool.java, for each table Bar in database Foo generate
> public List getAllBars() // returns getAllBars(new Criteria())
> protected List getAllBars(Criteria c) // does BarPeer.doSelect(c)
> protected Bar getBar(ObjectKey pkName) // does retrieveByPK()
> public Bar getBarFromContextInfo() // gets pk values from ParameterParser by
>name
>
> The last two methods will be generated with more parameters in case of multiple pks.
>It uses the same Ant task
> that is used for generating the OM classes, just with a different set of templates.
>
> I've attached the file generated by my test setup (just two tables).
>
> I've had to manually create and keep up to date exactly this kind of pull tool for
>my last three projects and
> that's no fun for projects with 10+ tables.
>
> Obviously the methods I've generated are the ones I needed for my projects... they
>might need to be changed.
> But if there is enough interest for this, I wouldn't mind making the changes
>necessary for adding it to Torque
> and the TDK.
>
> Anyone interested ?
>
> Age
>
> ------------------------------------------------------------------------
> Name: BaseDefaultQueryTool.java
> BaseDefaultQueryTool.java Type: unspecified type (application/octet-stream)
> Encoding: 7bit
>
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> 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]
