[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [configuration] Accessing from EL script
From:       "Mark R. Diggory" <mdiggory () latte ! harvard ! edu>
Date:       2004-05-19 16:17:16
Message-ID: 40AB888C.4010206 () latte ! harvard ! edu
[Download RAW message or body]

Emmanuel Bourg wrote:

> Mark R. Diggory wrote:
>
>> For instance, storing :
>>
>> config.add("a.b", z);
>> config.add("a.b.c", y);
>> config.add("a.b.c.d.e", x);
>> config.add("a.b.c.d.e.f", w);
>>
>> ${sessionScope.configAttribute.a.b} --> z
>> ${sessionScope.configAttribute.a.b.c} --> y
>> ${sessionScope.configAttribute.a.b.c.d.e} --> x
>> ${sessionScope.configAttribute.a.b.c.d.e.f} --> w
>>
>> but
>>
>> ${sessionScope.configAttribute.a.b.c.d}
>>    --> Map containing {"e",x; Map [x[ { "f",w } }
>
>
> I'm not sure it works, if I understand well, the following EL:
>
> ${config.a.b.c}
>
> translates into (through reflexion):
>
> config.get("a").get("b").get("c");
>
> but what is supposed to return the get("b") part ? the value of "a.b" 
> that's "z" or the subset under "a.b" containing the "c", "c.d.e" and 
> "c.d.e.f" elements ?
>
> Emmanuel Bourg


Hmm, I get your point. That is a limiting factor, heres a possible solution:

In my example, we have the case that config.get("a") returns a nested 
structure of key --> Map pairs.
   
Map{
       "b",  Map {
                 "c", Map {
                             "d", Map {
                                        "e", Map {
                                                     "f", value
                                                       }
                                              }
                                  }
                         }
             }

so that you can do:

config.get("a").get("b").get("c");

however, how do we get the object value for the case of "a.b.c" as 
opposed to the collection of its children. I suspect the answer is 
similar to that of "DOM" where an Element node has both Attributes and 
Children. So, a Map in this case has both a coercable Default Value 
(toString()) and Children.

[..] conotates "default value"

Map a = config.get("a");

    Map {
       "b",  Map [z] {                                            -----> 
a.get("b").toString() = z
                 "c", Map [y] {                                   -----> 
a.get("b").get("c").toString() = y
                             "d", Map [NULL] {              -----> 
a.get("b").get("c").get("d").toString() = null
                                        "e", Map [x]{             -----> 
a.get("b").get("c").get("d").get("e").toString() = x
                                                     "f", w             
----> a.get("b").get("c").get("d").get("e").get("f").toString()  = w
                                                       }
                                              }
                                  }
                         }
             }

Unfortunately, JSTL's EL coercion isn't what I expected. I would expect 
Objects to be coerced to Strings using "toString()", then have the 
String coerced to Boolean, Number, char, etc... But Objects coerced to 
anything but string result in a coersion error. Which means that the 
results could never be used for EL arithmetic. That is something that 
could be taken up with the JSTL/EL folks though.

So for limited functionality, when a Map object is returned, it could be 
coerced to a String value using its "toString()" method at least for now.
 
So

${sessionScope.configAttribute.a.b} --> z
${sessionScope.configAttribute.a.b.c} --> y
${sessionScope.configAttribute.a.b.c.d.e} --> x
${sessionScope.configAttribute.a.b.c.d.e.f} --> w

but when ".b.c.d" is coerced

${sessionScope.configAttribute.a.b.c.d} --> null

as opposed to iterated over using JSTL which would be

${sessionScope.configAttribute.a.b.c.d}
   --> Map [NULL] {
            "e",x; Map [x] {
                          "f",w }
        }

-Mark




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]