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?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
