JSTL: getting a map's keys

C

Chris Riesbeck

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>
 
L

Lew

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
Click to expand...

If you mean 'java.util.Hashtable', that's a rather obsolete class. You should stick with 'java.util.HashMap'.
keyset()
Click to expand...

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
Click to expand...

If "rates" is set to an instance of a 'HashTable' said:
Why does ${rates.keys} generate nothing in these lines of JSP?
Click to expand...

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>
Click to expand...

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

Tim Slattery

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

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.
 
C

Chris Riesbeck

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.
Click to expand...
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>
 
C

Chris Riesbeck

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.
Click to expand...
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>
Click to expand...

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>
 
M

markspace

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.
Click to expand...


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.
 
D

Daniel Pitts

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>
Click to expand...
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.
 
C

Chris Riesbeck

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>
Click to expand...
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.
Click to expand...

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.
Click to expand...

Yes, that's what I've been doing instead for looping.
Hopefully this helps,
Daniel.
Click to expand...

Indeed. Thanks, Daniel
 
C

Chris Riesbeck

[summary: rates is an instance of a subclass of Map that
implements getKeys()]

Why does ${rates.keys} generate nothing in these lines of JSP?
Click to expand...
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.
Click to expand...
Click to expand...

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.
 
L

Lew

Chris said:
Chris said:
Daniel said:
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.
Click to expand...
Click to expand...

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.
Click to expand...

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 viewartifact (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 presentationconcerns.
 
D

Daniel Pitts

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.
Click to expand...
Click to expand...

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.
Click to expand...

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).
 
D

Daniel Pitts

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.
Click to expand...
Yes, I actually new the "answer", but not the official "reason". It was
interesting to see that "there's a spec for that".
 
C

Chris Riesbeck

Chris Riesbeck wrote:

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

- Don't have scriptlet in your JSPs.
Click to expand...

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.
Click to expand...

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.
 
L

Lew

Chris said:
Lew said:
- 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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

Which would be neatly accomplished by my suggestion.
 
C

Chris Riesbeck

Chris said:
Lew said:
- 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.
Click to expand...

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.
Click to expand...

No, you most certainly would not.

Just define an appropriate method in your class.
Click to expand...

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 [].
 
L

Lew

Chris said:
Lew said:
Chris said:
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.
Click to expand...

No, you most certainly would not.

Just define an appropriate method in your class.
Click to expand...

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 [].
Click to expand...

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.
 
C

Chris Riesbeck

Chris said:
Lew said:
Chris Riesbeck wrote:
Click to expand...

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 [].
Click to expand...

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.
Click to expand...

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.
 
L

Lew

Chris said:
Lew said:
Chris said:
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 [].
Click to expand...

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.
Click to expand...

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.
Click to expand...

Let us know how it plays out, please.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

comp.lang.c Answers to Frequently Asked Questions (FAQ List) 1

Members online

No members online now.
Total: 35 (members: 1, guests: 34)
Robots: 592

Forum statistics

Threads
473,769
Messages
2,569,578
Members
45,052
Latest member
LucyCarper

Latest Threads

Top