JSTL: getting a map's keys

Discussion in 'Java' started by Chris Riesbeck, Mar 19, 2012.

  1. 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>
    Chris Riesbeck, Mar 19, 2012
    #1
    1. Advertising

  2. Chris Riesbeck

    Lew Guest

    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
    Lew, Mar 19, 2012
    #2
    1. Advertising

  3. Chris Riesbeck

    Tim Slattery Guest

    Chris Riesbeck <> 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
    Tim Slattery, Mar 19, 2012
    #3
  4. On 3/19/2012 3:08 PM, Tim Slattery wrote:
    > Chris Riesbeck<> 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>
    Chris Riesbeck, Mar 19, 2012
    #4
  5. On 3/19/2012 4:06 PM, Chris Riesbeck wrote:
    > On 3/19/2012 3:08 PM, Tim Slattery wrote:
    >> Chris Riesbeck<> 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>
    Chris Riesbeck, Mar 19, 2012
    #5
  6. Chris Riesbeck

    markspace Guest

    On 3/19/2012 1:08 PM, Tim Slattery wrote:
    > Chris Riesbeck<> 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.
    markspace, Mar 19, 2012
    #6
  7. Chris Riesbeck

    Daniel Pitts Guest

    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.
    Daniel Pitts, Mar 19, 2012
    #7
  8. 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
    Chris Riesbeck, Mar 20, 2012
    #8
  9. 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.
    Chris Riesbeck, Mar 20, 2012
    #9
  10. Chris Riesbeck

    Lew Guest

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

    --
    Lew
    Lew, Mar 20, 2012
    #10
  11. Chris Riesbeck

    Daniel Pitts Guest

    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).
    Daniel Pitts, Mar 20, 2012
    #11
  12. Chris Riesbeck

    markspace Guest

    markspace, Mar 20, 2012
    #12
  13. Chris Riesbeck

    Daniel Pitts Guest

    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".
    Daniel Pitts, Mar 20, 2012
    #13
  14. 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.
    Chris Riesbeck, Mar 21, 2012
    #14
  15. Chris Riesbeck

    Lew Guest

    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
    Lew, Mar 22, 2012
    #15
  16. 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 [].
    Chris Riesbeck, Mar 22, 2012
    #16
  17. Chris Riesbeck

    Lew Guest

    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
    Lew, Mar 22, 2012
    #17
  18. 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.
    Chris Riesbeck, Mar 23, 2012
    #18
  19. Chris Riesbeck

    Lew Guest

    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
    Lew, Mar 23, 2012
    #19
  20. 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
    Chris Riesbeck, Mar 26, 2012
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Robert Mark Bram

    Custom JSTL that accepts JSTL expression

    Robert Mark Bram, Dec 15, 2004, in forum: Java
    Replies:
    0
    Views:
    950
    Robert Mark Bram
    Dec 15, 2004
  2. Paul MG

    getting keys out of a map

    Paul MG, Jul 24, 2003, in forum: C++
    Replies:
    5
    Views:
    415
    Paul MG
    Jul 25, 2003
  3. Erik Arner
    Replies:
    0
    Views:
    1,301
    Erik Arner
    Nov 2, 2004
  4. alan
    Replies:
    3
    Views:
    348
    Victor Bazarov
    Nov 28, 2007
  5. DaFoot
    Replies:
    1
    Views:
    1,664
    DaFoot
    Oct 23, 2008
Loading...

Share This Page