Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #13050 > unrolled thread

JSTL: getting a map's keys

Back to article view | Back to comp.lang.java.programmer

Contents

  JSTL: getting a map's keys Chris Riesbeck <Chris.Riesbeck@gmail.com> - 2012-03-19 13:15 -0500
    Re: JSTL: getting a map's keys Lew <lewbloch@gmail.com> - 2012-03-19 12:57 -0700
    Re: JSTL: getting a map's keys Tim Slattery <Slattery_T@bls.gov> - 2012-03-19 16:08 -0400
      Re: JSTL: getting a map's keys Chris Riesbeck <Chris.Riesbeck@gmail.com> - 2012-03-19 16:06 -0500
        Re: JSTL: getting a map's keys Chris Riesbeck <Chris.Riesbeck@gmail.com> - 2012-03-19 16:39 -0500
      Re: JSTL: getting a map's keys markspace <-@.> - 2012-03-19 15:27 -0700
    Re: JSTL: getting a map's keys Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-03-19 16:59 -0700
      Re: JSTL: getting a map's keys Chris Riesbeck <Chris.Riesbeck@gmail.com> - 2012-03-20 12:19 -0500
        Re: JSTL: getting a map's keys Chris Riesbeck <Chris.Riesbeck@gmail.com> - 2012-03-20 12:52 -0500
          Re: JSTL: getting a map's keys Lew <lewbloch@gmail.com> - 2012-03-20 11:05 -0700
            Re: JSTL: getting a map's keys Chris Riesbeck <Chris.Riesbeck@gmail.com> - 2012-03-21 13:09 -0500
              Re: JSTL: getting a map's keys Lew <noone@lewscanon.com> - 2012-03-22 07:51 -0700
                Re: JSTL: getting a map's keys Chris Riesbeck <Chris.Riesbeck@gmail.com> - 2012-03-22 12:53 -0500
                  Re: JSTL: getting a map's keys Lew <lewbloch@gmail.com> - 2012-03-22 13:23 -0700
                    Re: JSTL: getting a map's keys Chris Riesbeck <Chris.Riesbeck@gmail.com> - 2012-03-23 12:23 -0500
                      Re: JSTL: getting a map's keys Lew <noone@lewscanon.com> - 2012-03-23 13:50 -0700
                        Re: JSTL: getting a map's keys Chris Riesbeck <Chris.Riesbeck@gmail.com> - 2012-03-26 14:10 -0500
          Re: JSTL: getting a map's keys Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-03-20 11:28 -0700
          Re: JSTL: getting a map's keys markspace <-@.> - 2012-03-20 11:29 -0700
            Re: JSTL: getting a map's keys Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-03-20 12:10 -0700

#13050 — JSTL: getting a map's keys

Can anyone help me figure out why the following is happening, or further 
experiments I can run? (I have workarounds but I'd like to know what I'm 
misunderstanding.)

Given:
   - SimTable, a subclass of HashTable that defines getKeys() to call 
keyset()
   - a session variable "data" which is a HashTable with "rates" set to 
an instance of a SimTable

Why does ${rates.keys} generate nothing in these lines of JSP?

   <c:set var="rates" value='${data["rates"]}'/>

   <p>rates: ${rates}</p>

   <p>jstl: ${rates.keys}</p>

   <p>jsp: <%= ((edu.northwestern.ils.simulator.SimTable) 
pageContext.findAttribute("rates")).getKeys() %></p>

Here's the generated HTML output:

   <p>rates: {Bill=100.0, Fred=75.0, Jane=75.0, Mary=50.0, Sam=75.0, 
Sarah=150.0}</p>

   <p>jstl: </p>

   <p>jsp: [Bill, Fred, Jane, Mary, Sam, Sarah]</p>

[toc] | [next] | [standalone]

#13054

On Monday, March 19, 2012 11:15:52 AM UTC-7, Chris Riesbeck wrote:
> Can anyone help me figure out why the following is happening, or further 
> experiments I can run? (I have workarounds but I'd like to know what I'm 
> misunderstanding.)
> 
> Given:
>    - SimTable, a subclass of HashTable [sic] that defines getKeys() to call 

If you mean 'java.util.Hashtable', that's a rather obsolete class. You should stick with 'java.util.HashMap'.

> keyset()

Joshua Bloch recommends to prefer composition over inheritance.

>    - a session variable "data" which is a HashTable with "rates" set to 
> an instance of a SimTable

If "rates" is set to an instance of a 'HashTable', or whatever, is 'data' then a 'Map<String,Map<?,?>>'?

> Why does ${rates.keys} generate nothing in these lines of JSP?

How about you follow the advice here:
http://sscce.org/
and then maybe we can help you. It would make it easier for you to answer the questions I'm asking.

I think perhaps you're overthinking the session vars. Why can't your 'rates' Map go in there directly?

>    <c:set var="rates" value='${data["rates"]}'/>
> 
>    
> rates: ${rates}</p>
> 
>    
> jstl: ${rates.keys}</p>
> 
>    
> jsp: <%= ((edu.northwestern.ils.simulator.SimTable) 
> pageContext.findAttribute("rates")).getKeys() %></p>
> 
> Here's the generated HTML output:
> 
>    
> rates: {Bill=100.0, Fred=75.0, Jane=75.0, Mary=50.0, Sam=75.0, 
> Sarah=150.0}</p>
> 
>    
> jstl: </p>
> 
>    
> jsp: [Bill, Fred, Jane, Mary, Sam, Sarah]</p>

Your example code is fragmented and incomplete. Give us something we can work with, please.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#13056

Chris Riesbeck <Chris.Riesbeck@gmail.com> wrote:


>   <p>jstl: ${rates.keys}</p>

The EL here finds the object "rates" and looks for an attribute named
"keys". That means that if rates doesn't have a public method named
getKeys, the EL won't find anything.

-- 
Tim Slattery
Slattery_T@bls.gov

[toc] | [prev] | [next] | [standalone]

#13059

On 3/19/2012 3:08 PM, Tim Slattery wrote:
> Chris Riesbeck<Chris.Riesbeck@gmail.com>  wrote:
>
>
>>    <p>jstl: ${rates.keys}</p>
>
> The EL here finds the object "rates" and looks for an attribute named
> "keys". That means that if rates doesn't have a public method named
> getKeys, the EL won't find anything.
>
Which it does. Here's a complete example, class and test JSP, and the 
HTML output I get

****** CLASS

package example;

import java.util.HashMap;
import java.util.Set;

public class SimTable extends HashMap<String, Object> {

   public Set<String> getKeys() {
     return keySet();
   }
}

****** JSP

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

<%
   final example.SimTable data = new example.SimTable();
   data.put("Bill", 100);  data.put("Mary", 150);  data.put("Fred", 200);
   pageContext.setAttribute("data", data);
   %>

<!doctype HTML>
<html>
<head>
<title>Test</title>
</head>
<body>
<p>data: ${data}</p>
<p>data.keys: ${data.keys}</p>
<p>data.getKeys():
   <%= ((example.SimTable) pageContext.findAttribute("data")).getKeys() %>
</p>
</body>
</html>


****** HTML output

<!doctype HTML>
<html>
<head>
<title>Test</title>
</head>
<body>
<p>data: {Bill=100, Mary=150, Fred=200}</p>
<p>data.keys: </p>
<p>data.getKeys():
   [Bill, Mary, Fred]
</p>

</body>
</html>

[toc] | [prev] | [next] | [standalone]

#13060

On 3/19/2012 4:06 PM, Chris Riesbeck wrote:
> On 3/19/2012 3:08 PM, Tim Slattery wrote:
>> Chris Riesbeck<Chris.Riesbeck@gmail.com> wrote:
>>
>>
>>> <p>jstl: ${rates.keys}</p>
>>
>> The EL here finds the object "rates" and looks for an attribute named
>> "keys". That means that if rates doesn't have a public method named
>> getKeys, the EL won't find anything.
>>
> Which it does. Here's a complete example, class and test JSP, and the
> HTML output I get
>
> ****** CLASS
>
> package example;
>
> import java.util.HashMap;
> import java.util.Set;
>
> public class SimTable extends HashMap<String, Object> {
>
> public Set<String> getKeys() {
> return keySet();
> }
> }
>
> ****** JSP
>
> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
>
> <%
> final example.SimTable data = new example.SimTable();
> data.put("Bill", 100); data.put("Mary", 150); data.put("Fred", 200);
> pageContext.setAttribute("data", data);
> %>
>
> <!doctype HTML>
> <html>
> <head>
> <title>Test</title>
> </head>
> <body>
> <p>data: ${data}</p>
> <p>data.keys: ${data.keys}</p>
> <p>data.getKeys():
> <%= ((example.SimTable) pageContext.findAttribute("data")).getKeys() %>
> </p>
> </body>
> </html>
>
>
> ****** HTML output
>
> <!doctype HTML>
> <html>
> <head>
> <title>Test</title>
> </head>
> <body>
> <p>data: {Bill=100, Mary=150, Fred=200}</p>
> <p>data.keys: </p>
> <p>data.getKeys():
> [Bill, Mary, Fred]
> </p>
>
> </body>
> </html>

And I added these lines to my JSP to see if "keys" was appearing as a 
property via the Introspector and it was

****** additional JSP

<c:set var="props"
   value='<%= 
java.beans.Introspector.getBeanInfo(pageContext.findAttribute("data").getClass()).getPropertyDescriptors() 
%>' />
<ul>
   <c:forEach var="prop" items="${props}">
     <li>${prop.name}</li>
   </c:forEach>
</ul>

****** additional HTML output

<ul>

     <li>class</li>

     <li>empty</li>

     <li>keys</li>

</ul>

[toc] | [prev] | [next] | [standalone]

#13061

On 3/19/2012 1:08 PM, Tim Slattery wrote:
> Chris Riesbeck<Chris.Riesbeck@gmail.com>  wrote:
>
>
>>    <p>jstl: ${rates.keys}</p>
>
> The EL here finds the object "rates" and looks for an attribute named
> "keys". That means that if rates doesn't have a public method named
> getKeys, the EL won't find anything.
>


Up before the part you snipped, the OP mentioned that he did sub-class 
HashTable and add a "getKeys()" method.

Hmm, maybe there's a clue there.  Are there coercion rules for JSTL? 
It's been a long while since I looked at it.  Is it possible that JSTL 
is coercing SimTable (the one with getKeys()) to a HashTable, which does 
not have "getKeys()" defined?

You might want to uncompile the .class file for this JSTL, it might show 
you what is actually being produced.  There may be a clue there.

[toc] | [prev] | [next] | [standalone]

#13062

On 3/19/12 11:15 AM, Chris Riesbeck wrote:
> Can anyone help me figure out why the following is happening, or further
> experiments I can run? (I have workarounds but I'd like to know what I'm
> misunderstanding.)
>
> Given:
> - SimTable, a subclass of HashTable that defines getKeys() to call keyset()
> - a session variable "data" which is a HashTable with "rates" set to an
> instance of a SimTable
>
> Why does ${rates.keys} generate nothing in these lines of JSP?
>
> <c:set var="rates" value='${data["rates"]}'/>
>
> <p>rates: ${rates}</p>
>
> <p>jstl: ${rates.keys}</p>
>
> <p>jsp: <%= ((edu.northwestern.ils.simulator.SimTable)
> pageContext.findAttribute("rates")).getKeys() %></p>
>
> Here's the generated HTML output:
>
> <p>rates: {Bill=100.0, Fred=75.0, Jane=75.0, Mary=50.0, Sam=75.0,
> Sarah=150.0}</p>
>
> <p>jstl: </p>
>
> <p>jsp: [Bill, Fred, Jane, Mary, Sam, Sarah]</p>
>
My guess is that ${rates.keys} is interpreted as equivalent to 
${rates['keys']}, so it is looking for a key of "keys", not a java bean 
property.

You *can* use c:forEach to iterate over the entry set (Map.Entry) in a 
map.

Hopefully this helps,
Daniel.

[toc] | [prev] | [next] | [standalone]

#13080

On 3/19/2012 6:59 PM, Daniel Pitts wrote:
> On 3/19/12 11:15 AM, Chris Riesbeck wrote:
>> Can anyone help me figure out why the following is happening, or further
>> experiments I can run? (I have workarounds but I'd like to know what I'm
>> misunderstanding.)
>>
>> Given:
>> - SimTable, a subclass of HashTable that defines getKeys() to call
>> keyset()
>> - a session variable "data" which is a HashTable with "rates" set to an
>> instance of a SimTable
>>
>> Why does ${rates.keys} generate nothing in these lines of JSP?
>>
>> <c:set var="rates" value='${data["rates"]}'/>
>>
>> <p>rates: ${rates}</p>
>>
>> <p>jstl: ${rates.keys}</p>
>>
>> <p>jsp: <%= ((edu.northwestern.ils.simulator.SimTable)
>> pageContext.findAttribute("rates")).getKeys() %></p>
>>
>> Here's the generated HTML output:
>>
>> <p>rates: {Bill=100.0, Fred=75.0, Jane=75.0, Mary=50.0, Sam=75.0,
>> Sarah=150.0}</p>
>>
>> <p>jstl: </p>
>>
>> <p>jsp: [Bill, Fred, Jane, Mary, Sam, Sarah]</p>
>>
> My guess is that ${rates.keys} is interpreted as equivalent to
> ${rates['keys']}, so it is looking for a key of "keys", not a java bean
> property.

Ah! This would explain why ${rates.class} doesn't work either. 
Basically, name.key will always be taken as name[key] for a Map, even if 
key is a property of name. If I'm reading the JSP EL resolver 
specification correctly, that's just what is happening.

>
> You *can* use c:forEach to iterate over the entry set (Map.Entry) in a map.

Yes, that's what I've been doing instead for looping.

>
> Hopefully this helps,
> Daniel.

Indeed. Thanks, Daniel

[toc] | [prev] | [next] | [standalone]

#13082

On 3/20/2012 12:19 PM, Chris Riesbeck wrote:
> On 3/19/2012 6:59 PM, Daniel Pitts wrote:
>> On 3/19/12 11:15 AM, Chris Riesbeck wrote:
>>>
>>> [summary: rates is an instance of a subclass of Map that
 >>>  implements getKeys()]
>>>
>>> Why does ${rates.keys} generate nothing in these lines of JSP?
>>>
>> My guess is that ${rates.keys} is interpreted as equivalent to
>> ${rates['keys']}, so it is looking for a key of "keys", not a java bean
>> property.

Just to nail the coffin lid shut on this. The JSP EL defines name.key as 
just shorthand for name["key"]. To interpret [] expressions, JSP uses 
the first answer it gets from this chain of resolvers:

     ImplicitObjectELResolver
     registered custom ELResolvers
     MapELResolver
     ListELResolver
     ArrayELResolver
     BeanELResolver
     ScopedAttributeELResolver

 
http://docs.oracle.com/javaee/5/api/javax/servlet/jsp/JspApplicationContext.html

So the Map interpretation will always override the Bean interpretation.

[toc] | [prev] | [next] | [standalone]

#13083

Chris Riesbeck wrote:
> Chris Riesbeck wrote:
>> Daniel Pitts wrote:
>>> Chris Riesbeck wrote:
>>>>
>>>> [summary: rates is an instance of a subclass of Map that
>>>>  implements getKeys()]
>>>>
>>>> Why does ${rates.keys} generate nothing in these lines of JSP?
>>>>
>>> My guess is that ${rates.keys} is interpreted as equivalent to
>>> ${rates['keys']}, so it is looking for a key of "keys", not a java bean
>>> property.
> 
> Just to nail the coffin lid shut on this. The JSP EL defines name.key as 
> just shorthand for name["key"]. To interpret [] expressions, JSP uses 
> the first answer it gets from this chain of resolvers:
> 
>      ImplicitObjectELResolver
>      registered custom ELResolvers
>      MapELResolver
>      ListELResolver
>      ArrayELResolver
>      BeanELResolver
>      ScopedAttributeELResolver
> 
>  
> http://docs.oracle.com/javaee/5/api/javax/servlet/jsp/JspApplicationContext.html
> 
> So the Map interpretation will always override the Bean interpretation.

Now that your main question is answered, a couple of comments are in order.

- Don't have scriptlet in your JSPs.
- If you had *composed* a 'Map' into a custom class rather than inheriting 'Map', you would not have had the problem. Your custom class would have been resolved by the bean resolver.
- This in turn would make for a better design overall. Instead of your view artifact (the JSP) caring about the implementation details of the map and its set of keys, you'd have a controller call like 'getKeys()' or whatever that would cleanly separate the logic of how you get them from presentation concerns.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#13102

On 3/20/2012 1:05 PM, Lew wrote:
> Chris Riesbeck wrote:

>> http://docs.oracle.com/javaee/5/api/javax/servlet/jsp/JspApplicationContext.html
>>
>> So the Map interpretation will always override the Bean interpretation.
>
> Now that your main question is answered, a couple of comments are in order.
>
> - Don't have scriptlet in your JSPs.

I never do. That was in the original JSP just to show that getKeys() was 
functioning and returning a non-empty result

> - If you had *composed* a 'Map' into a custom class rather than
> inheriting 'Map', you would not have had the problem. Your custom
> class would have been resolved by the bean resolver. - This in turn
> would make for a better design overall. Instead of your view artifact
> (the JSP) caring about the implementation details of the map and its
> set of keys, you'd have a controller call like 'getKeys()' or
> whatever that would cleanly separate the logic of how you get them
> from presentation concerns.

Using delegation (my preference also) doesn't support the JSP EL form 
${rates["Bill"]}. If I had a custom class, I'd need a custom tag or 
custom EL resolver to make that work.

The original goal was to get the JSTL away from knowing about Map's, in 
particular about entry.key and entry.value.

[toc] | [prev] | [next] | [standalone]

#13122

Chris Riesbeck wrote:
> Lew wrote:
>> - If you had *composed* a 'Map' into a custom class rather than
>> inheriting 'Map', you would not have had the problem. Your custom
>> class would have been resolved by the bean resolver. - This in turn
>> would make for a better design overall. Instead of your view artifact
>> (the JSP) caring about the implementation details of the map and its
>> set of keys, you'd have a controller call like 'getKeys()' or
>> whatever that would cleanly separate the logic of how you get them
>> from presentation concerns.
>
> Using delegation (my preference also) doesn't support the JSP EL form
> ${rates["Bill"]}. If I had a custom class, I'd need a custom tag or custom EL
> resolver to make that work.

No, you most certainly would not.

Just define an appropriate method in your class.

> The original goal was to get the JSTL away from knowing about Map's [sic], in
> particular about entry.key and entry.value.

Which would be neatly accomplished by my suggestion.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#13123

On 3/22/2012 9:51 AM, Lew wrote:
> Chris Riesbeck wrote:
>> Lew wrote:
>>> - If you had *composed* a 'Map' into a custom class rather than
>>> inheriting 'Map', you would not have had the problem. Your custom
>>> class would have been resolved by the bean resolver. - This in turn
>>> would make for a better design overall. Instead of your view artifact
>>> (the JSP) caring about the implementation details of the map and its
>>> set of keys, you'd have a controller call like 'getKeys()' or
>>> whatever that would cleanly separate the logic of how you get them
>>> from presentation concerns.
>>
>> Using delegation (my preference also) doesn't support the JSP EL form
>> ${rates["Bill"]}. If I had a custom class, I'd need a custom tag or
>> custom EL
>> resolver to make that work.
>
> No, you most certainly would not.
>
> Just define an appropriate method in your class.

Color me totally dense. Maybe I'm missing what method I should be defining.

If my class implements the Map interface, then MAPElResolver will be 
invoked and do the same thing with name.key and name["key"]: call 
name.get("key"). The JSP EL won't be able to call any bean method of name.

If my class doesn't implement Map, then BeanELResolver will be invoked 
and do the same thing with name.key and name["key"]: call name.getKey(). 
The JSP EL won't be able to call name.get() via [].

So I don't see how I can have a class such that in the JSP EL I can call 
a method to get all the keys, and also retrieve data with a key using [].

[toc] | [prev] | [next] | [standalone]

#13125

Chris Riesbeck wrote:
> Lew wrote:
> > Chris Riesbeck wrote:
> >> Lew wrote:
> >>> - If you had *composed* a 'Map' into a custom class rather than
> >>> inheriting 'Map', you would not have had the problem. Your custom
> >>> class would have been resolved by the bean resolver. - This in turn
> >>> would make for a better design overall. Instead of your view artifact
> >>> (the JSP) caring about the implementation details of the map and its
> >>> set of keys, you'd have a controller call like 'getKeys()' or
> >>> whatever that would cleanly separate the logic of how you get them
> >>> from presentation concerns.
> >>
> >> Using delegation (my preference also) doesn't support the JSP EL form
> >> ${rates["Bill"]}. If I had a custom class, I'd need a custom tag or
> >> custom EL
> >> resolver to make that work.
> >
> > No, you most certainly would not.
> >
> > Just define an appropriate method in your class.
> 
> Color me totally dense. Maybe I'm missing what method I should be defining.
> 
> If my class implements the Map interface, then MAPElResolver will be 
> invoked and do the same thing with name.key and name["key"]: call 
> name.get("key"). The JSP EL won't be able to call any bean method of name.
> 
> If my class doesn't implement Map, then BeanELResolver will be invoked 
> and do the same thing with name.key and name["key"]: call name.getKey(). 
> The JSP EL won't be able to call name.get() via [].
> 
> So I don't see how I can have a class such that in the JSP EL I can call 
> a method to get all the keys, and also retrieve data with a key using [].

I was thinking along the lines of this incompletely worked-through notion:

 public class ContactScreenBacker
 {
   private final Map<String, Rate> rates = howeverYouSetItUp();
   public Map<String, Rate> getRates() { return Collections.unmodifiableMap(rates); }
   public Set<String> getKeys() { return Collections.unmodifiableSet(rates.getKeys(); }
// ...
 }

You should be able to use an EL like '#{thingie.rates["Bill"]}'. I haven't tried it, but this is what I had in mind.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#13136

On 3/22/2012 3:23 PM, Lew wrote:
> Chris Riesbeck wrote:
>> Lew wrote:
>>> Chris Riesbeck wrote:
>>
>> So I don't see how I can have a class such that in the JSP EL I can call
>> a method to get all the keys, and also retrieve data with a key using [].
>
> I was thinking along the lines of this incompletely worked-through notion:
>
>   public class ContactScreenBacker
>   {
>     private final Map<String, Rate>  rates = howeverYouSetItUp();
>     public Map<String, Rate>  getRates() { return Collections.unmodifiableMap(rates); }
>     public Set<String>  getKeys() { return Collections.unmodifiableSet(rates.getKeys(); }
> // ...
>   }
>
> You should be able to use an EL like '#{thingie.rates["Bill"]}'. I
> haven't tried it, but this is what I had in mind.

Yes, that's probably the approach I'll take. Not quite what I'd wanted, 
but close enough and I can't see why it shouldn't work.

Thanks, all.

[toc] | [prev] | [next] | [standalone]

#13138

Chris Riesbeck wrote:
> Lew wrote:
>> Chris Riesbeck wrote:
>>> Lew wrote:
>>>> Chris Riesbeck wrote:
>>>
>>> So I don't see how I can have a class such that in the JSP EL I can call
>>> a method to get all the keys, and also retrieve data with a key using [].
>>
>> I was thinking along the lines of this incompletely worked-through notion:
>>
>> public class ContactScreenBacker
>> {
>> private final Map<String, Rate> rates = howeverYouSetItUp();
>> public Map<String, Rate> getRates() { return
>> Collections.unmodifiableMap(rates); }
>> public Set<String> getKeys() { return
>> Collections.unmodifiableSet(rates.getKeys(); }
>> // ...
>> }
>>
>> You should be able to use an EL like '#{thingie.rates["Bill"]}'. I
>> haven't tried it, but this is what I had in mind.
>
> Yes, that's probably the approach I'll take. Not quite what I'd wanted, but
> close enough and I can't see why it shouldn't work.

Let us know how it plays out, please.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#13192

On 3/23/2012 3:50 PM, Lew wrote:
> Chris Riesbeck wrote:
>> Lew wrote:
>>>
>>> I was thinking along the lines of this incompletely worked-through
>>> notion:
>>>
>>> public class ContactScreenBacker
>>> {
>>> private final Map<String, Rate> rates = howeverYouSetItUp();
>>> public Map<String, Rate> getRates() { return
>>> Collections.unmodifiableMap(rates); }
>>> public Set<String> getKeys() { return
>>> Collections.unmodifiableSet(rates.getKeys(); }
>>> // ...
>>> }
>> Yes, that's probably the approach I'll take. Not quite what I'd
>> wanted, but
>> close enough and I can't see why it shouldn't work.
>
> Let us know how it plays out, please.

So far, fine. Only time will tell if it pays off in how my JSP looks.

Thanks

[toc] | [prev] | [next] | [standalone]

#13085

On 3/20/12 10:52 AM, Chris Riesbeck wrote:
> On 3/20/2012 12:19 PM, Chris Riesbeck wrote:
>> On 3/19/2012 6:59 PM, Daniel Pitts wrote:
>>> On 3/19/12 11:15 AM, Chris Riesbeck wrote:
>>>>
>>>> [summary: rates is an instance of a subclass of Map that
>  >>> implements getKeys()]
>>>>
>>>> Why does ${rates.keys} generate nothing in these lines of JSP?
>>>>
>>> My guess is that ${rates.keys} is interpreted as equivalent to
>>> ${rates['keys']}, so it is looking for a key of "keys", not a java bean
>>> property.
>
> Just to nail the coffin lid shut on this. The JSP EL defines name.key as
> just shorthand for name["key"]. To interpret [] expressions, JSP uses
> the first answer it gets from this chain of resolvers:
>
> ImplicitObjectELResolver
> registered custom ELResolvers
> MapELResolver
> ListELResolver
> ArrayELResolver
> BeanELResolver
> ScopedAttributeELResolver
>
>
> http://docs.oracle.com/javaee/5/api/javax/servlet/jsp/JspApplicationContext.html
>
>
> So the Map interpretation will always override the Bean interpretation.

Another interesting side-effect of this approach is that 
SomeObject.property might attempt to parse "property" as a number if 
SomeObject implements List. We've had this problem where a generic class 
which converts XML->Maps/Lists/Strings used different types depending on 
the multiplicity of specific tags.  (It was bad design IMO, but I was 
politically unable to have it designed otherwise).

[toc] | [prev] | [next] | [standalone]

#13086

On 3/20/2012 10:52 AM, Chris Riesbeck wrote:

> http://docs.oracle.com/javaee/5/api/javax/servlet/jsp/JspApplicationContext.html
>


By the way, I appreciate you sharing the problem's resolution with us, 
and also this second post on root cause.  It's nice to help someone who 
then helps you back.

[toc] | [prev] | [next] | [standalone]

#13088

On 3/20/12 11:29 AM, markspace wrote:
> On 3/20/2012 10:52 AM, Chris Riesbeck wrote:
>
>> http://docs.oracle.com/javaee/5/api/javax/servlet/jsp/JspApplicationContext.html
>>
>>
>
>
> By the way, I appreciate you sharing the problem's resolution with us,
> and also this second post on root cause. It's nice to help someone who
> then helps you back.
>
Yes, I actually new the "answer", but not the official "reason". It was 
interesting to see that "there's a spec for that".

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web