on 9/19/01 9:32 AM, "John McNally" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
