[
https://issues.apache.org/struts/browse/WW-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40227
]
Stuart Piltch commented on WW-1747:
-----------------------------------
The good news is that it passes almost all the tests. The only test that failed
was the testSimpleIntegerWithValueWorkaround() test that I added to test the
original problem in WW-1711. Removing te "toString()" makes the test pass.
Admittedly, the toString() workaround is no longer needed, but it may be harsh
to punish people that had to resort to that workaround. I'm not sure whether we
should include support for workarounds that were needed due to bugs. My vote
would be no, as long as we document that fact that if you had to resort to the
workaround, you'll need to update your code to remove it.
The better news is that the new jar file works fine for me in my app, including
the pre-selection of items in the multi-select, which had never worked before.
The only exception, of course, is the pages where I had the toString()
workaround.
> 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
>
> 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.
