You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2006/07/06 02:07:04 UTC
[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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] VariableFormatter - pre 2.2
Posted by Tom Schindl <li...@bestsolution.at>.
Henri Yandell schrieb:
> This is all that's left in 2.2 before an RC can be built.
>
> On 7/5/06, Stephen Colebourne <sc...@btopenworld.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] VariableFormatter - pre 2.2
Posted by Stephen Colebourne <sc...@joda.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] VariableFormatter - pre 2.2
Posted by Henri Yandell <fl...@gmail.com>.
On 7/21/06, Oliver Heger <ol...@oliver-heger.de> 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 <sc...@btopenworld.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] VariableFormatter - pre 2.2
Posted by Oliver Heger <ol...@oliver-heger.de>.
Henri Yandell wrote:
> This is all that's left in 2.2 before an RC can be built.
>
> On 7/5/06, Stephen Colebourne <sc...@btopenworld.com> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [lang] VariableFormatter - pre 2.2
Posted by Gary Gregory <gg...@seagullsoftware.com>.
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:flamefew@gmail.com]
> 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 <sc...@btopenworld.com> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] VariableFormatter - pre 2.2
Posted by Henri Yandell <fl...@gmail.com>.
This is all that's left in 2.2 before an RC can be built.
On 7/5/06, Stephen Colebourne <sc...@btopenworld.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [lang] JRE level?
Posted by Gary Gregory <gg...@seagullsoftware.com>.
I have the Eclipse project that the code lives in on my machine setup
with Java 1.3.1. In Eclipse, you can set a different JRE for each
project or have a project inherit the JRE from the containing workspace.
Gary
> -----Original Message-----
> From: Henri Yandell [mailto:flamefew@gmail.com]
> Sent: Friday, July 07, 2006 9:43 AM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] JRE level?
>
> Grumble, grumble, Maven -> 1.4+, grumble, grumble, OS X -> no 1.2.x,
> grumble, grumble, grumble.
>
> How did you catch this by the way Gary?
>
> Hen
>
> On 7/6/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > [lang] should be JDK1.2 compliant, although I tend to think of it as
> > 1.3+ with 1.2 at users risk.
> >
> > Stephen
> >
> > Gary Gregory wrote:
> > > Hello All:
> > >
> > > Based on the project.properties file entry:
> > >
> > > maven.compile.source = 1.3
> > >
> > > I assume that we are making Java 1.3 the requirement.
> > >
> > > We therefore should not have Java 1.4 dependencies:
> > >
> > > Severity and Description Path Resource Location
> > > Creation Time Id
> > > The method getCause() is undefined for the type Throwable
Apache
> > > Jakarta Commons
> > > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > > ExceptionUtilsTestCase.java line 135 1151797976890
13807342
> > > The method getCause() is undefined for the type Throwable
Apache
> > > Jakarta Commons
> > > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > > ExceptionUtilsTestCase.java line 136 1151797976890
13807346
> > > The method getCause() is undefined for the type Throwable
Apache
> > > Jakarta Commons
> > > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > > ExceptionUtilsTestCase.java line 169 1151797976890
13807374
> > > The method getCause() is undefined for the type Throwable
Apache
> > > Jakarta Commons
> > > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > > ExceptionUtilsTestCase.java line 269 1151797976890
13807406
> > > The method getCause() is undefined for the type Throwable
Apache
> > > Jakarta Commons
> > > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > > ExceptionUtilsTestCase.java line 316 1151797976890
13807407
> > >
> > > Or am I missing something?
> > >
> > > Thanks,
> > > Gary
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
commons-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] JRE level?
Posted by Henri Yandell <fl...@gmail.com>.
Grumble, grumble, Maven -> 1.4+, grumble, grumble, OS X -> no 1.2.x,
grumble, grumble, grumble.
How did you catch this by the way Gary?
Hen
On 7/6/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> [lang] should be JDK1.2 compliant, although I tend to think of it as
> 1.3+ with 1.2 at users risk.
>
> Stephen
>
> Gary Gregory wrote:
> > Hello All:
> >
> > Based on the project.properties file entry:
> >
> > maven.compile.source = 1.3
> >
> > I assume that we are making Java 1.3 the requirement.
> >
> > We therefore should not have Java 1.4 dependencies:
> >
> > Severity and Description Path Resource Location
> > Creation Time Id
> > The method getCause() is undefined for the type Throwable Apache
> > Jakarta Commons
> > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > ExceptionUtilsTestCase.java line 135 1151797976890 13807342
> > The method getCause() is undefined for the type Throwable Apache
> > Jakarta Commons
> > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > ExceptionUtilsTestCase.java line 136 1151797976890 13807346
> > The method getCause() is undefined for the type Throwable Apache
> > Jakarta Commons
> > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > ExceptionUtilsTestCase.java line 169 1151797976890 13807374
> > The method getCause() is undefined for the type Throwable Apache
> > Jakarta Commons
> > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > ExceptionUtilsTestCase.java line 269 1151797976890 13807406
> > The method getCause() is undefined for the type Throwable Apache
> > Jakarta Commons
> > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > ExceptionUtilsTestCase.java line 316 1151797976890 13807407
> >
> > Or am I missing something?
> >
> > Thanks,
> > Gary
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] JRE level?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
[lang] should be JDK1.2 compliant, although I tend to think of it as
1.3+ with 1.2 at users risk.
Stephen
Gary Gregory wrote:
> Hello All:
>
> Based on the project.properties file entry:
>
> maven.compile.source = 1.3
>
> I assume that we are making Java 1.3 the requirement.
>
> We therefore should not have Java 1.4 dependencies:
>
> Severity and Description Path Resource Location
> Creation Time Id
> The method getCause() is undefined for the type Throwable Apache
> Jakarta Commons
> trunks-proper/lang/src/test/org/apache/commons/lang/exception
> ExceptionUtilsTestCase.java line 135 1151797976890 13807342
> The method getCause() is undefined for the type Throwable Apache
> Jakarta Commons
> trunks-proper/lang/src/test/org/apache/commons/lang/exception
> ExceptionUtilsTestCase.java line 136 1151797976890 13807346
> The method getCause() is undefined for the type Throwable Apache
> Jakarta Commons
> trunks-proper/lang/src/test/org/apache/commons/lang/exception
> ExceptionUtilsTestCase.java line 169 1151797976890 13807374
> The method getCause() is undefined for the type Throwable Apache
> Jakarta Commons
> trunks-proper/lang/src/test/org/apache/commons/lang/exception
> ExceptionUtilsTestCase.java line 269 1151797976890 13807406
> The method getCause() is undefined for the type Throwable Apache
> Jakarta Commons
> trunks-proper/lang/src/test/org/apache/commons/lang/exception
> ExceptionUtilsTestCase.java line 316 1151797976890 13807407
>
> Or am I missing something?
>
> Thanks,
> Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[lang] JRE level?
Posted by Gary Gregory <gg...@seagullsoftware.com>.
Hello All:
Based on the project.properties file entry:
maven.compile.source = 1.3
I assume that we are making Java 1.3 the requirement.
We therefore should not have Java 1.4 dependencies:
Severity and Description Path Resource Location
Creation Time Id
The method getCause() is undefined for the type Throwable Apache
Jakarta Commons
trunks-proper/lang/src/test/org/apache/commons/lang/exception
ExceptionUtilsTestCase.java line 135 1151797976890 13807342
The method getCause() is undefined for the type Throwable Apache
Jakarta Commons
trunks-proper/lang/src/test/org/apache/commons/lang/exception
ExceptionUtilsTestCase.java line 136 1151797976890 13807346
The method getCause() is undefined for the type Throwable Apache
Jakarta Commons
trunks-proper/lang/src/test/org/apache/commons/lang/exception
ExceptionUtilsTestCase.java line 169 1151797976890 13807374
The method getCause() is undefined for the type Throwable Apache
Jakarta Commons
trunks-proper/lang/src/test/org/apache/commons/lang/exception
ExceptionUtilsTestCase.java line 269 1151797976890 13807406
The method getCause() is undefined for the type Throwable Apache
Jakarta Commons
trunks-proper/lang/src/test/org/apache/commons/lang/exception
ExceptionUtilsTestCase.java line 316 1151797976890 13807407
Or am I missing something?
Thanks,
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] VariableFormatter - pre 2.2
Posted by Oliver Heger <ol...@oliver-heger.de>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] VariableFormatter - pre 2.2
Posted by Henri Yandell <fl...@gmail.com>.
On 7/7/06, Oliver Heger <ol...@oliver-heger.de> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] VariableFormatter - pre 2.2
Posted by Oliver Heger <ol...@oliver-heger.de>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] VariableFormatter - pre 2.2
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [lang] VariableFormatter - pre 2.2
Posted by Gary Gregory <gg...@seagullsoftware.com>.
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:scolebourne@btopenworld.com]
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org