[
https://issues.apache.org/struts/browse/WW-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40448
]
Rene Gielen commented on WW-1747:
---------------------------------
OK, maybe a much simpler solution: Prevent freemarker from formatting numbers
here! We don't need this feature at all, so just putting
<#setting number_format="#">
on top of the template makes all tests run. If there are no objections I'll
commit this one including updated test case.
> select tag doesn't work with "multiple" if list keys are not strings
> --------------------------------------------------------------------
>
> Key: WW-1747
> URL: https://issues.apache.org/struts/browse/WW-1747
> Project: Struts 2
> Issue Type: Bug
> Components: Views
> Affects Versions: 2.0.6
> Reporter: Stuart Piltch
> Assigned To: Rene Gielen
> Fix For: 2.0.8
>
> Attachments: WW-1747.patch
>
>
> This is similar to WW-1711, but the fix included there doesn't handle the
> case where the select tag has multiple="true" and the listKey is not a
> string. In some cases, this can result in a freemarker syntax error:
> Expected number, date, or string. parameters.nameValue evaluated instead to
> freemarker.ext.beans.ArrayModel
> I'll try to create a new test case that fails (the current multiple select
> test passes in a array of Strings), then I'll attempt to find a more complete
> fix. In the meantime, if anyone needs to get this working, a quick workaround
> is to override the template/simple/select.ftl file and change this:
> <#if tag.contains(parameters.nameValue, itemKey) == true ||
> (parameters.nameValue?exists && parameters.nameValue?string == itemKey)>
> to this:
> <#if tag.contains(parameters.nameValue, itemKey) == true ||
> (parameters.nameValue?exists && (parameters.nameValue?is_string
> || parameters.nameValue?is_number) &&
> parameters.nameValue?string == itemKey) >
> It still doesn't correctly pre-select values if the listKey isn't a string,
> but at least it avoids the freemarker error. I'm not convinced that this is
> the right long-term solution, so I didn't make it a source patch. It may be
> useful to do so, though, if this doesn't get fixed soon.
> I think the correct fix here (and the cleaner fix for WW-1711) will be to
> create a new contains() method that checks objects.toString() against the
> strings (right now it only matches if the types match). But that's currently
> done in OGNL. Maybe we need our own contains()?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
