[
https://issues.apache.org/struts/browse/WW-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen resolved WW-1747.
-----------------------------
Resolution: Fixed
Fix Version/s: (was: 2.0.8)
2.0.7
- updated test to show number formatting issue
- fixed issue by preventing freemarker from formatting numbers for this template
> 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.7
>
> 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.
