Make FreeMarker macros for select input LinkedHashMap friendly [SPR-3864]

[spring-projects-issues]

Eric Bottard opened SPR-3864 and commented

The freemarker macros that generate inputs of the type <select /> such as formSingleSelect iterate on options?keys. This is technically correct, but it would be nice to iterate on entries as this is what is ordered in LinkedHashMaps. This would allow to easily display options in label order.

Please note that using a SortedMap does not work, as one often wants values ordering (what is diplayed) rather then key ordering.

Hope this RFE makes sense.

---

Affects: 2.1 M3

[spring-projects-issues]

Juergen Hoeller commented

According to the FreeMarker documentation (http://www.freemarker.org/docs/ref_builtins_hash.html#ref_builtin_keys), "?keys" is supposed to preserve ordering if there is any in the underlying Map... So if that doesn't work for you, do you have a suggestion for an alternative implementation of those macros, using something other than "?keys"?

Juergen

[spring-projects-issues]

Eric Bottard commented

The thing is, ?keys preserves order of the "keySet()" which is slightly different from the order of the "Map". Indeed, LinkedHashMap guaranties order on its entrySet() iterator, but not on keySet() (nor values()).

My understanding is that there is rarely benefit to iterate in keys order (which are technical "codes") but there is often to iterate on values order (labels).
To accomodate both, the best way is IMO to use a LinkedHashMap (configured to expose insertion order). However, only LinkedHashMap#entrySet() surfaces that order.

So my "implementation" solution would be to do something similar to this :

<#macro formSingleSelect path options attributes="">
<@bind path/>
<select id="${status.expression}" name="${status.expression}" ${attributes}>
<#list options.entrySet() as entry>

<option value="${entry.key?html}"<@checkSelected entry.key/>>${options[entry.key]?html}</option>
</#list>
</select>
</#macro>
which is less elegant I admit, but not that much...

[spring-projects-issues]

Juergen Hoeller commented

Actually, as far as I can tell both from playing with it and from reviewing its implementation, LinkedHashMap seems to preserve order for all of its iterators, entrySet as well as keySet and values. Implementation-wise, the keySet/values iterators are the same as the entrySet iterator, just exposing a different object (key/value instead of the Entry)... Where exactly did you get the impression from that LinkedHashMap only guarantees ordering for its entrySet? Are you referring to potentially different implementations of LinkedHashMap here (I checked the one in Sun's JDK 1.6)?

Juergen

[spring-projects-issues]

Eric Bottard commented

Well this is extremely embarrassing :
#1 you're totally right about how LinkedHashMap works (and I did check JDK5 as well)
#2 Not only that, but I can't reproducte my problem now !

I guess all this shows that one should not jump to conclusions so fast (shame)

Feel free to close this one as "wontfix', I'll dig it if I can reproduce it and it actually really matches the topic (double check'd)

Sorry for the noise,
/me exiles in a cave

[spring-projects-issues]

Juergen Hoeller commented

No worries, our IT world is so full of side effects that it's sometimes hard to find the intended effects ;-)

Juergen