Re: [lang] VariableFormatter - pre 2.2
Almost done on text package - StrSubstitutor needs replace methods taking a StringBuffer (as adding them later causes overloading issues as per StringBuffer itself from JDK1.3 to 1.4) Stephen Henri Yandell wrote: On 8/4/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: On 8/2/06, Tom Schindl [EMAIL PROTECTED] wrote: Well I'd love to see this method in 2.2 because I think it does make any API visible to the user and doesn't bloat the interface with too many new methods. Any other thoughts? Just that now that Attributes 2.2 is out, I'm ready to start cutting Lang 2.2 release candidates and want to put this one to bed :) I'm away next two weekends. VariableFormatter needs to be extracted as an abstract class StrLookup - like StrMatcher. And the resolveVariable method needs altering to have a more subclass friendly API (see other thread). So, if you feel like coding... Before 2.2? Or for what Tom wants? Hen - 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]
Re: [lang] VariableFormatter - pre 2.2
On 8/4/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: On 8/2/06, Tom Schindl [EMAIL PROTECTED] wrote: Well I'd love to see this method in 2.2 because I think it does make any API visible to the user and doesn't bloat the interface with too many new methods. Any other thoughts? Just that now that Attributes 2.2 is out, I'm ready to start cutting Lang 2.2 release candidates and want to put this one to bed :) I'm away next two weekends. VariableFormatter needs to be extracted as an abstract class StrLookup - like StrMatcher. And the resolveVariable method needs altering to have a more subclass friendly API (see other thread). So, if you feel like coding... Before 2.2? Or for what Tom wants? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
Henri Yandell wrote: On 8/2/06, Tom Schindl [EMAIL PROTECTED] wrote: Well I'd love to see this method in 2.2 because I think it does make any API visible to the user and doesn't bloat the interface with too many new methods. Any other thoughts? Just that now that Attributes 2.2 is out, I'm ready to start cutting Lang 2.2 release candidates and want to put this one to bed :) I'm away next two weekends. VariableFormatter needs to be extracted as an abstract class StrLookup - like StrMatcher. And the resolveVariable method needs altering to have a more subclass friendly API (see other thread). So, if you feel like coding... Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
On 8/2/06, Tom Schindl [EMAIL PROTECTED] wrote: Well I'd love to see this method in 2.2 because I think it does make any API visible to the user and doesn't bloat the interface with too many new methods. Any other thoughts? Just that now that Attributes 2.2 is out, I'm ready to start cutting Lang 2.2 release candidates and want to put this one to bed :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
Henri Yandell schrieb: On 8/2/06, Tom Schindl [EMAIL PROTECTED] wrote: Well I'd love to see this method in 2.2 because I think it does make any API visible to the user and doesn't bloat the interface with too many new methods. Any other thoughts? Just that now that Attributes 2.2 is out, I'm ready to start cutting Lang 2.2 release candidates and want to put this one to bed :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Well no problem from my side. I'll create a Jira-Entry. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
Make a new one - unless you're arguing for the change to be in 2.2;
then keep it going on this thread.
Hen
On 8/2/06, Tom Schindl [EMAIL PROTECTED] wrote:
Where should I put my feature request should I:
- append it to VariableFormatter's-Jira-Entry
- create a new Jira-Entry for StrSubstitutor
Tom
Tom Schindl schrieb:
Hi,
Looks good to me. Maybe for 2.3 this patch could provide
MessageFormatting like proposed before without bloating the API. Does
this now mean that VariableFormatter is gone? I like the nameing
StrSubstitutor better.
Tom
Henri Yandell schrieb:
On 7/23/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
I have reworked the VariableFormatter class along the lines that I
was thinking. I have committed it as StrSubstitutor so it doesn't
clash for the moment and so it can be easiy reviewed.
This version does not have a separate parser class, but still
supports escaping, and matchers for prefix/suffix (which can now be
set by users). The new class should perform better as a result.
I have removed the edge cases wrt resolving Objects, as they were
rather ill-defined.
Otherwise, the basic functionality it supported, and the test case
is slightly enlarged. I still want to break out the resolver as a
public abstract class before release.
Opinions
Oliver, Gary, Tom?
Looking to get Lang 2.2 moving out the door and this is the only blocker.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index:
/home.local/tom/projects/eclipse-ws/bidi-forms/jakarta-commons-lang/src/java/org/apache/commons/lang/text/StrSubstitutor.java
===
---
/home.local/tom/projects/eclipse-ws/bidi-forms/jakarta-commons-lang/src/java/org/apache/commons/lang/text/StrSubstitutor.java
(revision 427468)
+++
/home.local/tom/projects/eclipse-ws/bidi-forms/jakarta-commons-lang/src/java/org/apache/commons/lang/text/StrSubstitutor.java
(working copy)
@@ -16,6 +16,7 @@
package org.apache.commons.lang.text;
+import java.text.MessageFormat;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
@@ -725,5 +726,84 @@
return obj.toString();
}
}
+
+/**
+ * Looks up a string value by name using a [EMAIL PROTECTED] Map} and
can use format
+ * expressions known from [EMAIL PROTECTED] MessageFormat}
+ */
+static class MapVariableResolverFormat extends MapVariableResolver {
+
+ MapVariableResolverFormat(Map map) {
+ super(map);
+ }
+
+ public String resolveVariable(String varName) {
+ int index;
+
+ if (map != null (index = varName.indexOf(,)) !=
-1) {
+ return MessageFormat.format({0 +
varName.substring(index)
+ + }, new Object[] { map.get(
+ varName.substring(0,
index)) });
+ } else {
+ return super.resolveVariable(varName);
+ }
+ }
+}
+
+/**
+ * Substitutes variables by value and allows to use the formats known
from
+ * [EMAIL PROTECTED] MessageFormat}:
+ * p
+ * The following example demonstrates this:
+ * /p
+ * pre
+ * Map map = new HashMap();
+ * map.put(num,new Double(1000.103));
+ * map.put(date, new
SimpleDateFormat(-MM-dd).parse(1970-01-01));
+ *
+ * StrSubstitutor.Format.replace(Number: ${num,number,integer}, Date:
${date,date,-MM-dd}, map)
+ * /pre
+ * yielding in Locale.US
+ * pre
+ * Number: 1,000, Date: 1970-01-01
+ * /pre
+ */
+public static class Format {
+ private Format() {}
+
+/**
+ * Replaces all the occurrences of variables in the given source
object with
+ * their matching values from the map.
+ *
+ * @param source the source text containing the variables to
substitute
+ * @param valueMap the map with the values
+ * @return the result of the replace operation
+ */
+public static String replace(Object source, Map valueMap) {
+ StrSubstitutor tmp = new StrSubstitutor();
+ tmp.setVariableResolver(new
MapVariableResolverFormat(valueMap));
+
+return tmp.replace(source);
+}
+/**
+ * Replaces all the occurrences of variables in the given source
object with
+ * their matching values from the map. This method allows to
specifiy a
+ * custom variable prefix and suffix
+ *
+ * @param source the source text containing the variables to
substitute
+
Re: [lang] VariableFormatter - pre 2.2
Well I'd love to see this method in 2.2 because I think it does make any
API visible to the user and doesn't bloat the
interface with too many new methods.
Any other thoughts?
Tom
Henri Yandell wrote:
Make a new one - unless you're arguing for the change to be in 2.2;
then keep it going on this thread.
Hen
On 8/2/06, Tom Schindl [EMAIL PROTECTED] wrote:
Where should I put my feature request should I:
- append it to VariableFormatter's-Jira-Entry
- create a new Jira-Entry for StrSubstitutor
Tom
Tom Schindl schrieb:
Hi,
Looks good to me. Maybe for 2.3 this patch could provide
MessageFormatting like proposed before without bloating the API. Does
this now mean that VariableFormatter is gone? I like the nameing
StrSubstitutor better.
Tom
Henri Yandell schrieb:
On 7/23/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
I have reworked the VariableFormatter class along the lines that I
was thinking. I have committed it as StrSubstitutor so it doesn't
clash for the moment and so it can be easiy reviewed.
This version does not have a separate parser class, but still
supports escaping, and matchers for prefix/suffix (which can now be
set by users). The new class should perform better as a result.
I have removed the edge cases wrt resolving Objects, as they were
rather ill-defined.
Otherwise, the basic functionality it supported, and the test case
is slightly enlarged. I still want to break out the resolver as a
public abstract class before release.
Opinions
Oliver, Gary, Tom?
Looking to get Lang 2.2 moving out the door and this is the only
blocker.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index:
/home.local/tom/projects/eclipse-ws/bidi-forms/jakarta-commons-lang/src/java/org/apache/commons/lang/text/StrSubstitutor.java
===
---
/home.local/tom/projects/eclipse-ws/bidi-forms/jakarta-commons-lang/src/java/org/apache/commons/lang/text/StrSubstitutor.java
(revision 427468)
+++
/home.local/tom/projects/eclipse-ws/bidi-forms/jakarta-commons-lang/src/java/org/apache/commons/lang/text/StrSubstitutor.java
(working copy)
@@ -16,6 +16,7 @@
package org.apache.commons.lang.text;
+import java.text.MessageFormat;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
@@ -725,5 +726,84 @@
return obj.toString();
}
}
+
+/**
+ * Looks up a string value by name using a [EMAIL PROTECTED] Map} and
can
use format
+ * expressions known from [EMAIL PROTECTED] MessageFormat}
+ */
+static class MapVariableResolverFormat extends
MapVariableResolver {
+
+ MapVariableResolverFormat(Map map) {
+ super(map);
+ }
+
+ public String resolveVariable(String varName) {
+ int index;
+
+ if (map != null (index =
varName.indexOf(,)) != -1) {
+ return MessageFormat.format({0 +
varName.substring(index)
+ + }, new Object[] { map.get(
+
varName.substring(0, index)) });
+ } else {
+ return super.resolveVariable(varName);
+ }
+ }
+}
+
+/**
+ * Substitutes variables by value and allows to use the
formats known from
+ * [EMAIL PROTECTED] MessageFormat}:
+ * p
+ * The following example demonstrates this:
+ * /p
+ * pre
+ * Map map = new HashMap();
+ * map.put(num,new Double(1000.103));
+ * map.put(date, new
SimpleDateFormat(-MM-dd).parse(1970-01-01));
+ *
+ * StrSubstitutor.Format.replace(Number:
${num,number,integer}, Date: ${date,date,-MM-dd}, map)
+ * /pre
+ * yielding in Locale.US
+ * pre
+ * Number: 1,000, Date: 1970-01-01
+ * /pre
+ */
+public static class Format {
+ private Format() {}
+
+/**
+ * Replaces all the occurrences of variables in the given
source object with
+ * their matching values from the map.
+ *
+ * @param source the source text containing the variables
to substitute
+ * @param valueMap the map with the values
+ * @return the result of the replace operation
+ */
+public static String replace(Object source, Map valueMap) {
+ StrSubstitutor tmp = new StrSubstitutor();
+ tmp.setVariableResolver(new
MapVariableResolverFormat(valueMap));
+
+return tmp.replace(source);
+
RE: [lang] VariableFormatter - pre 2.2
Hello All: I think the argument for the name change I am hearing is: we are not formatting a la printf but we are replacing markers with values (and not formatting those values). Is that right? If that is the case, a Substitutor name is better. As a general rule, I do not like or use abbreviations in class or method names (acronyms are OK by me). So I would say that StringSubstitutor is better. After all, we have StringUtils, StringEscapeUtils and many others, not StrUtils, StrEscapeUtils. So I would ask that we use StringFoo for all of these classes. Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, July 31, 2006 11:30 PM To: Jakarta Commons Developers List; Stephen Colebourne Subject: Re: [lang] VariableFormatter - pre 2.2 On 7/23/06, Stephen Colebourne [EMAIL PROTECTED] wrote: I have reworked the VariableFormatter class along the lines that I was thinking. I have committed it as StrSubstitutor so it doesn't clash for the moment and so it can be easiy reviewed. This version does not have a separate parser class, but still supports escaping, and matchers for prefix/suffix (which can now be set by users). The new class should perform better as a result. I have removed the edge cases wrt resolving Objects, as they were rather ill- defined. Otherwise, the basic functionality it supported, and the test case is slightly enlarged. I still want to break out the resolver as a public abstract class before release. Opinions Oliver, Gary, Tom? Looking to get Lang 2.2 moving out the door and this is the only blocker. Hen - 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]
Re: [lang] VariableFormatter - pre 2.2
Stephen Colebourne wrote:
For example There were ${number} characters, would return the
object matching the ${number} substitution, and dropping the rest of
the text!
Perhaps you can point to an exact use case?
Oliver Heger wrote:
Your analysis is correct. The idea was that you can have specialized
resolver implementations that inherently work on objects, e.g.
- a constant resolver, which interprets the variable name as a name of
a static field of a class, e.g.
${my.package.MyClass.MY_CONSTANT} would return the value of the
constant field.
- an expression resolver, which could be passed an expression in a
language like JEXL and would calculate the result.
Of course if the string passed to the substitutor contains other text
elements or variables, you have no choice than converting the result
to text. But if only a single variable is to be processed, the result
can be an arbitrary type.
Sounds a bit [configuration] specific to me.
However, we could add a singleVariableName(String) method which would
check for the special case where the whole string was a variable.
We could also have a variableNames(String) method which returns the top
level variable names in the string.
Not sure how useful either of these would really be though.
What might be more useful, would be to change the method signature of
resolveVariable() to take the StrBuilder start pos and current variable
start and end. That would effectively provide subclasses with much more
detailed events about the variables.
So, pre 2.2 - I'd suggest
a) alter resolveVariable()
b) extract VariableFormatter interface to be StrLookup abstract class
c) agree class name (is anyone not OK with StrSubstitutor?)
Stephen
a) and b) is fine with me. The discussion about the class name I will
leave to you native speakers ;-)
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
On 8/2/06, Gary Gregory [EMAIL PROTECTED] wrote: Hello All: I think the argument for the name change I am hearing is: we are not formatting a la printf but we are replacing markers with values (and not formatting those values). Is that right? If that is the case, a Substitutor name is better. As a general rule, I do not like or use abbreviations in class or method names (acronyms are OK by me). So I would say that StringSubstitutor is better. After all, we have StringUtils, StringEscapeUtils and many others, not StrUtils, StrEscapeUtils. So I would ask that we use StringFoo for all of these classes. I think in some places it was to avoid clash with JDK 1.5. StringBuilder I presume being the one. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
Henri Yandell wrote: On 8/2/06, Gary Gregory [EMAIL PROTECTED] wrote: I think in some places it was to avoid clash with JDK 1.5. StringBuilder I presume being the one. (I sent a mail earlier, but its not arrived) But yes, this is the key point. StrBuilder is a pre JDK5 version of StringBuilder - except that it has many many more features :-) Hence the rest of the classes are named in sympathy. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
On 7/23/06, Stephen Colebourne [EMAIL PROTECTED] wrote: I have reworked the VariableFormatter class along the lines that I was thinking. I have committed it as StrSubstitutor so it doesn't clash for the moment and so it can be easiy reviewed. This version does not have a separate parser class, but still supports escaping, and matchers for prefix/suffix (which can now be set by users). The new class should perform better as a result. I have removed the edge cases wrt resolving Objects, as they were rather ill-defined. Otherwise, the basic functionality it supported, and the test case is slightly enlarged. I still want to break out the resolver as a public abstract class before release. Opinions Oliver, Gary, Tom? Looking to get Lang 2.2 moving out the door and this is the only blocker. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
Hi,
Looks good to me. Maybe for 2.3 this patch could provide
MessageFormatting like proposed before without bloating the API. Does
this now mean that VariableFormatter is gone? I like the nameing
StrSubstitutor better.
Tom
Henri Yandell schrieb:
On 7/23/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
I have reworked the VariableFormatter class along the lines that I
was thinking. I have committed it as StrSubstitutor so it doesn't
clash for the moment and so it can be easiy reviewed.
This version does not have a separate parser class, but still
supports escaping, and matchers for prefix/suffix (which can now be
set by users). The new class should perform better as a result.
I have removed the edge cases wrt resolving Objects, as they were
rather ill-defined.
Otherwise, the basic functionality it supported, and the test case
is slightly enlarged. I still want to break out the resolver as a
public abstract class before release.
Opinions
Oliver, Gary, Tom?
Looking to get Lang 2.2 moving out the door and this is the only blocker.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index:
/home.local/tom/projects/eclipse-ws/bidi-forms/jakarta-commons-lang/src/java/org/apache/commons/lang/text/StrSubstitutor.java
===
---
/home.local/tom/projects/eclipse-ws/bidi-forms/jakarta-commons-lang/src/java/org/apache/commons/lang/text/StrSubstitutor.java
(revision 427468)
+++
/home.local/tom/projects/eclipse-ws/bidi-forms/jakarta-commons-lang/src/java/org/apache/commons/lang/text/StrSubstitutor.java
(working copy)
@@ -16,6 +16,7 @@
package org.apache.commons.lang.text;
+import java.text.MessageFormat;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
@@ -725,5 +726,84 @@
return obj.toString();
}
}
+
+/**
+ * Looks up a string value by name using a [EMAIL PROTECTED] Map} and can
use format
+ * expressions known from [EMAIL PROTECTED] MessageFormat}
+ */
+static class MapVariableResolverFormat extends MapVariableResolver {
+
+ MapVariableResolverFormat(Map map) {
+ super(map);
+ }
+
+ public String resolveVariable(String varName) {
+ int index;
+
+ if (map != null (index = varName.indexOf(,)) !=
-1) {
+ return MessageFormat.format({0 +
varName.substring(index)
+ + }, new Object[] { map.get(
+ varName.substring(0,
index)) });
+ } else {
+ return super.resolveVariable(varName);
+ }
+ }
+}
+
+/**
+ * Substitutes variables by value and allows to use the formats known from
+ * [EMAIL PROTECTED] MessageFormat}:
+ * p
+ * The following example demonstrates this:
+ * /p
+ * pre
+ * Map map = new HashMap();
+ * map.put(num,new Double(1000.103));
+ * map.put(date, new SimpleDateFormat(-MM-dd).parse(1970-01-01));
+ *
+ * StrSubstitutor.Format.replace(Number: ${num,number,integer}, Date:
${date,date,-MM-dd}, map)
+ * /pre
+ * yielding in Locale.US
+ * pre
+ * Number: 1,000, Date: 1970-01-01
+ * /pre
+ */
+public static class Format {
+ private Format() {}
+
+/**
+ * Replaces all the occurrences of variables in the given source
object with
+ * their matching values from the map.
+ *
+ * @param source the source text containing the variables to
substitute
+ * @param valueMap the map with the values
+ * @return the result of the replace operation
+ */
+public static String replace(Object source, Map valueMap) {
+ StrSubstitutor tmp = new StrSubstitutor();
+ tmp.setVariableResolver(new
MapVariableResolverFormat(valueMap));
+
+return tmp.replace(source);
+}
+/**
+ * Replaces all the occurrences of variables in the given source
object with
+ * their matching values from the map. This method allows to specifiy a
+ * custom variable prefix and suffix
+ *
+ * @param source the source text containing the variables to
substitute
+ * @param valueMap the map with the values
+ * @param prefix the prefix of variables
+ * @param suffix the suffix of variables
+ * @return the result of the replace operation
+ */
+public static String replace(Object source, Map valueMap, String
prefix, String suffix) {
+ StrSubstitutor tmp = new StrSubstitutor();
+
Re: [lang] VariableFormatter - pre 2.2
For my part
On 8/1/06, Oliver Heger [EMAIL PROTECTED] wrote:
+1 for the name StrSubstitutor.
I'm ambivalent on the name. I've always called this introspecting, but
we killed that name a while back so I'll take anything.
Well, I guess I have no chance to convince you to get back to Object as
result type for the resolver interface? Hm, for [configuration] I can
probably live with this, but it may cause unnecessary conversions.
I can't see Objects working well in string substitution unless you add
the concept of formatting, and that takes us one step further down the
road to a full on velocity clone or some such.
${date:hh:dd:mm} or whatever.
Something to consider adding in a later release, but the basic
substitution is probably a good start.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
Stephen Colebourne wrote:
Oliver Heger wrote:
+1 for the name StrSubstitutor.
:-)
Well, I guess I have no chance to convince you to get back to Object
as result type for the resolver interface? Hm, for [configuration] I
can probably live with this, but it may cause unnecessary conversions.
My review of the original code seemed to show that if there was one
substitution then the input object was returned, but if none or two
substitutions then the string was returned. This just seems like a plain
weird API.
For example There were ${number} characters, would return the object
matching the ${number} substitution, and dropping the rest of the text!
Perhaps you can point to an exact use case?
Stephen
Your analysis is correct. The idea was that you can have specialized
resolver implementations that inherently work on objects, e.g.
- a constant resolver, which interprets the variable name as a name of a
static field of a class, e.g.
${my.package.MyClass.MY_CONSTANT} would return the value of the constant
field.
- an expression resolver, which could be passed an expression in a
language like JEXL and would calculate the result.
Of course if the string passed to the substitutor contains other text
elements or variables, you have no choice than converting the result to
text. But if only a single variable is to be processed, the result can
be an arbitrary type.
But maybe you are right and this concept is not really stringent.
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
For example There were ${number} characters, would return the object
matching the ${number} substitution, and dropping the rest of the text!
Perhaps you can point to an exact use case?
Oliver Heger wrote:
Your analysis is correct. The idea was that you can have specialized
resolver implementations that inherently work on objects, e.g.
- a constant resolver, which interprets the variable name as a name of a
static field of a class, e.g.
${my.package.MyClass.MY_CONSTANT} would return the value of the constant
field.
- an expression resolver, which could be passed an expression in a
language like JEXL and would calculate the result.
Of course if the string passed to the substitutor contains other text
elements or variables, you have no choice than converting the result to
text. But if only a single variable is to be processed, the result can
be an arbitrary type.
Sounds a bit [configuration] specific to me.
However, we could add a singleVariableName(String) method which would
check for the special case where the whole string was a variable.
We could also have a variableNames(String) method which returns the top
level variable names in the string.
Not sure how useful either of these would really be though.
What might be more useful, would be to change the method signature of
resolveVariable() to take the StrBuilder start pos and current variable
start and end. That would effectively provide subclasses with much more
detailed events about the variables.
So, pre 2.2 - I'd suggest
a) alter resolveVariable()
b) extract VariableFormatter interface to be StrLookup abstract class
c) agree class name (is anyone not OK with StrSubstitutor?)
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
I have reworked the VariableFormatter class along the lines that I was thinking. I have committed it as StrSubstitutor so it doesn't clash for the moment and so it can be easiy reviewed. This version does not have a separate parser class, but still supports escaping, and matchers for prefix/suffix (which can now be set by users). The new class should perform better as a result. I have removed the edge cases wrt resolving Objects, as they were rather ill-defined. Otherwise, the basic functionality it supported, and the test case is slightly enlarged. I still want to break out the resolver as a public abstract class before release. Opinions Stephen PS. Having trouble sending mails ATM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
I have reworked the VariableFormatter class along the lines that I was thinking. I have committed it as StrSubstitutor so it doesn't clash for the moment and so it can be easiy reviewed. This version does not have a separate parser class, but still supports escaping, and matchers for prefix/suffix (which can now be set by users). The new class should perform better as a result. I have removed the edge cases wrt resolving Objects, as they were rather ill-defined. Otherwise, the basic functionality it supported, and the test case is slightly enlarged. I still want to break out the resolver as a public abstract class before release. Opinions Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
Henri Yandell schrieb: This is all that's left in 2.2 before an RC can be built. On 7/5/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: Anyone know of any half-finished code in there at the moment? I think I'm on record for saying that the VariableFormatter class doesn't quite fit as is IMHO. But I've not spelt out why, so here goes... At a minimum, I'd like to see MapVariableResolver packge scoped. Reading the following in the threads, no one seems to be against making MapVariableResolver package scoped. Personally I don't think we should have public nested classes, especially if they're intended for extension. That might just be me being a dumb user. VariableResolver is another public nested class (well interface). Any reason to not have this be package scoped for the 2.2 release as well? Well I don't mind whether the the resolver is made package scoped as long as I can somehow subclass it (at my own risk) adding the MessageFormat.format() things. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] VariableFormatter - pre 2.2
Do you'all think the variable code be simpler to groke/reuse for
customers if there we changed the nested classes into 1st class
citizens? Kinda of a side issue I know...
G
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 20, 2006 10:55 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] VariableFormatter - pre 2.2
This is all that's left in 2.2 before an RC can be built.
On 7/5/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record for saying that the VariableFormatter class
doesn't quite fit as is IMHO. But I've not spelt out why, so here
goes...
At a minimum, I'd like to see MapVariableResolver packge scoped.
Reading the following in the threads, no one seems to be against
making MapVariableResolver package scoped.
Personally I don't think we should have public nested classes,
especially if they're intended for extension. That might just be me
being a dumb user.
VariableResolver is another public nested class (well interface). Any
reason to not have this be package scoped for the 2.2 release as well?
However, I thnk I'd rather see VariableResolver changed to be a more
general StrLookup class rather like StrMatcher. That way it could be
used equally as well independent of VariableFormatter.
public class StrLookup {
String lookup(String key);
// package scoped implementation for Map
}
You could envisage other (non [lang]) accessors such as OGNL, EL,
XPath
or perhaps ones that accessed a List of strings by index.
The key point is that this shouldn't be limited to just
VariableFormatter in the same way that StrMatcher isn't limited to
StrTokenizer. Separation of Concerns.
A 2.3/3.0 subject?
Hen
-
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]
Re: [lang] VariableFormatter - pre 2.2
Henri Yandell wrote:
This is all that's left in 2.2 before an RC can be built.
On 7/5/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record for saying that the VariableFormatter class
doesn't quite fit as is IMHO. But I've not spelt out why, so here goes...
At a minimum, I'd like to see MapVariableResolver packge scoped.
Reading the following in the threads, no one seems to be against
making MapVariableResolver package scoped.
Personally I don't think we should have public nested classes,
especially if they're intended for extension. That might just be me
being a dumb user.
VariableResolver is another public nested class (well interface). Any
reason to not have this be package scoped for the 2.2 release as well?
If this interface was made package scope, it could not be implemented by
client code. So the option of providing specialized variable resolver
implementations (which I need for my purposes) would be lost. Or am I
missing something?
Oliver
However, I thnk I'd rather see VariableResolver changed to be a more
general StrLookup class rather like StrMatcher. That way it could be
used equally as well independent of VariableFormatter.
public class StrLookup {
String lookup(String key);
// package scoped implementation for Map
}
You could envisage other (non [lang]) accessors such as OGNL, EL, XPath
or perhaps ones that accessed a List of strings by index.
The key point is that this shouldn't be limited to just
VariableFormatter in the same way that StrMatcher isn't limited to
StrTokenizer. Separation of Concerns.
A 2.3/3.0 subject?
Hen
-
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]
Re: [lang] VariableFormatter - pre 2.2
On 7/21/06, Oliver Heger [EMAIL PROTECTED] wrote: Henri Yandell wrote: This is all that's left in 2.2 before an RC can be built. On 7/5/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: Anyone know of any half-finished code in there at the moment? I think I'm on record for saying that the VariableFormatter class doesn't quite fit as is IMHO. But I've not spelt out why, so here goes... At a minimum, I'd like to see MapVariableResolver packge scoped. Reading the following in the threads, no one seems to be against making MapVariableResolver package scoped. Personally I don't think we should have public nested classes, especially if they're intended for extension. That might just be me being a dumb user. VariableResolver is another public nested class (well interface). Any reason to not have this be package scoped for the 2.2 release as well? If this interface was made package scope, it could not be implemented by client code. So the option of providing specialized variable resolver implementations (which I need for my purposes) would be lost. Or am I missing something? I think that was definitely Stephen's aim. Basically I want to get Lang 2.2 out and have this discussion be a part of 2.3. Stephen's suggestion allows us to get the basic VariableFormatter functionality that most people need (I think?) out there and continue talking about the more powerful aspects for a later release. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
This is all that's left in 2.2 before an RC can be built.
On 7/5/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record for saying that the VariableFormatter class
doesn't quite fit as is IMHO. But I've not spelt out why, so here goes...
At a minimum, I'd like to see MapVariableResolver packge scoped.
Reading the following in the threads, no one seems to be against
making MapVariableResolver package scoped.
Personally I don't think we should have public nested classes,
especially if they're intended for extension. That might just be me
being a dumb user.
VariableResolver is another public nested class (well interface). Any
reason to not have this be package scoped for the 2.2 release as well?
However, I thnk I'd rather see VariableResolver changed to be a more
general StrLookup class rather like StrMatcher. That way it could be
used equally as well independent of VariableFormatter.
public class StrLookup {
String lookup(String key);
// package scoped implementation for Map
}
You could envisage other (non [lang]) accessors such as OGNL, EL, XPath
or perhaps ones that accessed a List of strings by index.
The key point is that this shouldn't be limited to just
VariableFormatter in the same way that StrMatcher isn't limited to
StrTokenizer. Separation of Concerns.
A 2.3/3.0 subject?
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
On 7/7/06, Oliver Heger [EMAIL PROTECTED] wrote: Stephen Colebourne wrote: snip/ Oliver Heger wrote: Fine with me, but could the return value of lookup be Object instead of String? Especially if you want to use this interface in other areas, you might need more freedom. If only String processing needs to be performed, the returned Object can be transformed to a String by calling toString(). But what kind of object are you expectng to be returned here (other than a String)? A similar question applies to the replaceObject() method which appears to have very odd semantics as you can't rely on the return value being of any specific type. What Objects are you expecting to work with? Stephen I plan to use the class in [configuration] for variable substitution. A variable can represent a configuration property, which can have an arbitrary type. Anything further on this thread? Any sign of consensus? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
Stephen Colebourne wrote: snip/ Oliver Heger wrote: Fine with me, but could the return value of lookup be Object instead of String? Especially if you want to use this interface in other areas, you might need more freedom. If only String processing needs to be performed, the returned Object can be transformed to a String by calling toString(). But what kind of object are you expectng to be returned here (other than a String)? A similar question applies to the replaceObject() method which appears to have very odd semantics as you can't rely on the return value being of any specific type. What Objects are you expecting to work with? Stephen I plan to use the class in [configuration] for variable substitution. A variable can represent a configuration property, which can have an arbitrary type. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
Stephen Colebourne wrote:
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record for saying that the VariableFormatter class
doesn't quite fit as is IMHO. But I've not spelt out why, so here goes...
At a minimum, I'd like to see MapVariableResolver packge scoped.
However, I thnk I'd rather see VariableResolver changed to be a more
general StrLookup class rather like StrMatcher. That way it could be
used equally as well independent of VariableFormatter.
public class StrLookup {
String lookup(String key);
// package scoped implementation for Map
}
You could envisage other (non [lang]) accessors such as OGNL, EL, XPath
or perhaps ones that accessed a List of strings by index.
The key point is that this shouldn't be limited to just
VariableFormatter in the same way that StrMatcher isn't limited to
StrTokenizer. Separation of Concerns.
Fine with me, but could the return value of lookup be Object instead of
String? Especially if you want to use this interface in other areas, you
might need more freedom. If only String processing needs to be
performed, the returned Object can be transformed to a String by calling
toString().
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] VariableFormatter - pre 2.2
Hello All:
At a minimum, I'd like to see MapVariableResolver packge scoped.
Looking at the message thread:
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg78697.html
It seems that another proposal being discussed back in April was to make
some classes /easier/ to reuse and extend for the more advanced users by
making them come out of inner, which would also mean keeping them
public.
However, I thnk I'd rather see VariableResolver changed to be a more
general StrLookup class rather like StrMatcher. That way it could be
used equally as well independent of VariableFormatter.
The challenge to me here is that I've heard some folks says they do not
want [lang] to become too framework-like. I am wondering if making
VariableResolver more generic would go in that direction. The nice thing
I see about the way it is now is that the solution is on making the
variable resolver pluggable and nothing more. Which is a draw back if
that interface is really /that great/.
FWIW, I am pretty happy with using the VariableFormatter class as is and
plan on doing so (as soon as my work schedule allows.)
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 05, 2006 5:07 PM
To: Jakarta Commons Developers List
Subject: [lang] VariableFormatter - pre 2.2
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record for saying that the VariableFormatter class
doesn't quite fit as is IMHO. But I've not spelt out why, so here
goes...
At a minimum, I'd like to see MapVariableResolver packge scoped.
However, I thnk I'd rather see VariableResolver changed to be a more
general StrLookup class rather like StrMatcher. That way it could be
used equally as well independent of VariableFormatter.
public class StrLookup {
String lookup(String key);
// package scoped implementation for Map
}
You could envisage other (non [lang]) accessors such as OGNL, EL,
XPath
or perhaps ones that accessed a List of strings by index.
The key point is that this shouldn't be limited to just
VariableFormatter in the same way that StrMatcher isn't limited to
StrTokenizer. Separation of Concerns.
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]
Re: [lang] VariableFormatter - pre 2.2
Gary Gregory wrote: At a minimum, I'd like to see MapVariableResolver packge scoped. Looking at the message thread: http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg78697.html It seems that another proposal being discussed back in April was to make some classes /easier/ to reuse and extend for the more advanced users by making them come out of inner, which would also mean keeping them public. The problem here is that once we publish the API thats it, we can't unpublish it. MapVariableResolver seems like an internal class that we create for our own needs. All the constructors allow for a Map to be passed in, so the users of MapVariableResolver will be very much edge case users. However, I thnk I'd rather see VariableResolver changed to be a more general StrLookup class rather like StrMatcher. That way it could be used equally as well independent of VariableFormatter. Gary Gregory wrote: The challenge to me here is that I've heard some folks says they do not want [lang] to become too framework-like. I am wondering if making VariableResolver more generic would go in that direction. The nice thing I see about the way it is now is that the solution is on making the variable resolver pluggable and nothing more. Which is a draw back if that interface is really /that great/. The question is whether we can see a [lang] use case for using StrLookup other than in VariableFormatter. Oliver Heger wrote: Fine with me, but could the return value of lookup be Object instead of String? Especially if you want to use this interface in other areas, you might need more freedom. If only String processing needs to be performed, the returned Object can be transformed to a String by calling toString(). But what kind of object are you expectng to be returned here (other than a String)? A similar question applies to the replaceObject() method which appears to have very odd semantics as you can't rely on the return value being of any specific type. What Objects are you expecting to work with? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] VariableFormatter - pre 2.2
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record for saying that the VariableFormatter class
doesn't quite fit as is IMHO. But I've not spelt out why, so here goes...
At a minimum, I'd like to see MapVariableResolver packge scoped.
However, I thnk I'd rather see VariableResolver changed to be a more
general StrLookup class rather like StrMatcher. That way it could be
used equally as well independent of VariableFormatter.
public class StrLookup {
String lookup(String key);
// package scoped implementation for Map
}
You could envisage other (non [lang]) accessors such as OGNL, EL, XPath
or perhaps ones that accessed a List of strings by index.
The key point is that this shouldn't be limited to just
VariableFormatter in the same way that StrMatcher isn't limited to
StrTokenizer. Separation of Concerns.
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
