Hello Gary,
the current state of VariableFormatter is fine with me, it allows me
everything to do I need for [configuration].
I think the problem will be to satisfy other needs mentioned by others
in this thread (e.g. operating on a char[], a static interpolation
method that works without creating an instance). But these points are
less important for me.
Oliver
Gary Gregory wrote:
>Hello VariableFormatters:
>
>I've retro-fitted the VariableResolver interface into the
>VariableFormatter class and provided a Map-backed VariableResolver
>implementation. I did not change everything to statics.
>
>I think (and hope) this approach provides an API to address the most
>common cases (Map) with the ability to extend functionality by
>implementing your own VariableResolver and possibly subclassing.
>
>If Oliver and others could see how this looks and feels to them I would
>appreciate any and all comments; in particular as to the use for
>[configuration].
>
>Thanks,
>Gary
>
>
>
>>-----Original Message-----
>>From: Oliver Heger [mailto:oliver.heger@t-online.de]
>>Sent: Sunday, July 10, 2005 11:45 AM
>>To: Jakarta Commons Developers List
>>Subject: Re: [lang] text.Interpolation, on to 2.2
>>
>>Gary Gregory wrote:
>>
>>
>>
>>>I would like us to reconsider the use of the VariableResolver
>>>
>>>
>interface
>
>
>>>for VariableFormatter.
>>>
>>>It seems that this is a cleaner design that does not force
>>>
>>>
>subclassing
>
>
>>>or composition as the sole mean of feature extension.
>>>
>>>Considering the complexity of the StrTokenizer class, I do not think
>>>that the earlier concern that VariableFormatter+VariableResolver as
>>>
>>>
>too
>
>
>>>framework-like is really valid.
>>>
>>>The interface VariableResolver could be made to live in the
>>>VariableFormatter class we *really* think we need to "hide" this
>>>feature.
>>>
>>>If Oliver is up for it and the list does not say "no, no,
>>>
>>>
>because...",
>
>
>>>I'd like to see a patch to the CVS code that makes VariableFormatter
>>>
>>>
>use
>
>
>>>a VariableResolver with an canned implementation for Maps.
>>>
>>>Gary
>>>
>>>
>>>
>>>
>>I prefer the VariableResolver approach, too. So if nobody objects, I
>>will create a patch, which re-introduces this interface (as an inner
>>class) and makes all methods static. (With this approach there is no
>>need for creating instances of VariableFormatter, right?)
>>
>>Don't know how much time I have in the next days, so this might take
>>some days.
>>
>>Oliver
>>
>><snip/>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|