Fixed: HashMaps are not properly rendered in FTL with current FTL integration (OFBIZ-13164) - #1616
Merged
mridulpathak merged 1 commit intoAug 10, 2026
Conversation
…egration (OFBIZ-13164)
FreeMarkerWorker built a plain BeansWrapper, so every java.util.Map reached
templates as freemarker.ext.beans.MapModel. MapModel.keySet() returns the
union of the map's own keys and the bean property names of the map object, so
key enumeration saw accessors mixed in with the real entries. On a two entry
map, ?size reported 30, ?keys listed getClass, put, entrySet and the rest
alongside alpha and beta, and <#list aMap as key, value> failed outright,
because the values behind those synthetic keys are methods rather than
strings.
Added OfbizBeansWrapper, which substitutes a MapModel whose key set is the
map's own. Only enumeration changes: member lookup still falls back to the
bean model, so templates keep calling methods on maps. That distinction
matters because GenericEntity implements Map, so switching to
DefaultObjectWrapper or enabling simpleMapWrapper would have broken every
${anEntity.getRelatedOne(...)}, ${anEntity.getString(...)} and
${aMap.get(...)} currently in the templates.
HtmlWidget.ExtendedWrapper now extends OfbizBeansWrapper so that screen
rendering picks up the same behaviour.
Two secondary effects are worth noting: ?keys now follows the map's iteration
order rather than being arbitrary, and an empty map now reports ?size 0,
which is consistent with the ?has_content it already reported.
Thanks to Carsten Schinzer for reporting this issue and for identifying the
BeansWrapper versus DefaultObjectWrapper mechanism behind it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backported from trunk (#1615). OfbizBeansWrapper substitutes a MapModel whose key set is the map's own, instead of FreeMarker's stock union of the map's keys and its bean property names, so ?keys, ?size, and <#list map as key, value> stop seeing accessors like getClass or entrySet mixed in with the real entries; HtmlWidget.ExtendedWrapper picks up the same fix for screen rendering. Cherry-picked cleanly onto release24.09 with no conflicts and no adaptation needed.
Thanks: Aditi Patel (author of the trunk fix) and Carsten Schinzer (original reporter).