[lang] text.Interpolation, on to 2.2

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[lang] text.Interpolation, on to 2.2

Gary Gregory
Hello:

Is anyone planning on working on text.Interpolation in the near future?

It seems like a logical candidate and a motivation for the next release.

Where does the class come from and does it make sense to simply extract
some code out of Ant.

I could see a subclass dealing specifically with this. Something like:

Interpolation si = new SystemPropertyInterpolation();
// replace all system property in ${} with real values.
string = si.interpolateAll(string);

The class name does seem a little pedantic to me, but eh, I can't come
up with something more succinct right now ;-)

Thoughts?

Thanks,

Gary

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Steven Caswell
Though I don't really have bandwidth to help with it, I am +1 on
moving forward with Interpolation being a motivation for the next
release.

On 6/23/05, Gary Gregory <[hidden email]> wrote:

> Hello:
>
> Is anyone planning on working on text.Interpolation in the near future?
>
> It seems like a logical candidate and a motivation for the next release.
>
> Where does the class come from and does it make sense to simply extract
> some code out of Ant.
>
> I could see a subclass dealing specifically with this. Something like:
>
> Interpolation si = new SystemPropertyInterpolation();
> // replace all system property in ${} with real values.
> string = si.interpolateAll(string);
>
> The class name does seem a little pedantic to me, but eh, I can't come
> up with something more succinct right now ;-)
>
> Thoughts?
>
> Thanks,
>
> Gary
>
>
>


--
Steven Caswell
[hidden email]

Take back the web - http://www.mozilla.org

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Simon Kitching
I'm willing to do some work on this. I'll need to see what's in lang at
the moment though...at least some of the code came originally from
Digester so I feel responsible for knocking it into shape for lang!

Cheers,

Simon

On Fri, 2005-06-24 at 06:34 -0400, Steven Caswell wrote:

> Though I don't really have bandwidth to help with it, I am +1 on
> moving forward with Interpolation being a motivation for the next
> release.
>
> On 6/23/05, Gary Gregory <[hidden email]> wrote:
> > Hello:
> >
> > Is anyone planning on working on text.Interpolation in the near future?
> >
> > It seems like a logical candidate and a motivation for the next release.
> >
> > Where does the class come from and does it make sense to simply extract
> > some code out of Ant.
> >
> > I could see a subclass dealing specifically with this. Something like:
> >
> > Interpolation si = new SystemPropertyInterpolation();
> > // replace all system property in ${} with real values.
> > string = si.interpolateAll(string);
> >
> > The class name does seem a little pedantic to me, but eh, I can't come
> > up with something more succinct right now ;-)
> >
> > Thoughts?
> >
> > Thanks,
> >
> > Gary
> >
> >
> >
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Oliver Heger-2
I am interested in this topic, too, because I want to implement enhanced
interpolation suport for [configuration].

I already had a look at the available Interpolation class, but it lacks
some features I need. So I wrote something myself which is similar to
the interpolation engine of digester, but is based on the interpolation
method that existed in configuration. The code and a unit test can be
found at the following bugzilla ticket:

http://issues.apache.org/bugzilla/show_bug.cgi?id=35116

Oliver

Simon Kitching wrote:

>I'm willing to do some work on this. I'll need to see what's in lang at
>the moment though...at least some of the code came originally from
>Digester so I feel responsible for knocking it into shape for lang!
>
>Cheers,
>
>Simon
>
>On Fri, 2005-06-24 at 06:34 -0400, Steven Caswell wrote:
>  
>
>>Though I don't really have bandwidth to help with it, I am +1 on
>>moving forward with Interpolation being a motivation for the next
>>release.
>>
>>On 6/23/05, Gary Gregory <[hidden email]> wrote:
>>    
>>
>>>Hello:
>>>
>>>Is anyone planning on working on text.Interpolation in the near future?
>>>
>>>It seems like a logical candidate and a motivation for the next release.
>>>
>>>Where does the class come from and does it make sense to simply extract
>>>some code out of Ant.
>>>
>>>I could see a subclass dealing specifically with this. Something like:
>>>
>>>Interpolation si = new SystemPropertyInterpolation();
>>>// replace all system property in ${} with real values.
>>>string = si.interpolateAll(string);
>>>
>>>The class name does seem a little pedantic to me, but eh, I can't come
>>>up with something more succinct right now ;-)
>>>
>>>Thoughts?
>>>
>>>Thanks,
>>>
>>>Gary
>>>
>>>
>>>
>>>      
>>>
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] text.Interpolation, on to 2.2

Gary Gregory
In reply to this post by Gary Gregory
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}");

Would [configuration] be interested in have this in the next version of
[lang]? Assuming that whatever loose requirements created by the current
lang tests are satisfied.  

Gary

-----Original Message-----
From: Oliver Heger [mailto:[hidden email]]
Sent: Saturday, June 25, 2005 7:46 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] text.Interpolation, on to 2.2

I am interested in this topic, too, because I want to implement enhanced

interpolation suport for [configuration].

I already had a look at the available Interpolation class, but it lacks
some features I need. So I wrote something myself which is similar to
the interpolation engine of digester, but is based on the interpolation
method that existed in configuration. The code and a unit test can be
found at the following bugzilla ticket:

http://issues.apache.org/bugzilla/show_bug.cgi?id=35116

Oliver

Simon Kitching wrote:

>I'm willing to do some work on this. I'll need to see what's in lang at
>the moment though...at least some of the code came originally from
>Digester so I feel responsible for knocking it into shape for lang!
>
>Cheers,
>
>Simon
>
>On Fri, 2005-06-24 at 06:34 -0400, Steven Caswell wrote:
>  
>
>>Though I don't really have bandwidth to help with it, I am +1 on
>>moving forward with Interpolation being a motivation for the next
>>release.
>>
>>On 6/23/05, Gary Gregory <[hidden email]> wrote:
>>    
>>
>>>Hello:
>>>
>>>Is anyone planning on working on text.Interpolation in the near
future?
>>>
>>>It seems like a logical candidate and a motivation for the next
release.
>>>
>>>Where does the class come from and does it make sense to simply
extract
>>>some code out of Ant.
>>>
>>>I could see a subclass dealing specifically with this. Something
like:
>>>
>>>Interpolation si = new SystemPropertyInterpolation();
>>>// replace all system property in ${} with real values.
>>>string = si.interpolateAll(string);
>>>
>>>The class name does seem a little pedantic to me, but eh, I can't
come

>>>up with something more succinct right now ;-)
>>>
>>>Thoughts?
>>>
>>>Thanks,
>>>
>>>Gary
>>>
>>>
>>>
>>>      
>>>
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Oliver Heger-2
Gary,

that's right, the basic idea is to configure several VariableResolvers
for different purposes. This is pretty much the same as the
interpolation engine of [digester] works. Resolvers for system
properties and map based resolvers are very obvious and simple
implementations. But a VariableResolver could be arbitrary complex, e.g.
a JEXLResolver for expressions (maybe not directly suited for [lang]).

Interolation is an important feature of [configuration], but I am
reluctant to implementing a complete interpolation engine in this
project and expose it in the public API. So I would love to see
something like that in [lang].

Oliver

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}");
>
>Would [configuration] be interested in have this in the next version of
>[lang]? Assuming that whatever loose requirements created by the current
>lang tests are satisfied.  
>
>Gary
>
>-----Original Message-----
>From: Oliver Heger [mailto:[hidden email]]
>Sent: Saturday, June 25, 2005 7:46 AM
>To: Jakarta Commons Developers List
>Subject: Re: [lang] text.Interpolation, on to 2.2
>
>I am interested in this topic, too, because I want to implement enhanced
>
>interpolation suport for [configuration].
>
>I already had a look at the available Interpolation class, but it lacks
>some features I need. So I wrote something myself which is similar to
>the interpolation engine of digester, but is based on the interpolation
>method that existed in configuration. The code and a unit test can be
>found at the following bugzilla ticket:
>
>http://issues.apache.org/bugzilla/show_bug.cgi?id=35116
>
>Oliver
>
>Simon Kitching wrote:
>
>  
>
>>I'm willing to do some work on this. I'll need to see what's in lang at
>>the moment though...at least some of the code came originally from
>>Digester so I feel responsible for knocking it into shape for lang!
>>
>>Cheers,
>>
>>Simon
>>
>>On Fri, 2005-06-24 at 06:34 -0400, Steven Caswell wrote:
>>
>>
>>    
>>
>>>Though I don't really have bandwidth to help with it, I am +1 on
>>>moving forward with Interpolation being a motivation for the next
>>>release.
>>>
>>>On 6/23/05, Gary Gregory <[hidden email]> wrote:
>>>  
>>>
>>>      
>>>
>>>>Hello:
>>>>
>>>>Is anyone planning on working on text.Interpolation in the near
>>>>        
>>>>
>future?
>  
>
>>>>It seems like a logical candidate and a motivation for the next
>>>>        
>>>>
>release.
>  
>
>>>>Where does the class come from and does it make sense to simply
>>>>        
>>>>
>extract
>  
>
>>>>some code out of Ant.
>>>>
>>>>I could see a subclass dealing specifically with this. Something
>>>>        
>>>>
>like:
>  
>
>>>>Interpolation si = new SystemPropertyInterpolation();
>>>>// replace all system property in ${} with real values.
>>>>string = si.interpolateAll(string);
>>>>
>>>>The class name does seem a little pedantic to me, but eh, I can't
>>>>        
>>>>
>come
>  
>
>>>>up with something more succinct right now ;-)
>>>>
>>>>Thoughts?
>>>>
>>>>Thanks,
>>>>
>>>>Gary
>>>>
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>  
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>>
>>
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] text.Interpolation, on to 2.2

Gary Gregory
In reply to this post by Gary Gregory
Hello:

I think that a good motivation for interpolation in [lang] would be to
have [configuration] as a call site ([configuration] already depends on
[lang]). With that in mind, I would like to see interpolation classes
suitable for [configuration] but not any more complicated for a first
cut.

"I am reluctant to implementing a complete interpolation engine in this
project and expose it in the public API."

I would like us to take an XP approach first by implementing just what
[configuration] needs for example, not a complete engine.

You mention [digester]; does it have what you would call a "complete
interpolation engine"? Do you have a definition of what such a best
features? What are the differences b/w the code in the ticket and a
complete engine or the one in [digester]?

Thanks,
Gary


-----Original Message-----
From: Oliver Heger [mailto:[hidden email]]
Sent: Monday, June 27, 2005 1:08 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] text.Interpolation, on to 2.2

Gary,

that's right, the basic idea is to configure several VariableResolvers
for different purposes. This is pretty much the same as the
interpolation engine of [digester] works. Resolvers for system
properties and map based resolvers are very obvious and simple
implementations. But a VariableResolver could be arbitrary complex, e.g.

a JEXLResolver for expressions (maybe not directly suited for [lang]).

Interolation is an important feature of [configuration], but I am
reluctant to implementing a complete interpolation engine in this
project and expose it in the public API. So I would love to see
something like that in [lang].

Oliver

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}");
>
>Would [configuration] be interested in have this in the next version of
>[lang]? Assuming that whatever loose requirements created by the
current

>lang tests are satisfied.  
>
>Gary
>
>-----Original Message-----
>From: Oliver Heger [mailto:[hidden email]]
>Sent: Saturday, June 25, 2005 7:46 AM
>To: Jakarta Commons Developers List
>Subject: Re: [lang] text.Interpolation, on to 2.2
>
>I am interested in this topic, too, because I want to implement
enhanced
>
>interpolation suport for [configuration].
>
>I already had a look at the available Interpolation class, but it lacks

>some features I need. So I wrote something myself which is similar to
>the interpolation engine of digester, but is based on the interpolation

>method that existed in configuration. The code and a unit test can be
>found at the following bugzilla ticket:
>
>http://issues.apache.org/bugzilla/show_bug.cgi?id=35116
>
>Oliver
>
>Simon Kitching wrote:
>
>  
>
>>I'm willing to do some work on this. I'll need to see what's in lang
at

>>the moment though...at least some of the code came originally from
>>Digester so I feel responsible for knocking it into shape for lang!
>>
>>Cheers,
>>
>>Simon
>>
>>On Fri, 2005-06-24 at 06:34 -0400, Steven Caswell wrote:
>>
>>
>>    
>>
>>>Though I don't really have bandwidth to help with it, I am +1 on
>>>moving forward with Interpolation being a motivation for the next
>>>release.
>>>
>>>On 6/23/05, Gary Gregory <[hidden email]> wrote:
>>>  
>>>
>>>      
>>>
>>>>Hello:
>>>>
>>>>Is anyone planning on working on text.Interpolation in the near
>>>>        
>>>>
>future?
>  
>
>>>>It seems like a logical candidate and a motivation for the next
>>>>        
>>>>
>release.
>  
>
>>>>Where does the class come from and does it make sense to simply
>>>>        
>>>>
>extract
>  
>
>>>>some code out of Ant.
>>>>
>>>>I could see a subclass dealing specifically with this. Something
>>>>        
>>>>
>like:
>  
>
>>>>Interpolation si = new SystemPropertyInterpolation();
>>>>// replace all system property in ${} with real values.
>>>>string = si.interpolateAll(string);
>>>>
>>>>The class name does seem a little pedantic to me, but eh, I can't
>>>>        
>>>>
>come
>  
>
>>>>up with something more succinct right now ;-)
>>>>
>>>>Thoughts?
>>>>
>>>>Thanks,
>>>>
>>>>Gary
>>>>
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>  
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>>
>>
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Oliver Heger-2
Hello Gary,

I have no strict definition of what I call an interpolation engine, but
I view it as somewhat that is customizable by clients. What is already
implemented in [digester] would to a major part satisfy the needs of
[configuration]. In addition to the basic interpolation functionality we
would like to have

- the VariableResolver concept allowing a user to define a custom set of
sources for variable values,

- support for multiple VariableResolvers at the same time (e.g. by using
certain prefixes for the variables to associate them with a resolver),

- a default VariableResolver, which will be called for all variables
that are not associated with a specific resolver; the configuration
object itself will act as this default resolver maintaining backwards
compatibility with the current interpolation implementation (ATM the
values of configuration properties can be variables, which will be
replaced by the values of the properties in the same configuration
object they refer to).

The code in the bugzilla ticket is different from [digester] in the
following points:

- The VariableResolver interface returns an Object as a variable's
value. [digester]'s pendant has a String. Because [configuration]
supports different data types by default I thought plain Objects would
be more appropriate and would avoid unnecessary type conversions.

- For the same reason the main interpolation method returns an Object
rather than a String, too.

- The prefixes that associate a variable with a VariableResolver are a
bit different (but this is a matter of taste).

- The main interpolation method is extracted from AbstractConfiguration.
It is able to detect cyclic variable replacements and throws an
exception with a nice stack trace in these cases. I don't know how this
is implemented in [digester].

Oliver

Gary Gregory wrote:

>Hello:
>
>I think that a good motivation for interpolation in [lang] would be to
>have [configuration] as a call site ([configuration] already depends on
>[lang]). With that in mind, I would like to see interpolation classes
>suitable for [configuration] but not any more complicated for a first
>cut.
>
>"I am reluctant to implementing a complete interpolation engine in this
>project and expose it in the public API."
>
>I would like us to take an XP approach first by implementing just what
>[configuration] needs for example, not a complete engine.
>
>You mention [digester]; does it have what you would call a "complete
>interpolation engine"? Do you have a definition of what such a best
>features? What are the differences b/w the code in the ticket and a
>complete engine or the one in [digester]?
>
>Thanks,
>Gary
>
>
>-----Original Message-----
>From: Oliver Heger [mailto:[hidden email]]
>Sent: Monday, June 27, 2005 1:08 AM
>To: Jakarta Commons Developers List
>Subject: Re: [lang] text.Interpolation, on to 2.2
>
>Gary,
>
>that's right, the basic idea is to configure several VariableResolvers
>for different purposes. This is pretty much the same as the
>interpolation engine of [digester] works. Resolvers for system
>properties and map based resolvers are very obvious and simple
>implementations. But a VariableResolver could be arbitrary complex, e.g.
>
>a JEXLResolver for expressions (maybe not directly suited for [lang]).
>
>Interolation is an important feature of [configuration], but I am
>reluctant to implementing a complete interpolation engine in this
>project and expose it in the public API. So I would love to see
>something like that in [lang].
>
>Oliver
>
>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}");
>>
>>Would [configuration] be interested in have this in the next version of
>>[lang]? Assuming that whatever loose requirements created by the
>>    
>>
>current
>  
>
>>lang tests are satisfied.  
>>
>>Gary
>>
>>-----Original Message-----
>>From: Oliver Heger [mailto:[hidden email]]
>>Sent: Saturday, June 25, 2005 7:46 AM
>>To: Jakarta Commons Developers List
>>Subject: Re: [lang] text.Interpolation, on to 2.2
>>
>>I am interested in this topic, too, because I want to implement
>>    
>>
>enhanced
>  
>
>>interpolation suport for [configuration].
>>
>>I already had a look at the available Interpolation class, but it lacks
>>    
>>
>
>  
>
>>some features I need. So I wrote something myself which is similar to
>>the interpolation engine of digester, but is based on the interpolation
>>    
>>
>
>  
>
>>method that existed in configuration. The code and a unit test can be
>>found at the following bugzilla ticket:
>>
>>http://issues.apache.org/bugzilla/show_bug.cgi?id=35116
>>
>>Oliver
>>
>>    
>>
<snip>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] text.Interpolation, on to 2.2

Gary Gregory
In reply to this post by Gary Gregory
Ok, this all sounds good!

I think it would be reasonable to have a String version of the resolve
API to make the most common case easy to deal with. Perhaps the generic
Object API would be "Object resolveObject()" while the more normal (for
[lang].text) String version be "String resolve()"?

Gary

-----Original Message-----
From: Oliver Heger [mailto:[hidden email]]
Sent: Monday, June 27, 2005 10:30 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] text.Interpolation, on to 2.2

Hello Gary,

I have no strict definition of what I call an interpolation engine, but
I view it as somewhat that is customizable by clients. What is already
implemented in [digester] would to a major part satisfy the needs of
[configuration]. In addition to the basic interpolation functionality we

would like to have

- the VariableResolver concept allowing a user to define a custom set of

sources for variable values,

- support for multiple VariableResolvers at the same time (e.g. by using

certain prefixes for the variables to associate them with a resolver),

- a default VariableResolver, which will be called for all variables
that are not associated with a specific resolver; the configuration
object itself will act as this default resolver maintaining backwards
compatibility with the current interpolation implementation (ATM the
values of configuration properties can be variables, which will be
replaced by the values of the properties in the same configuration
object they refer to).

The code in the bugzilla ticket is different from [digester] in the
following points:

- The VariableResolver interface returns an Object as a variable's
value. [digester]'s pendant has a String. Because [configuration]
supports different data types by default I thought plain Objects would
be more appropriate and would avoid unnecessary type conversions.

- For the same reason the main interpolation method returns an Object
rather than a String, too.

- The prefixes that associate a variable with a VariableResolver are a
bit different (but this is a matter of taste).

- The main interpolation method is extracted from AbstractConfiguration.

It is able to detect cyclic variable replacements and throws an
exception with a nice stack trace in these cases. I don't know how this
is implemented in [digester].

Oliver

Gary Gregory wrote:

>Hello:
>
>I think that a good motivation for interpolation in [lang] would be to
>have [configuration] as a call site ([configuration] already depends on
>[lang]). With that in mind, I would like to see interpolation classes
>suitable for [configuration] but not any more complicated for a first
>cut.
>
>"I am reluctant to implementing a complete interpolation engine in this
>project and expose it in the public API."
>
>I would like us to take an XP approach first by implementing just what
>[configuration] needs for example, not a complete engine.
>
>You mention [digester]; does it have what you would call a "complete
>interpolation engine"? Do you have a definition of what such a best
>features? What are the differences b/w the code in the ticket and a
>complete engine or the one in [digester]?
>
>Thanks,
>Gary
>
>
>-----Original Message-----
>From: Oliver Heger [mailto:[hidden email]]
>Sent: Monday, June 27, 2005 1:08 AM
>To: Jakarta Commons Developers List
>Subject: Re: [lang] text.Interpolation, on to 2.2
>
>Gary,
>
>that's right, the basic idea is to configure several VariableResolvers
>for different purposes. This is pretty much the same as the
>interpolation engine of [digester] works. Resolvers for system
>properties and map based resolvers are very obvious and simple
>implementations. But a VariableResolver could be arbitrary complex,
e.g.

>
>a JEXLResolver for expressions (maybe not directly suited for [lang]).
>
>Interolation is an important feature of [configuration], but I am
>reluctant to implementing a complete interpolation engine in this
>project and expose it in the public API. So I would love to see
>something like that in [lang].
>
>Oliver
>
>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}");
>>
>>Would [configuration] be interested in have this in the next version
of

>>[lang]? Assuming that whatever loose requirements created by the
>>    
>>
>current
>  
>
>>lang tests are satisfied.  
>>
>>Gary
>>
>>-----Original Message-----
>>From: Oliver Heger [mailto:[hidden email]]
>>Sent: Saturday, June 25, 2005 7:46 AM
>>To: Jakarta Commons Developers List
>>Subject: Re: [lang] text.Interpolation, on to 2.2
>>
>>I am interested in this topic, too, because I want to implement
>>    
>>
>enhanced
>  
>
>>interpolation suport for [configuration].
>>
>>I already had a look at the available Interpolation class, but it
lacks
>>    
>>
>
>  
>
>>some features I need. So I wrote something myself which is similar to
>>the interpolation engine of digester, but is based on the
interpolation

>>    
>>
>
>  
>
>>method that existed in configuration. The code and a unit test can be
>>found at the following bugzilla ticket:
>>
>>http://issues.apache.org/bugzilla/show_bug.cgi?id=35116
>>
>>Oliver
>>
>>    
>>
<snip>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Stephen Colebourne
In reply to this post by Oliver Heger-2
Oliver Heger wrote:
> Hello Gary,
>
> I have no strict definition of what I call an interpolation engine, but
> I view it as somewhat that is customizable by clients.

I am a little concerned by the direction of this thread. [lang]'s scope
doesn't cover the words 'framework' or 'engine'. [lang] is intended to
be simple and obvious.

I have no objection to have some kind of interpolator in [lang], but we
should try to keep it simple.

And maybe we should be basing this around the new StrBuilder class.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Stephen Colebourne
In reply to this post by Gary Gregory
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] text.Interpolation, on to 2.2

Gary Gregory
In reply to this post by Gary Gregory
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:[hidden email]]
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: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Oliver Heger
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:[hidden email]]
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] text.Interpolation, on to 2.2

Gary Gregory
In reply to this post by Gary Gregory
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:[hidden email]]
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:[hidden email]]
> 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: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Emmanuel Bourg-3
Gary Gregory wrote:

> - 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)?

And what about some kind of chained VariableResolver ? A resolver that
will check several resolvers or use a specific resolver depending on the
key ? Thus there is no need to have several resolveAll methods and the
actual strategy is delegated to the resolver.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Oliver Heger-2
Emmanuel Bourg wrote:

> Gary Gregory wrote:
>
>> - 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)?
>
>
> And what about some kind of chained VariableResolver ? A resolver that
> will check several resolvers or use a specific resolver depending on
> the key ? Thus there is no need to have several resolveAll methods and
> the actual strategy is delegated to the resolver.
>
> Emmanuel Bourg
>
Yes, this is exactly what I meant by

"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."

The idea is to somehow associate variables with a concrete resolver. As an example, an input could look like:

"File ${x:fileName} was stored in ${sys:user.home} at ${e:now}"

Then there would be a composite or chained variable resolver that would know, which of its child resolver to use for the different variables. So the API in [lang] can remain simple and complex logic can be put in specific implementations of the VariableResolver interface (which would live in other projects).

Oliver


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] text.Interpolation, on to 2.2

Gary Gregory
In reply to this post by Gary Gregory
Thank you for the clarification Oliver, now I see and I like it.

Now, to get back to where this code should live: I do like the idea of
having a class for this feature (and the one interface). We now have
text.Interpolation. I've never been crazy about the name and looking at
the JRE (1.4.2), there is a java.text.MessageFormat that is similar in
intention, the JRE format classes only work with indices, not names.

If we can agree that this code should live in its own class, I would
like to propose o.a.c.l.text.VariableFormat (or a similar *Format name).
Then we'd have a nicely named pair text.VariableFormat and
text.VariableResolver.

Thoughts?

Gary

-----Original Message-----
From: Oliver Heger [mailto:[hidden email]]
Sent: Tuesday, June 28, 2005 10:56 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] text.Interpolation, on to 2.2

Emmanuel Bourg wrote:

> Gary Gregory wrote:
>
>> - 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)?
>
>
> And what about some kind of chained VariableResolver ? A resolver that

> will check several resolvers or use a specific resolver depending on
> the key ? Thus there is no need to have several resolveAll methods and

> the actual strategy is delegated to the resolver.
>
> Emmanuel Bourg
>
Yes, this is exactly what I meant by

"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."

The idea is to somehow associate variables with a concrete resolver. As
an example, an input could look like:

"File ${x:fileName} was stored in ${sys:user.home} at ${e:now}"

Then there would be a composite or chained variable resolver that would
know, which of its child resolver to use for the different variables. So
the API in [lang] can remain simple and complex logic can be put in
specific implementations of the VariableResolver interface (which would
live in other projects).

Oliver


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] text.Interpolation, on to 2.2

Michael Heuer-2
In reply to this post by Gary Gregory

Gary Gregory wrote:

> - (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());

Maybe it is a bit of overkill, but you could use Velocity for this:

Velocity.init();
VelocityContext ctx = new VelocityContext(System.getProperties());
Template t = new Template(...);  // make a template from source
StringWriter sw = new StringWriter();
t.merge(ctx, sw);
String s = sw.toString();

Why reimplement something that already works quite well?

   michael


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] text.Interpolation, on to 2.2

Michael Heuer-2

Michael Heuer wrote:

> Gary Gregory wrote:
>
> > - (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());
>
> Maybe it is a bit of overkill, but you could use Velocity for this:
>
> Velocity.init();
> VelocityContext ctx = new VelocityContext(System.getProperties());
> Template t = new Template(...);  // make a template from source
> StringWriter sw = new StringWriter();
> t.merge(ctx, sw);
> String s = sw.toString();

Sorry, even easier:

StringWriter sw = new StringWriter();
VelocityContext ctx = new VelocityContext(System.getProperties());
VelocityEngine.evaluate(ctx, sw, source);

   michael


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Emmanuel Bourg-3
In reply to this post by Oliver Heger-2
Dumb question, why do we even need a VariableResolver interface ? A
String->Object association is a common job for a Map after all. We
should be able to build a sophisticated resolver system in
[configuration] with a simple resolve(String, Map) method in [lang].

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123