[
https://jira.jboss.org/jira/browse/RF-8244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Belaevski reassigned RF-8244:
----------------------------------
Assignee: Nick Belaevski
> dataTable built-in filter cause form values to be submitted to different rows.
> ------------------------------------------------------------------------------
>
> Key: RF-8244
> URL: https://jira.jboss.org/jira/browse/RF-8244
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 3.3.1, 3.3.2.CR1, 3.3.2.GA, 3.3.2.SR1, 3.3.3.BETA1
> Reporter: Hugh Nguyen
> Assignee: Nick Belaevski
>
> This is regarding rich:dataTable built-in filtering.
> The filter requests submit and process the entire form that enclosed the
> table, including all the form fields inside the table.
> Besides the issue of inefficiency, this submission cause an obscure bug:
> The form data of the first row before filtering SOMETIMES get submitted into
> the first row that appear after the the filtering request is completed.
> For example, I have an Invoice table like this
> Invoice No
> Invoice Amt
> (filter input) [Z0000013 ]
> ------------------------------------------------------------------------------------------------
> Z000001334
> [66.00]
> Z000001369
> [77.00]
> Z000001373
> [88.00]
> Z000001375
> [99.00]
> Z000001378
> [00.00]
> The filterEvent is set to 'onkeyup'
> Now, if I type quickly add '78' to the filter input, the table will show only
> invoice Z000001378, which is expected, but the Invoice Amt for Z000001378
> would become 66.00, which is the value for Z000001334. The value is not just
> the screen value, but it's also set into the backing bean for Z000001378.
> Furthermore, the backing bean value for Invoice Amt of Z000001373 is also
> updated 66.00. I suspect that this is because Z000001373 would be the first
> invoice shown after the first key stroke ('7')
> -------------------------
> Edit note: I realised that my original example is not quite valid. I rewrote
> above it with the actual data from my system this time. The notable change
> here is that each filter key stroke would cause the table to be updated.
> -------------------------
> If I leave filterEvent value as default 'onblur', the bug is less likely to
> occur, but still can happen if I manage to cause the Ajax requests to be sent
> fast enough.
> For Richfaces configuration, I enabled the global queue in web.xml.
> With a bit of tracing, I found that all the input field values present in the
> table before the filtering happen is sent along with the Filter input during
> the enclosing form submission, and there is no ajaxSingle attribute for the
> Filter input. I guess that there is some mix up of processing the multiple
> filter requests that come before the filtered result is returned, and this
> cause the submission value to go into the wrong row(s).
> My suggestion is that there should be some way to cause the form to only
> process the Filter input, all other inputs should be ignored, in a manner
> similar to ajaxSingle attribute for the components that support it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
richfaces-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/richfaces-issues
