Hello All:
At a minimum, I'd like to see MapVariableResolver packge scoped.
Looking at the message thread:
@
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
Message
From: Stephen Colebourne [mailto:scolebourne (AT) btopenworld (DOT) 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 IMH 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 GNL, 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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

Gary Gregory wrote:
>>At a minimum, I'd like to see MapVariableResolver packge scoped.

Looking at the message thread:
@
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.

Heger wrote:
Fine with me, but could the return value of lookup be 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 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 () method which appears
to have very odd semantics as you can't rely on the return value being
of any specific type. What are you expecting to work with?

Stephen

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

Stephen Colebourne wrote:
<snip/>

Heger wrote:
Fine with me, but could the return value of lookup be 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 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 () method which appears
to have very odd semantics as you can't rely on the return value being
of any specific type. What 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.

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

7/7/06, Heger <oliver.heger (AT) oliver-heger (DOT) dewrote:
Stephen Colebourne wrote:
<snip/>
--
Heger wrote:
Fine with me, but could the return value of lookup be 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 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 () method which appears
to have very odd semantics as you can't rely on the return value being
of any specific type. What 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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org