[jira] Updated: (BEANUTILS-265) Allow access to public methods from not public classes
[
https://issues.apache.org/jira/browse/BEANUTILS-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Schindl updated BEANUTILS-265:
--
Attachment: beanutils.txt
> Allow access to public methods from not public classes
> --
>
> Key: BEANUTILS-265
> URL: https://issues.apache.org/jira/browse/BEANUTILS-265
> Project: Commons BeanUtils
> Issue Type: New Feature
> Components: Bean / Property Utils
>Affects Versions: 1.7.0
> Reporter: Tom Schindl
> Attachments: beanutils.txt
>
>
> Currently BeanUtils doesn't provide the possibility to access getters and
> setters in classes who are package-scoped!
> ---8<---
> class HiddenBean {
> private String a;
>
> protected HiddenBean() {
>
> }
>
> public void setA(String a) {
> this.a = a;
> }
>
> public String getA() {
> return this.a;
> }
> }
> public class PublicBean extends HiddenBean {
> }
> ---8<---
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] Why does needs the method declaring a class to be public
Craig McClanahan schrieb: > On 11/23/06, Tom Schindl <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> the problem are not the methods visibility the methods in the sub-class >> are public but their class declaration is not and you can call them if >> you method.setAccessible(true) I've currently modified BeanUtils in my >> project and it works perfectly. > > > This solution will work (by default) ... until you try it on a server where > a security manager with rational policies is enabled by default (such as > had > *better* be the case, for example, in a server environment that shares a > JVM > across multiple third party webapps). If you don't think this is imprtant, > you might as well be coding in a scripting language, because you are giving > up one of the key advantages of using a strongly typed language like Java. you are right in server environments this might bring us into trouble under certain circumstance. That's why I proposed to make this configurable because e.g. in my case stand-alone SWT-Application (Loading GUI from XML) doesn't have any problems with it. BTW what I can not really understand is why I can not call a *public* method from a class without setAccessible(true) using reflection when I can do it in any ordinary java application. Providing access to private, package, protected scoped methods should not be allowed by the way using BeanUtils. The only thing I request is to call public methods! Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] Why does needs the method declaring a class to be public
Hi, Craig McClanahan schrieb: > On 11/23/06, Henri Yandell <[EMAIL PROTECTED]> wrote: [...] > If BeanUtils is going to continue to evolve on the trajectory that seems to > be epitomized by recent comments on the mailing list and in JIRA issues, it > will need to be modified to deal with scenarios like this. On the other > hand, more modern approaches to both configuration management (alternative > strategies for parsing configuration files plus completely different > approaches like JAXB), plus the decoupling of modern web frameworks from > hard coded things like a Struts ActionForm, means that my personal need to > care about what happens in BeanUtils is pretty much zero. I don't consider > it an appropriate place to do innovative development, but if you are > interested in improving support for legacy applications then it is (of > course) fertile ground for incremental improvements -- some of which could > be pretty substantial improvements in usabilty. > Well for me BeanUtils are a really usable components because the classes I need to deal with in my framework are not 100% JavaBeans (they are SWT-Widgets I'm loading from XML-Spec to design GUIs in a language called XSWT) so other technologies to instantiate them fail for me miserably and BeanUtils really help me here a lot to set the various values with nearly no custom code. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (BEANUTILS-265) Allow access to public methods from not public classes
Allow access to public methods from not public classes
--
Key: BEANUTILS-265
URL: http://issues.apache.org/jira/browse/BEANUTILS-265
Project: Commons BeanUtils
Issue Type: New Feature
Components: Bean / Property Utils
Affects Versions: 1.7.0
Reporter: Tom Schindl
Currently BeanUtils doesn't provide the possibility to access getters and
setters in classes who are package-scoped!
---8<---
class HiddenBean {
private String a;
protected HiddenBean() {
}
public void setA(String a) {
this.a = a;
}
public String getA() {
return this.a;
}
}
public class PublicBean extends HiddenBean {
}
---8<---
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] Why does needs the method declaring a class to be public
Thanks Henri,
maybe we could make this configurable somehow. I can't read somewhere in
the spec of JavaBeans that you can't use inheritance.
Tom
Henri Yandell schrieb:
> JIRA reports are good - we've a big backlog in BeanUtils but it's
> starting to go down.
>
> There are a couple of other similar issues (BEANUTILS-157 + BEANUTILS-87).
>
> I don't know why the API is designed to only work with public methods;
> whether that's an aspect of adherence to the spec, by design or
> legacy. Seems that if we're going to use setAccessible, that we could
> just open it to package and private too.
>
> Anyone know why MethodUtils intentionally limits itself?
>
> Hen
>
> On 11/22/06, Tom Schindl <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Nobody any comments should I file a bug report against JIRA?
>>
>> Tom
>>
>> Tom Schindl schrieb:
>> > Hi,
>> >
>> > I have an issue the current implementation of
>> >
>> > MethodUtils#getAccessibleMethod(Method) where it reads:
>> >
>> > 8<
>> > if( Modifier.isPublic(clazz.getModifiers()) ) {
>> >
>> > }
>> >
>> > // Check the implemented interfaces and subinterfaces
>> > 8<
>> >
>> > With this check setting attributes on a class Hierarchy like the one
>> > below doesn't work:
>> >
>> > 8<
>> > class HiddenBean {
>> > private String a;
>> >
>> > protected HiddenBean() {
>> >
>> > }
>> >
>> > public void setA(String a) {
>> > this.a = a;
>> > }
>> >
>> > public String getA() {
>> > return this.a;
>> > }
>> > }
>> >
>> > public class PublicBean extends HiddenBean {
>> >
>> > }
>> > 8<
>> >
>> > The problem is that big framework like e.g. Eclipse often use
>> > package-visible classes to not expose too much API to the user and you
>> > can't use BeanUtils currently to set values.
>> >
>> > I came across this problem when trying to provide an enhanced
>> version of
>> > XSWT which is not working in Eclipse 3.2 but not in 3.3 any more
>> because
>> > of this.
>> >
>> > What would be the problem to change the check to the following:
>> >
>> > MethodUtils#getAccessibleMethod(Method):
>> > 8<
>> > if( ! Modifier.isPrivate(clazz.getModifiers()) && !
>> > Modifier.isPackage(clazz.getModifiers()) ) {
>> >
>> > }
>> > 8<
>> >
>> > PropertyUtilsBean#invokeMethod(...):
>> > 8<
>> > method.setAccessible(true);
>> > return method.invoke(bean,values);
>> > 8<
>> >
>> > I first wanted to discuss this here and not creating an bug
>> immediately.
>> >
>> > Tom
>> >
>> > -
>> > 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]
>>
>>
>
> -
> 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: [BeanUtils] Why does needs the method declaring a class to be public
Hi,
the problem are not the methods visibility the methods in the sub-class
are public but their class declaration is not and you can call them if
you method.setAccessible(true) I've currently modified BeanUtils in my
project and it works perfectly.
Tom
Will Pugh schrieb:
> Since, MethodUtils is not going to be in the same package as whatever
> class you are calling a method on, I don't think you going to be allowed
> to call a package, protected or private methods in that class?
>
>--Will
>
> Henri Yandell wrote:
>> JIRA reports are good - we've a big backlog in BeanUtils but it's
>> starting to go down.
>>
>> There are a couple of other similar issues (BEANUTILS-157 +
>> BEANUTILS-87).
>>
>> I don't know why the API is designed to only work with public methods;
>> whether that's an aspect of adherence to the spec, by design or
>> legacy. Seems that if we're going to use setAccessible, that we could
>> just open it to package and private too.
>>
>> Anyone know why MethodUtils intentionally limits itself?
>>
>> Hen
>>
>> On 11/22/06, Tom Schindl <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>> Nobody any comments should I file a bug report against JIRA?
>>>
>>> Tom
>>>
>>> Tom Schindl schrieb:
>>> > Hi,
>>> >
>>> > I have an issue the current implementation of
>>> >
>>> > MethodUtils#getAccessibleMethod(Method) where it reads:
>>> >
>>> > 8<
>>> > if( Modifier.isPublic(clazz.getModifiers()) ) {
>>> >
>>> > }
>>> >
>>> > // Check the implemented interfaces and subinterfaces
>>> > 8<
>>> >
>>> > With this check setting attributes on a class Hierarchy like the one
>>> > below doesn't work:
>>> >
>>> > 8<
>>> > class HiddenBean {
>>> > private String a;
>>> >
>>> > protected HiddenBean() {
>>> >
>>> > }
>>> >
>>> > public void setA(String a) {
>>> > this.a = a;
>>> > }
>>> >
>>> > public String getA() {
>>> > return this.a;
>>> > }
>>> > }
>>> >
>>> > public class PublicBean extends HiddenBean {
>>> >
>>> > }
>>> > 8<
>>> >
>>> > The problem is that big framework like e.g. Eclipse often use
>>> > package-visible classes to not expose too much API to the user and you
>>> > can't use BeanUtils currently to set values.
>>> >
>>> > I came across this problem when trying to provide an enhanced
>>> version of
>>> > XSWT which is not working in Eclipse 3.2 but not in 3.3 any more
>>> because
>>> > of this.
>>> >
>>> > What would be the problem to change the check to the following:
>>> >
>>> > MethodUtils#getAccessibleMethod(Method):
>>> > 8<
>>> > if( ! Modifier.isPrivate(clazz.getModifiers()) && !
>>> > Modifier.isPackage(clazz.getModifiers()) ) {
>>> >
>>> > }
>>> > 8<
>>> >
>>> > PropertyUtilsBean#invokeMethod(...):
>>> > 8<
>>> > method.setAccessible(true);
>>> > return method.invoke(bean,values);
>>> > 8<
>>> >
>>> > I first wanted to discuss this here and not creating an bug
>>> immediately.
>>> >
>>> > Tom
>>> >
>>> > -
>>> > 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]
>>>
>>>
>>
>> -
>> 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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] Why does needs the method declaring a class to be public
Hi,
Nobody any comments should I file a bug report against JIRA?
Tom
Tom Schindl schrieb:
> Hi,
>
> I have an issue the current implementation of
>
> MethodUtils#getAccessibleMethod(Method) where it reads:
>
> 8<
> if( Modifier.isPublic(clazz.getModifiers()) ) {
>
> }
>
> // Check the implemented interfaces and subinterfaces
> 8<
>
> With this check setting attributes on a class Hierarchy like the one
> below doesn't work:
>
> 8<
> class HiddenBean {
> private String a;
>
> protected HiddenBean() {
>
> }
>
> public void setA(String a) {
> this.a = a;
> }
>
> public String getA() {
> return this.a;
> }
> }
>
> public class PublicBean extends HiddenBean {
>
> }
> 8<
>
> The problem is that big framework like e.g. Eclipse often use
> package-visible classes to not expose too much API to the user and you
> can't use BeanUtils currently to set values.
>
> I came across this problem when trying to provide an enhanced version of
> XSWT which is not working in Eclipse 3.2 but not in 3.3 any more because
> of this.
>
> What would be the problem to change the check to the following:
>
> MethodUtils#getAccessibleMethod(Method):
> 8<
> if( ! Modifier.isPrivate(clazz.getModifiers()) && !
> Modifier.isPackage(clazz.getModifiers()) ) {
>
> }
> 8<
>
> PropertyUtilsBean#invokeMethod(...):
> 8<
> method.setAccessible(true);
> return method.invoke(bean,values);
> 8<
>
> I first wanted to discuss this here and not creating an bug immediately.
>
> Tom
>
> -
> 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]
[BeanUtils] Why does needs the method declaring a class to be public
Hi,
I have an issue the current implementation of
MethodUtils#getAccessibleMethod(Method) where it reads:
8<
if( Modifier.isPublic(clazz.getModifiers()) ) {
}
// Check the implemented interfaces and subinterfaces
8<
With this check setting attributes on a class Hierarchy like the one
below doesn't work:
8<
class HiddenBean {
private String a;
protected HiddenBean() {
}
public void setA(String a) {
this.a = a;
}
public String getA() {
return this.a;
}
}
public class PublicBean extends HiddenBean {
}
8<
The problem is that big framework like e.g. Eclipse often use
package-visible classes to not expose too much API to the user and you
can't use BeanUtils currently to set values.
I came across this problem when trying to provide an enhanced version of
XSWT which is not working in Eclipse 3.2 but not in 3.3 any more because
of this.
What would be the problem to change the check to the following:
MethodUtils#getAccessibleMethod(Method):
8<
if( ! Modifier.isPrivate(clazz.getModifiers()) && !
Modifier.isPackage(clazz.getModifiers()) ) {
}
8<
PropertyUtilsBean#invokeMethod(...):
8<
method.setAccessible(true);
return method.invoke(bean,values);
8<
I first wanted to discuss this here and not creating an bug immediately.
Tom
-
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
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.resolveV
Re: [lang] VariableFormatter - pre 2.2
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}:
> + *
> + * The following example demonstrates this:
> + *
> + *
> + * 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)
> + *
> + * yielding in Locale.US
> + *
> + * Number: 1,000, Date: 1970-01-01
> + *
> + */
> +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
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}:
+ *
+ * The following example demonstrates this:
+ *
+ *
+ * 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)
+ *
+ * yielding in Locale.US
+ *
+ * Number: 1,000, Date: 1970-01-01
+ *
+ */
+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) {
+ Str
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]
[jira] Commented: (LANG-197) [lang] Extending VariableFormatter to use FormatPatterns
[ http://issues.apache.org/jira/browse/LANG-197?page=comments#action_12415991 ] Tom Schindl commented on LANG-197: -- Well that's sad because I think would not have been a great deal to add this functionality and it would make VariableFormatter much more feature rich so I have to maintain my I own fork but that's not a problem. > [lang] Extending VariableFormatter to use FormatPatterns > > > Key: LANG-197 > URL: http://issues.apache.org/jira/browse/LANG-197 > Project: Commons Lang > Type: Improvement > Versions: 2.1 > Environment: Operating System: All > Platform: Other > Reporter: Tom Schindl > Priority: Minor > Fix For: 3.0 > Attachments: VariableFormatterWithFormating.java, > VariableFormatterWithFormatingTest.java, patch.txt > > It would be great to extend VariableFormatter to use Format-Patterns like > MessageFormat does it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-197) [lang] Extending VariableFormatter to use FormatPatterns
[ http://issues.apache.org/jira/browse/LANG-197?page=all ] Tom Schindl updated LANG-197: - Attachment: patch.txt > [lang] Extending VariableFormatter to use FormatPatterns > > > Key: LANG-197 > URL: http://issues.apache.org/jira/browse/LANG-197 > Project: Commons Lang > Type: Improvement > Versions: 2.1 > Environment: Operating System: All > Platform: Other > Reporter: Tom Schindl > Priority: Minor > Fix For: 2.2 > Attachments: VariableFormatterWithFormating.java, > VariableFormatterWithFormatingTest.java, patch.txt > > It would be great to extend VariableFormatter to use Format-Patterns like > MessageFormat does it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter issues
>>>The implementation in the ticket subclasses VariableFormatter, why not >>>subclass just MapVariableResolver only? >>> >>> >>> >> >>Because of the above mentionned bloated API if you want to turn it >>on/off in VariableFormatter. >> >> > > I think part of the problem is that many method signatures expect a Map > and convert this automatically into a MapVariableResolver (e.g. > constructors of VariableFormatter, static replace() methods). This is > convenient for the users that only need the default functionality, but > makes it hard to use a different VariableResolver implementation. > > Shouldn't we at least have static replace() methods that take a > VariableResolver as argument? Then a caller can decide if he/she wants a > default or a formatting enabled resolver. > Yeah. I agree 100% with you Oliver having such a method and adding an boolean attribute to MapVariableResolver to turn on/off the feature would be sufficient. Tom signature.asc Description: OpenPGP digital signature
Re: [lang] VariableFormatter issues
Gary Gregory wrote:
> Hello:
>
> I wonder if in the interest of getting version 2.2 out the door we
> should keep VariableFormatter as-is. Anyone who likes the subclass can
> obviously use it. If the feature is easy to add, we don't have to
> discuss the following for post-2.2:
>
> - Does the VariableFormatterWithFormating functionality belong in
> VariableFormatter or should it be a subclass.
>
> - It seems like we could also extend the current ${} syntax to include
> the VariableFormatterWithFormating feature. Where this gets tricky and
> could become difficult is if we cannot reuse MessageFormat.format.
>
> Tom (and all):
>
> Have you considered changing VariableFormatter itself to provide the
> feature?
>
Yes but I thought if you want to turn on/off variable formatting (e.g.
because of performance issues) the API would get too bloated, you need
to duplicate all static functions, wouldn't you?
> Would changing MapVariableResolver only do the trick?
>
Yes, I think so but I wasn't sure about the side-effects.
> The implementation in the ticket subclasses VariableFormatter, why not
> subclass just MapVariableResolver only?
>
Because of the above mentionned bloated API if you want to turn it
on/off in VariableFormatter.
> To make the code more reusable we should be open to making the inner
> classes stand alone.
>
That would be a great thing to have.
> Gary
>
I think adding this formatting to VariableFormatter makes it more
useable e.g. for displaying debugging messages than it would be now.
Tom
signature.asc
Description: PGP signature
signature.asc
Description: OpenPGP digital signature
Re: [lang] VariableFormatter issues
Gary Gregory wrote:
> Hello:
>
> I wonder if in the interest of getting version 2.2 out the door we
> should keep VariableFormatter as-is. Anyone who likes the subclass can
> obviously use it. If the feature is easy to add, we don't have to
> discuss the following for post-2.2:
>
> - Does the VariableFormatterWithFormating functionality belong in
> VariableFormatter or should it be a subclass.
>
> - It seems like we could also extend the current ${} syntax to include
> the VariableFormatterWithFormating feature. Where this gets tricky and
> could become difficult is if we cannot reuse MessageFormat.format.
>
> Tom (and all):
>
> Have you considered changing VariableFormatter itself to provide the
> feature?
>
Yes but I thought if you want to turn on/off variable formatting (e.g.
because of performance issues) the API would get too bloated, you need
to duplicate all static functions, wouldn't you?
> Would changing MapVariableResolver only do the trick?
>
Yes, I think so but I wasn't sure about the side-effects.
> The implementation in the ticket subclasses VariableFormatter, why not
> subclass just MapVariableResolver only?
>
Because of the above mentionned bloated API if you want to turn it
on/off in VariableFormatter.
> To make the code more reusable we should be open to making the inner
> classes stand alone.
>
That would be a great thing to have.
> Gary
>
I think adding this formatting to VariableFormatter makes it more
useable e.g. for displaying debugging messages than it would be now.
Tom
signature.asc
Description: OpenPGP digital signature
Re: [lang] VariableFormatter issues
Gary Gregory wrote: >>-Original Message- >>From: Henri Yandell [mailto:[EMAIL PROTECTED] >>Sent: Monday, April 24, 2006 12:12 AM >>To: Jakarta Commons Developers List >>Subject: [lang] VariableFormatter issues >> >>Our favourite 'will this become a templating language' class. >> >>Two issues to ask questions about: >> >>1) First enhancement request: #36873. Adds MessageFormat like format >>patterns. It's an enhancement, seems like a pretty good one to me as >>it is an enhancement that builds on the JDK and not a new feature. How >>does this sit on people's slippery slopes? > > > This is interesting and slippery. Since the submitted code uses > "MessageFormat.format", we are not inventing a language, just accessing > a JRE feature. > > OTOH, the class VariableFormatter is named as such *because* it is not a > "Format" subclass and was not intended to be. So providing "Format" > features via a subclass to VariableFormatter is clean in the sense that > we are not mixing things up but not really what I had in mind (that's > the great part about OS). OTOH (the OOH), if we really think this is a > fantastic feature, we should consider if it should be better integrated > than with a subclass. > > I like VariableFormatter the way it is. So I am neutral as to using the > submitted code. If we do use "VariableFormatterWithFormating", could we > consider better class name? > Well I like it (maybe because I've submitted it) and use it frequently in my source codes. I wasn't really happy with the name too, still in my idea you don't need a sub-class a better idea would be a flag passed and turns on/off formatting but on the other hand this would maybe blow up the numer of API-Functions. Tom signature.asc Description: OpenPGP digital signature
Re: [lang] VariableFormatter-Patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks Gary that's great now I can maintain my sub-class of variable formatter which can use formats like MessageFormat in my own package-space. Tom Gary Gregory wrote: > Tom: > > I've made the constants public for easier access from subclasses or > wrappers. > > Thanks for the suggestions. Now in SVN. > > Gary > > >>-Original Message- >>From: Tom Schindl [mailto:[EMAIL PROTECTED] >>Sent: Tuesday, September 27, 2005 4:50 AM >>To: commons-dev@jakarta.apache.org >>Subject: [lang] VariableFormatter-Patch >> >>Hi, >> >>is it possible to change the visibility of constants in >>VariableFormatter protected. This way one could easily sub-class the >>VariableFormatter and write its own. The appended patch does that. >> >>Tom > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFDOZF3kVPeOFLgZFIRAmpeAKCl9ykhMx2S3z2nPPO7+MYhszRjpACffkFI jFE+YUIVqzI5lCasWnk2VV8= =NpYf -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] VariableFormatter-Patch
Hi,
is it possible to change the visibility of constants in
VariableFormatter protected. This way one could easily sub-class the
VariableFormatter and write its own. The appended patch does that.
Tom
Index:
E:/eclipse-workspaces/beso/jakart-lang/src/java/org/apache/commons/lang/text/VariableFormatter.java
===
---
E:/eclipse-workspaces/beso/jakart-lang/src/java/org/apache/commons/lang/text/VariableFormatter.java
(revision 291638)
+++
E:/eclipse-workspaces/beso/jakart-lang/src/java/org/apache/commons/lang/text/VariableFormatter.java
(working copy)
@@ -465,13 +465,13 @@
}
/** Constant for the default escape character. */
-static final char DEFAULT_ESCAPE = '$';
+protected static final char DEFAULT_ESCAPE = '$';
/** Constant for the default variable prefix. */
-static final String DEFAULT_PREFIX = "${";
+protected static final String DEFAULT_PREFIX = "${";
/** Constant for the default variable suffix. */
-static final String DEFAULT_SUFFIX = "}";
+protected static final String DEFAULT_SUFFIX = "}";
/**
* Replaces the occurrences of all variables in the given source data by
their current values obtained from the
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Questions concerning VariableFormatter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
oh. and the last VariableFormatter now really working.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFDAlIUkVPeOFLgZFIRAp9PAJ9/VFwjRFT62dF+dmREvbsHV3L0pQCgrYmm
g2j04O/D+oOmFZwT9jxs/WA=
=Ij5q
-END PGP SIGNATURE-
package org.apache.commons.lang.text;
import java.text.MessageFormat;
import java.util.Map;
public class VariableFormatterWithFormating extends VariableFormatter {
/**
*
* A VariableResolver backed by a [EMAIL PROTECTED] Map} who uses Formats like MessageFormat does
*
* @author Tom Schindl
* @version $Id: $
*/
public static class MapVariableResolverWithFormats extends MapVariableResolver {
/**
* Creates a new variable resolver to handle formats like
* [EMAIL PROTECTED] MessageFormat} does it. You can use e.g. {today,date,short} to
* format the variable today as a short date
*
* @param map
*The variable names and values.
*/
public MapVariableResolverWithFormats(Map map) {
super(map);
}
/**
* Resolves the variable and formats the object retrieved using
* [EMAIL PROTECTED] MessageFormat}
*
* @param varName
*name of the variable and optionally the data-type and
*data-format seperated by comma
*/
public Object resolveVariable(String varName) {
int index;
if (this.getMap() != null && (index = varName.indexOf(",")) != -1) {
return MessageFormat.format("{0" + varName.substring(index)
+ "}", new Object[] { this.getMap().get(
varName.substring(0, index)) });
} else {
return super.resolveVariable(varName);
}
}
}
/**
* Creates a new instance with defaults for variable prefix and suffix and the escaping character.
*/
public VariableFormatterWithFormating() {
this((VariableResolver) null, DEFAULT_PREFIX, DEFAULT_SUFFIX, DEFAULT_ESCAPE);
}
/**
* Creates a new instance and initializes it. Uses defaults for variable prefix and suffix and the escaping
* character.
*
* @param valueMap
*the map with the variables' values
*/
public VariableFormatterWithFormating(Map valueMap) {
this(valueMap, DEFAULT_PREFIX, DEFAULT_SUFFIX, DEFAULT_ESCAPE);
}
/**
* Creates a new instance and initializes it. Uses a default escaping character.
*
* @param valueMap
*the map with the variables' values
* @param prefix
*the prefix for variables
* @param suffix
*the suffix for variables
*/
public VariableFormatterWithFormating(Map valueMap, String prefix, String suffix) {
this(valueMap, prefix, suffix, DEFAULT_ESCAPE);
}
/**
* Creates a new instance and initializes it.
*
* @param valueMap
*the map with the variables' values
* @param prefix
*the prefix for variables
* @param suffix
*the suffix for variables
* @param escape
*the escape character
*/
public VariableFormatterWithFormating(Map valueMap, String prefix, String suffix, char escape) {
this(new MapVariableResolverWithFormats(valueMap), prefix, suffix, escape);
}
/**
* Creates a new instance and initializes it.
*
* @param variableResolver
*the variable resolver
* @param prefix
*the prefix for variables
* @param suffix
*the suffix for variables
* @param escape
*the escape character
*/
public VariableFormatterWithFormating(VariableResolver variableResolver, String prefix, String suffix, char escape) {
super(variableResolver,prefix,suffix,escape);
}
/**
* Replaces the occurrences of all variables in the given source data by their current values obtained from the
* passed in map.
*
* @param valueMap
*the map with the values
* @param source
*the source text
* @return the result of the replace operation
*/
public static String replace(Map valueMap, Object source) {
return new VariableFormatterWithFormating(valueMap).replace(source);
}
/**
* Replaces the occurrences of all variables in the given source data by their current values obtained from the
* passed in map. This method allows to specifiy a custom variable prefix and suffix
*
* @param valueMap
*the map with the values
* @param prefix
*the prefix of variables
* @param suffix
*the suffix of variables
* @param source
*the
Re: [lang] Questions concerning VariableFormatter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary Gregory wrote:
> Hello Tom:
>
> Please provide unit tests. I want to see this code in action in order to
> figure out what the intent of the class really is.
>
> Thanks,
> Gary
>
>
No. A very limited one but the idea should be clear ;-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFDAlHXkVPeOFLgZFIRAqbuAJ4ulPg3hGUkiCbWNunfNW+mtEUN0wCfQM/Q
XEZ2JafiiJF66IDnlfJ5adg=
=tD9P
-END PGP SIGNATURE-
import java.util.Date;
import java.util.HashMap;
import java.util.Locale;
import org.apache.commons.lang.text.VariableFormatterWithFormating;
import junit.framework.TestCase;
public class VariableFormatterWithFormatingTest extends TestCase {
/*
* Test method for 'org.apache.commons.lang.text.VariableFormatterWithFormating.replace(Map, Object)'
*/
public void testReplaceMapObject() {
HashMap map = new HashMap();
map.put("date",new Date(0));
map.put("number",new Double(100.2));
Locale.setDefault(Locale.US);
String message = new String("On ${date,date,-mm-dd} I earned ${number,number,currency}");
assertEquals("On 1970-00-01 I earned $100.20",VariableFormatterWithFormating.replace(map,message));
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Questions concerning VariableFormatter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary Gregory wrote:
> Tom:
>
> If you'd like to make things easier for me, what you could do is
> resubmit your patches against the current code base. I'll try to take a
> look tonight or tomorrow night.
>
> Thanks,
> Gary
>
Hi Gary,
I haven't patch for the latest SVN but I have a class which extends
VariableFormatter. It hasn't got a good name but it should show what I'm
trying to achieve.
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFDAkvokVPeOFLgZFIRAkleAJ9DGNXcfZogEioPOG8gXYSuW7m0LQCdGlcx
q8lv86JylSuRlZdAsDvqmag=
=Zfpj
-END PGP SIGNATURE-
package org.apache.commons.lang.text;
import java.text.MessageFormat;
import java.util.Map;
public class VariableFormatterWithFormating extends VariableFormatter {
/**
*
* A VariableResolver backed by a [EMAIL PROTECTED] Map} who uses Formats like MessageFormat does
*
* @author Tom Schindl
* @version $Id: $
*/
public static class MapVariableResolverWithFormats extends MapVariableResolver {
/**
* Creates a new variable resolver to handle formats like
* [EMAIL PROTECTED] MessageFormat} does it. You can use e.g. {today,date,short} to
* format the variable today as a short date
*
* @param map
*The variable names and values.
*/
public MapVariableResolverWithFormats(Map map) {
super(map);
}
/**
* Resolves the variable and formats the object retrieved using
* [EMAIL PROTECTED] MessageFormat}
*
* @param varName
*name of the variable and optionally the data-type and
*data-format seperated by comma
*/
public Object resolveVariable(String varName) {
int index;
if (this.getMap() != null && (index = varName.indexOf(",")) != -1) {
return MessageFormat.format("{0" + varName.substring(index)
+ "}", new Object[] { this.getMap().get(
varName.substring(0, index)) });
} else {
return super.resolveVariable(varName);
}
}
}
/**
* Creates a new instance with defaults for variable prefix and suffix and the escaping character.
*/
public VariableFormatterWithFormating() {
this((VariableResolver) null, DEFAULT_PREFIX, DEFAULT_SUFFIX, DEFAULT_ESCAPE);
}
/**
* Creates a new instance and initializes it. Uses defaults for variable prefix and suffix and the escaping
* character.
*
* @param valueMap
*the map with the variables' values
*/
public VariableFormatterWithFormating(Map valueMap) {
this(valueMap, DEFAULT_PREFIX, DEFAULT_SUFFIX, DEFAULT_ESCAPE);
}
/**
* Creates a new instance and initializes it. Uses a default escaping character.
*
* @param valueMap
*the map with the variables' values
* @param prefix
*the prefix for variables
* @param suffix
*the suffix for variables
*/
public VariableFormatterWithFormating(Map valueMap, String prefix, String suffix) {
this(valueMap, prefix, suffix, DEFAULT_ESCAPE);
}
/**
* Creates a new instance and initializes it.
*
* @param valueMap
*the map with the variables' values
* @param prefix
*the prefix for variables
* @param suffix
*the suffix for variables
* @param escape
*the escape character
*/
public VariableFormatterWithFormating(Map valueMap, String prefix, String suffix, char escape) {
this(new MapVariableResolverWithFormats(valueMap), prefix, suffix, escape);
}
/**
* Creates a new instance and initializes it.
*
* @param variableResolver
*the variable resolver
* @param prefix
*the prefix for variables
* @param suffix
*the suffix for variables
* @param escape
*the escape character
*/
public VariableFormatterWithFormating(VariableResolver variableResolver, String prefix, String suffix, char escape) {
super(variableResolver,prefix,suffix,escape);
}
/**
* Replaces the occurrences of all variables in the given source data by their current values obtained from the
* passed in map.
*
* @param valueMap
*the map with the values
* @param source
*the source text
* @return the result of the replace operation
*/
public static String replace(Map valueMap, Object source) {
return new VariableFormatter(valueMap).replace(source);
}
/**
* Replaces the occurrences of all variables in th
Re: [lang] Questions concerning VariableFormatter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Gregory wrote: > In a day or so, a new version will be in SVN, and I should be able to > chat about this other feature. Thanks for your patience. > > Gary Hi, I saw that a new version of VariableFormatter is in SVN. What I've done now is to subclass it. Do you have time to chat about it? Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFDAb55kVPeOFLgZFIRAvEFAJ9mpPdYRXipADcE5sKgV29jtUEZTwCeNIeJ 6KbSURSEaFqLvK16og1+hGg= =eHcW -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Questions concerning VariableFormatter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Gregory schrieb: > Hi Tom: > > I'm in the middle of work and integrating a rework from Oliver on free > time, so I cannot look at this at the moment. I'll try to peek tonight. > > Cheers, > Gary > > [...] no problem I simply need some pointers how I should go on to get into VariableFormatter what I think would make it useable as a real replacement for MessageFormat. Thanks Tom > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+N1FkVPeOFLgZFIRAigSAJ4g1lzB+X7srfdrosYmeuXb0hFvcQCfaeOw sbEKMN2pEn3EXAqdFq08W8k= =Kib9 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Questions concerning VariableFormatter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Gregory schrieb: > Hello: [...] > Simon's full message is here: > http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg63493.html > > Gary > Ok. Thanks for clearing up this so what's with the proposed formating of substiution values. Is the way I tried it now acceptable? If not could anybody tell me how a patch to VariableFormatter should look like to be acceptable? Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+NEakVPeOFLgZFIRAmanAKCcs/7eGl/B0FzB40i+Cl0Q3yVFAwCgmSiG Y8kiQUjvKWEyUwpfYnfdKSE= =j3kd -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Questions concerning VariableFormatter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Oliver Heger schrieb:
> Tom Schindl wrote:
>
>> Stephen Colebourne schrieb:
>>
>> >Please prefix emails by [lang]
>
[...]
> An alternative would be to provide an additional implementation of the
> VariableResolver interface. The default implementation stays as is and
> does not handle formats. An extended implementation could support
> further arguments that are appended to variables.
>
> Oliver
so i did now and added a new resolver based upon the existing one. What
this patch does:
- - added a new Resolver named MapVariableResolverWithFormats
- - static functions to turn Formats on/off
=> default methods changed to use Formats
- - new constructors
Hope that's better than my first try. I didn't have a enough time to
look closer at how to make VariableFormatter extend Format which I'd
desire most so that the interface between MessageFormat and
VariableFormatter is equal.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC+I+YkVPeOFLgZFIRAlszAJsGCQ7fdUnKtsho4rEvxliptJMQTACeKv1d
U1wwIvsx++Bw6Rn65CD7yCg=
=5lYH
-END PGP SIGNATURE-
Index:
E:/eclipse-workspaces/beso-internal-devel/jakarta-lang/src/java/org/apache/commons/lang/text/VariableFormatter.java
===
---
E:/eclipse-workspaces/beso-internal-devel/jakarta-lang/src/java/org/apache/commons/lang/text/VariableFormatter.java
(revision 231018)
+++
E:/eclipse-workspaces/beso-internal-devel/jakarta-lang/src/java/org/apache/commons/lang/text/VariableFormatter.java
(working copy)
@@ -16,6 +16,7 @@
package org.apache.commons.lang.text;
+import java.text.MessageFormat;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
@@ -175,6 +176,48 @@
Object resolveVariable(String varName);
}
+/**
+ *
+ * A VariableResolver backed by a [EMAIL PROTECTED] Map} who uses Formats
like MessageFormat does
+ *
+ * @author mailto:[EMAIL PROTECTED]">Tom Schindl
+ * @version $Id$
+ */
+public static class MapVariableResolverWithFormats extends
MapVariableResolver {
+
+ /**
+* Creates a new variable resolver to handle formats like
+* [EMAIL PROTECTED] MessageFormat} does it. You can use e.g.
{today,date,short} to
+* format the variable today as a short date
+*
+* @param map
+*The variable names and values.
+*/
+ public MapVariableResolverWithFormats(Map map) {
+ super(map);
+ }
+
+ /**
+* Resolves the variable and formats the object retrieved using
+* [EMAIL PROTECTED] MessageFormat}
+*
+* @param varName
+*name of the variable and optionally the data-type and
+*data-format seperated by comma
+*/
+ public Object resolveVariable(String varName) {
+ int index;
+
+ if (this.getMap() != null && (index = varName.indexOf(",")) !=
-1) {
+ return MessageFormat.format("{0" +
varName.substring(index)
+ + "}", new Object[] { this.getMap().get(
+ varName.substring(0,
index)) });
+ } else {
+ return super.resolveVariable(varName);
+ }
+ }
+}
+
/** Constant for the default escape character. */
static final char DEFAULT_ESCAPE = '$';
@@ -185,37 +228,95 @@
static final String DEFAULT_SUFFIX = "}";
/**
- * Replaces the occurrences of all variables in the given source data by
their current values obtained from the
- * passed in map.
- *
- * @param valueMap
- *the map with the values
- * @param source
- *the source text
- * @return the result of the replace operation
- */
-public static String replace(Map valueMap, Object source) {
-return new VariableFormatter(valueMap).replace(source);
-}
+* Replaces the occurrences of all variables in the given source data by
+* their current values obtained from the passed in map. Formats are
applied
+* automatically if you have defined them in your variable definition.
+*
+* @param valueMap
+*the map with the values
+* @param source
+*the source text
+* @return the result of the replace operation
+*/
+
Re: [lang] Questions concerning VariableFormatter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephen Colebourne schrieb:
> Please prefix emails by [lang]
>
> Tom Schindl wrote:
>
>> I just found out that this project has exactly what I was searching
>> for long time because MessageFormat doesn't really suite my needs.
>>
>> I see that this Class has been added in 2.2:
>>
>> a. Is there any plan when 2.2 is released
>
> When its ready ;-) No firm dates, but work rate is pretty high at present.
>
>> b. What would be with adding formats applied to values like
>> MessageFormat does it {myDate,date,short}. The attached patch does
>> that simply using MessageFormat.
>
> I agree that this is a good idea if done carefully. However we have no
> plans to do this at present. You might want to propose some
> suggestions/code separately.
Isn't the proposed patch appended to the last mail what could be done to
stay as compatible with MessageFormat as possible?
Maybe a flag to VariableFormatter could flag whether a search for
formats should be done so users not using formats are not hurt by the
search.
>
>> c. Are there any planned changes to VariableFormatter to make it more
>> look like MessageFormat?
>
> Not at present, although its my personal opinion that it should extend
> Format before 2.2 release. You could help code this.
I'll investigate on this.
>
> Stephen
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC8enEkVPeOFLgZFIRApONAJ448NB1ptbeKCPySkIMkWBjMAE+3gCfXkWv
KW4U6CHnKZIkUIBMV2hefcs=
=/ryH
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Questions concerning VariableFormatter
Hi,
I just found out that this project has exactly what I was searching for
long time because MessageFormat doesn't really suite my needs.
I see that this Class has been added in 2.2:
a. Is there any plan when 2.2 is released
b. What would be with adding formats applied to values like
MessageFormat does it {myDate,date,short}. The attached patch does that
simply using MessageFormat.
c. Are there any planned changes to VariableFormatter to make it more
look like MessageFormat?
Thanks
Tom
Index:
E:/eclipse-workspaces/beso-internal-devel/jakarta-lang/src/java/org/apache/commons/lang/text/VariableFormatter.java
===
---
E:/eclipse-workspaces/beso-internal-devel/jakarta-lang/src/java/org/apache/commons/lang/text/VariableFormatter.java
(revision 226795)
+++
E:/eclipse-workspaces/beso-internal-devel/jakarta-lang/src/java/org/apache/commons/lang/text/VariableFormatter.java
(working copy)
@@ -16,6 +16,7 @@
package org.apache.commons.lang.text;
+import java.text.MessageFormat;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
@@ -139,7 +140,14 @@
if (this.getMap() == null) {
return null;
}
-return this.getMap().get(varName);
+
+int index;
+
+if( (index = varName.indexOf(",")) != -1 ) {
+ return
MessageFormat.format("{0"+varName.substring(index)+"}",new Object[] {
this.getMap().get(varName.substring(0,index)) } );
+} else {
+ return this.getMap().get(varName);
+}
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
