${sessionScope.configAttribute["foo.bar"]} and ${sessionScope.configAttribute.foo.bar}
can both be resolved. To actually make this possible, one also needs to provide a hierarchical context to the configuration such that the following is possible.
Configuration config = session.getAttribute("configAttribute");
Collection subcontext = (Collection)config.get("foo");
Object value = subcontext.get("bar");This doesn't mean you can't still do:
Configuration config = ...;
double d = config.getDouble("foo.bar");Its just facilitated differently in the Collection methods where a simple recursive parse/search algorithm would be required.
I'll provide a patch for this so you have an example...
Mark R. Diggory wrote:
Hmm, I'm not sure your getting me, I'm refering to making the Configuration interface a proper Map via an extension of the Collection API's Map Interface and requiring all implementations to support that interface (Which could be facilitated through Abstraction/Polymorphism) with little impact to the existing usage.
http://jakarta.apache.org/commons/configuration/apidocs/org/apache/commons/configuration/Configuration.html
-Mark
Brent Verner wrote:
[2004-05-18 09:20] Mark R. Diggory said:
| Brent Verner wrote:
| | >[2004-05-18 08:43] Mark R. Diggory said:
| >| To extend the subject of refactoring. I want to be able to access | >| Configuration objects from EL references in JSP 2.0.
| >| | >| ${sessionScope.config.foo.bar}
| >
| >I do something similar _with_ properties configuration. The syntax
| >I use is
| > | > ${sessionScope.config['some.config.key']}
| >
| >after doing
| >
| > session.setAttribute("config",someMap);
| >
| >I'm not sure it is worth the effort to work around the "['...']"
| >syntax requirement/limitation, since the key/value configuration
| >would have to be copied into something that EL can address
| >directly (most simply a Map of Map [[of Map ] ...])
| >
| >cheers.
| > brent
| >
| | Yes, but maintaining a generic Map interface on the objects in the | configuration hierarchy would probably be very beneficial anywhere that | this similar approach of automation/reflection occurs. Would it not? It | probably would make for a simple backwards compatible refactoring.
Yeah, that makes sense. Here goes a sample impl. that looks like it'd do what you want.
cheers b
import java.util.Map; import java.util.HashMap; import java.util.Iterator; import java.util.StringTokenizer;
public class x {
public void insert(Map m, String key, String value){
// XXX: will not account for non-separator '.' such as a key that looks like "some.key.adn[something.that.ya.don't.want.nested].whatever.else"
Map rv = null;
int dp = key.indexOf(".");
String rest = null;
String first = key;
if( dp > 0 ){
first = key.substring(0,dp);
rest = key.substring(dp + 1);
}
rv = (Map)m.get(first);
if( rv == null ){
rv = new HashMap();
m.put(first,rv);
}
if( rest != null ){
insert(rv,rest,value);
}
else{
rv.put(first,value);
}
}
public Map blowItOut(Map m){
Map rv = new HashMap();
for( Iterator it = m.keySet().iterator(); it.hasNext(); ){
String k = (String)it.next();
String v = (String)m.get(k);
insert(rv,k,v);
}
return rv;
}
public void go(){ Map x = new HashMap(); Map top = null; x.put("a.b.c.d","abcd"); x.put("e.f.g","efgh"); x.put("h.i.j.k.l.m.n.o.p","hijklmnop"); x.put("q.r.s","qrs"); x.put("t.u.v","tuv"); x.put("w.x.y.and.z","wxyandz"); top = blowItOut(x); System.out.println(x); System.out.println(top); } public static void main(String[] args) throws Exception { x y = new x(); y.go(); } }
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
