I'm not up on the code, but I like the concept, and I like the idea of
retrofitting existing tasks to use a generic resource rather than
methods for each specific type. My original question was about having
the XmlProperty task read from a property as well as a file, I've always
wanted similar functionality in the "get" task -- it only writes the
response to a file, when on occassion it would be much handier to write
it to a property so subsequent tasks could act directly on the response.
Dale
Matt Benson wrote:
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
On Fri, 4 Nov 2005, Matt Benson
<[EMAIL PROTECTED]> wrote:
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
On Wed, 2 Nov 2005, Matt Benson
<[EMAIL PROTECTED]> wrote:
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
Hmm, I'd prefer (ab?)using PropertyHelpers for
this instead of
adding new helpers.
<copy resource="${resource:url:someurl}"/> or
something similar.
Hmm... this appears doable... it will require
that the properties
be resolved by IntrospectionHelper instead of
RuntimeConfigurable
though, which could require the usual
backwards-compatibility
acrobatics.
Do we really need to resolve that in
IntrospectionHelper? Why?
What's the alternative? setResource(String)
(after
which every implementor has to call resolution
code)?
I guess I need to re-read the code, its been a long
time. IIUC you
think we need to modify IntrospectionHelper so that
the correct object
type can be created right there, correct?
OK, I see the problem now. PropertyHelper - or the
way we use it -
isn't really suited for property expansions that
yield something other
than a String.
It's probably easier to have some kind of
ResourceFactory that
returned Resource instances (or subclasses thereof)
based on Strings
and explicitly code support for this into
IntrospectionHelper (much
like the special cases for boolean or File). Your
original idea,
isn't it?
Yeah, basically. :) So if anyone other than myself
and Stefan have been paying attention to this
conversation, does that scare anyone? DD? ;)
-Matt
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
---------------------------------------------------------------------
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]
