You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Age Mooy <am...@home.nl> on 2001/09/19 13:07:06 UTC
OM query pull tool generator in Torque. Anyone interested ?
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
RE: OM query pull tool generator in Torque. Anyone interested ?
Posted by Age Mooy <am...@home.nl>.
> > Do I just send my stuff to this list ? It's just three templates and some
> > small changes in build.properties
> > and build.xml (TDK application files). Again, I'm not sure whether I should
> > diff against
> > jakarta-turbine-torque or against jakarta-turbine-2 and jakarta-turbine-tdk...
>
> What I would like to see is having you package it up into a separate
> repository which can be checked out and run standalone. It should assume
> that there is a ${lib.repo} in order to resolve any dependencies on other
> projects.
>
> You can then work from there to integrate it into the TDK.
Creating repositories is a bit out of my league.... I'll leave that to you committers :)
That said, I don't think a seperate repository is called for here... we're talking
about three templates ! And they are useless without making some small
changes to files in the main repositories (jakarta-turbine-2, jakarta-turbine-torque,
and jakarta-turbine-tdk).
Like I said. I'm a bit lost in the forest of turbine repositories and dependencies but
creating a new repos for just three templates sounds a bit excessive...
I've browsed through the many turbine repositories and these are the necessary
changes I can find:
jakarta-turbine-2
- add a new 'tools' directory with three templates to
jakarta-turbine-2/conf/torque/templates/om
- add a QueryToolControlTemplate entry to
jakarta-turbine-2/conf/torque/build.properties
- add a 'torque-query-tool' taskdef and a 'project-query-tool' target to
jakarta-turbine-2/conf/torque/build.xml
jakarta-turbine-torque
- add a new 'tools' directory with three templates to
jakarta-turbine-torque/src/templates/om
- add a QueryToolControlTemplate entry to
jakarta-turbine-torque/src/conf/build.properties
- add a 'torque-query-tool' taskdef and a 'project-query-tool' target to
jakarta-turbine-torque/src/conf/build.xml
jakarta-turbine-tdk
- add a QueryToolControlTemplate entry to
jakarta-turbine-tdk/src/tdk/apps/2/build.properties
- add a QueryToolControlTemplate entry to
jakarta-turbine-tdk/src/tdk/apps/3/build.properties
- add a 'torque-query-tool' taskdef and a 'project-query-tool' target to
jakarta-turbine-tdk/src/tdk/apps/2/build.xml
- add a 'torque-query-tool' taskdef and a 'project-query-tool' target to
jakarta-turbine-tdk/src/tdk/apps/3/build.xml
I don't know why the tdk has its own versions of these build files when they are
already available in the dependent repositories...
I've attached the three templates.
Here is the build.properties entry:
QueryToolControlTemplate = om/tools/Control.vm
and here is the build.xml stuff:
<target name="init-tasks">
...
<taskdef name="torque-query-tool"
classname="org.apache.turbine.torque.TorqueObjectModelTask">
<classpath refid="classpath"/>
</taskdef>
</target>
<target name="project-query-tool" depends="init-tasks"
description="--> generates an OM context tool for your project">
<echo message="+------------------------------------------+"/>
<echo message="| |"/>
<echo message="| Generating Object Model Context Tool |"/>
<echo message="| for YOUR Turbine project! Woo hoo! |"/>
<echo message="| |"/>
<echo message="+------------------------------------------+"/>
<torque-query-tool
contextProperties="${build.properties}"
controlTemplate="${QueryToolControlTemplate}"
outputDirectory="${outputDirectory}/java"
templatePath="${templatePath}"
outputFile="report.${project}.query-tool.generation"
targetPackage="${targetPackage}.tools"
xmlFile="${schemaDirectory}/${project}-schema.xml"
/>
</target>
I hope you will find a good place for it. If you need any changes made or further work
done I'll be glad to help :)
Age
> -jon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
Re: OM query pull tool generator in Torque. Anyone interested ?
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/19/01 10:51 AM, "Age Mooy" <am...@home.nl> wrote:
> Sounds good. I'm a bit confused about the whole 2.x vs 3.x issue. Would this
> turbine-commons be used in 2.x
> versions of turbine too ?
I would say no. 2.x is about having everything together. 3.x is about
separation.
> Do I just send my stuff to this list ? It's just three templates and some
> small changes in build.properties
> and build.xml (TDK application files). Again, I'm not sure whether I should
> diff against
> jakarta-turbine-torque or against jakarta-turbine-2 and jakarta-turbine-tdk...
What I would like to see is having you package it up into a separate
repository which can be checked out and run standalone. It should assume
that there is a ${lib.repo} in order to resolve any dependencies on other
projects.
You can then work from there to integrate it into the TDK.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: OM query pull tool generator in Torque. Anyone interested ?
Posted by Age Mooy <am...@home.nl>.
> > 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.
>
> Lets make a jakarta-turbine-common
Sounds good. I'm a bit confused about the whole 2.x vs 3.x issue. Would this turbine-commons be used in 2.x
versions of turbine too ?
> That way, we can resolve dependencies across projects for Turbine specific
> interfaces that wouldn't really fit well into the Jakarta commons area.
>
> > 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.
+1 on all of these. I'll make the changes.
Do I just send my stuff to this list ? It's just three templates and some small changes in build.properties
and build.xml (TDK application files). Again, I'm not sure whether I should diff against
jakarta-turbine-torque or against jakarta-turbine-2 and jakarta-turbine-tdk...
Age
> +1
>
> -jon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: OM query pull tool generator in Torque. Anyone interested ?
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/19/01 9:32 AM, "John McNally" <jm...@collab.net> wrote:
> 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.
Lets make a jakarta-turbine-common
That way, we can resolve dependencies across projects for Turbine specific
interfaces that wouldn't really fit well into the Jakarta commons area.
> 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.
+1
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: OM query pull tool generator in Torque. Anyone interested ?
Posted by John McNally <jm...@collab.net>.
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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: OM query pull tool generator in Torque. Anyone interested ?
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/19/01 4:07 AM, "Age Mooy" <am...@home.nl> wrote:
> 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:
Kick ass!
That is great!
Lets get that into CVS ASAP!
I would say that it should be its own cvs project ... something like:
jakarta-turbine-querytoolbuilder
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org