[JBoss JIRA] Created: (RF-8244) dataTable built-in filter cause form values to be submitted to different rows.
7:59 a.m.
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.3.BETA1, 3.3.2.SR1, 3.3.2.GA, 3.3.2.CR1, 3.3.1
Reporter: Hugh Nguyen
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) [ ]
------------------------------------------------------------------------------------------------
INV1 [100.00]
INV2 [200.00]
INV3 [300.00]
The filterEvent is set to 'onkeyup'
Now, if I type quickly type INV3 to the filter input, the table will show only invoice
INV3, which is expected, but the Invoice Amt for INV3 would become 100.00, which is the
value for INV1. The value is not just the screen value, but it's also set into the
backing bean for INV1.
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
12:46 p.m.
New subject: [JBoss JIRA] Commented: (RF-8244) dataTable built-in filter cause form values to be submitted to different rows.
[
https://jira.jboss.org/jira/browse/RF-8244?page=com.atlassian.jira.plugin...
]
Nick Belaevski commented on RF-8244:
------------------------------------
Multiple requests should not happen if queue is active. Are there any additional settings
for queue in your application except the ones you mentioned you have in web.xml?
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
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) [ ]
------------------------------------------------------------------------------------------------
INV1 [100.00]
INV2 [200.00]
INV3 [300.00]
The filterEvent is set to 'onkeyup'
Now, if I type quickly type INV3 to the filter input, the table will show only invoice
INV3, which is expected, but the Invoice Amt for INV3 would become 100.00, which is the
value for INV1. The value is not just the screen value, but it's also set into the
backing bean for INV1.
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
3:34 a.m.
New subject: [JBoss JIRA] Commented: (RF-8244) dataTable built-in filter cause form values to be submitted to different rows.
[
https://jira.jboss.org/jira/browse/RF-8244?page=com.atlassian.jira.plugin...
]
Hugh Nguyen commented on RF-8244:
---------------------------------
I have this in web.xml:
<context-param>
<param-name>org.richfaces.queue.global.enabled</param-name>
<param-value>true</param-value>
</context-param>
There are no other queue settings.
I used LiveHttpHeaders addon for firefox to watch the http request/response and I could
see two requests being sent for the 2 keystroke on the filter.
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
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) [ ]
------------------------------------------------------------------------------------------------
INV1 [100.00]
INV2 [200.00]
INV3 [300.00]
The filterEvent is set to 'onkeyup'
Now, if I type quickly type INV3 to the filter input, the table will show only invoice
INV3, which is expected, but the Invoice Amt for INV3 would become 100.00, which is the
value for INV1. The value is not just the screen value, but it's also set into the
backing bean for INV1.
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
3:46 a.m.
New subject: [JBoss JIRA] Updated: (RF-8244) dataTable built-in filter cause form values to be submitted to different rows.
[
https://jira.jboss.org/jira/browse/RF-8244?page=com.atlassian.jira.plugin...
]
Hugh Nguyen updated RF-8244:
----------------------------
Description:
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 Z000001378. 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.
was:
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) [ ]
------------------------------------------------------------------------------------------------
INV1 [100.00]
INV2 [200.00]
INV3 [300.00]
The filterEvent is set to 'onkeyup'
Now, if I type quickly type INV3 to the filter input, the table will show only invoice
INV3, which is expected, but the Invoice Amt for INV3 would become 100.00, which is the
value for INV1. The value is not just the screen value, but it's also set into the
backing bean for INV1.
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.
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
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 Z000001378. 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
3:48 a.m.
New subject: [JBoss JIRA] Updated: (RF-8244) dataTable built-in filter cause form values to be submitted to different rows.
[
https://jira.jboss.org/jira/browse/RF-8244?page=com.atlassian.jira.plugin...
]
Hugh Nguyen updated RF-8244:
----------------------------
Description:
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.
was:
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 Z000001378. 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.
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
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
3:50 a.m.
New subject: [JBoss JIRA] Commented: (RF-8244) dataTable built-in filter cause form values to be submitted to different rows.
[
https://jira.jboss.org/jira/browse/RF-8244?page=com.atlassian.jira.plugin...
]
Hugh Nguyen commented on RF-8244:
---------------------------------
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.
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
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
4:23 p.m.
New subject: [JBoss JIRA] Assigned: (RF-8244) dataTable built-in filter cause form values to be submitted to different rows.
[
https://jira.jboss.org/jira/browse/RF-8244?page=com.atlassian.jira.plugin...
]
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
4:37 p.m.
New subject: [JBoss JIRA] Commented: (RF-8244) dataTable built-in filter cause form values to be submitted to different rows.
[
https://jira.jboss.org/jira/browse/RF-8244?page=com.atlassian.jira.plugin...
]
Nick Belaevski commented on RF-8244:
------------------------------------
So, is the problem solved now?
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
6:06 p.m.
New subject: [JBoss JIRA] Commented: (RF-8244) dataTable built-in filter cause form values to be submitted to different rows.
[
https://jira.jboss.org/jira/browse/RF-8244?page=com.atlassian.jira.plugin...
]
Hugh Nguyen commented on RF-8244:
---------------------------------
Eh, no, it's not solved.
What I meant was that the original example given could not be used to reproduce the bug.
Thus I edited the part with the example data in my bug description. The data given in the
description now is more likely to reproduce the bug.
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
12:28 a.m.
New subject: [JBoss JIRA] Commented: (RF-8244) dataTable built-in filter cause form values to be submitted to different rows.
[
https://jira.jboss.org/jira/browse/RF-8244?page=com.atlassian.jira.plugin...
]
Nick Belaevski commented on RF-8244:
------------------------------------
Please attach beans/page code to the issue.
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
1:38 a.m.
New subject: [JBoss JIRA] Commented: (RF-8244) dataTable built-in filter cause form values to be submitted to different rows.
[
https://jira.jboss.org/jira/browse/RF-8244?page=com.atlassian.jira.plugin...
]
Nick Belaevski commented on RF-8244:
------------------------------------
The same problem as here: http://community.jboss.org/thread/5759?tstart=0
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
9:57 p.m.
New subject: [JBoss JIRA] Updated: (RF-8244) dataTable built-in filter cause form values to be submitted to different rows.
[
https://jira.jboss.org/jira/browse/RF-8244?page=com.atlassian.jira.plugin...
]
Nick Belaevski updated RF-8244:
-------------------------------
Workaround Description:
Current implementation uses index of item in the filtered list as row key.
Workaround is creation of custom data model that will use more persistent row keys.
Workaround: [Workaround Exists]
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
Fix For: Future
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
9:57 p.m.
New subject: [JBoss JIRA] Updated: (RF-8244) dataTable built-in filter cause form values to be submitted to different rows.
[
https://jira.jboss.org/jira/browse/RF-8244?page=com.atlassian.jira.plugin...
]
Nick Belaevski updated RF-8244:
-------------------------------
Fix Version/s: Future
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
Fix For: Future
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
5351
days inactive
5369
days old
richfaces-issues@lists.jboss.org
12 comments
2 participants
participants (2)
-
Hugh Nguyen (JIRA) -
Nick Belaevski (JIRA)