Hello:
I'm not so sure that an interpolation class is out of scope since we
obviously had considered it with the current Interpolation class that is
now in CVS. Just how fancy to make it is perhaps what is at issue?
So, let's review:
Today in CVS and not in a [lang] release we have a new text package with
an Interpolation class and other goodies. The general consensus, it
seems, is that the text package is not "fully baked."
My proposal is finish out this text package and release a version 2.2.
For work, my needs now are solely focused around the Interpolation
feature, so I could see the package only containing the Interpolation
feature in a first text release (v2.2). I see the Interpolation feature
requirements as:
- (for me ;-) Provide an Interpolation feature that allows a simple way
to use System properties to replace variables in a String. For me, this
could be as simple as:
String s = XXX.resolveAll(source, "$", "{", "}",
System.getProperties());
Whether XXX is StringUtils or an Interpolation class (Utils or
instantiable), we can chat about.
- For [config]: Provide an Interpolation feature that it can build on.
The [config] project, please correct me if I am off, must have a way to
plug-in how to look stuff up, hence the nice and simple VariableResolver
interface, which could be surfaced as:
String s = XXX.resolveAll(source, ..., aVariableResolver);
There is also a [config] need for multiple VariableResolvers it seems,
which means that the API can take a Map of VariableResolver or that the
client simply calls the API until all resolve calls worked. But how do
you determine that an API call resolved everything? If one cannot
(Oliver?), then we have to provide a resolveInAll(String, Map) (or other
name)?
Gary
-----Original Message-----
From: Oliver Heger [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 28, 2005 1:20 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] text.Interpolation, on to 2.2
Hi,
I suspected that the whole thing gets a bit out of scope for [lang] and
now Stephen confirmed it.
But okay, I can live with that. Just provide basic support in [lang] and
I will build around it what I need. However it would be helpful if you
supported a more abstract concept for the source of variable values than
a simple map. If we had something like
StrBuilder.replace(String prefix, String suffix, VariableResolver v)
where VariableResolver is a very simple interface:
public interface VariableResolver
{
Object getVariable(String name);
}
and there can be a default implementation for a MapVariableResolver.
Then I could pack the logic I had before in my Interpolation class
(support for different variable resolvers, default variable resolver
etc.) into a special implementation of this interface.
Would this still be out of [lang]'s scope?
Oliver
Gary Gregory wrote:
> Hello:
>
> Should such proposed StrBuilder methods also not be in StringUtils?
>
> Whichever way we go (or provide both), I can still see the benefit of
a
> class that can be instantiated and configured with "$" "{", "}" and a
> map.
>
> Gary
>
> -----Original Message-----
> From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 27, 2005 3:36 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] text.Interpolation, on to 2.2
>
> Gary Gregory wrote:
>
>>Hello Oliver:
>>I took a quick look at the ticket you linked to below. For this to
>
> work
>
>>for System properties, a simple VariableResolver would do the trick I
>>think. Maybe a generic MapVariableResolver could also be provided and
>>maybe a factory methods in order to say simple things like:
>>
>>Interpolator.newInterpolator(System.getProperties()).resolve("The file
>>is here ${java.io.tmpdir}");
>
>
> I should point out that System.getProperties() returns a Properties
> which extends Hashtable which implements Map. So, these are not two
> separate use cases.
>
> Thus an API of the form might be enough:
> StrBuilder.replace(prefix, suffix, map)
> StrBuilder.replaceAll(prefix, suffix, map)
>
> Stephen
>
---------------------------------------------------------------------
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]
