Details
-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Component/s: ACE-Components
-
Labels:None
-
Environment:ICEfaces 2.1, ace:dataTable
-
Assignee Priority:P2
-
Affects:Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial
Description
- text-entry field: text-‐entry field at bottom of column header region
1. User types characters into text-‐field, presses the "Enter" key to initiate filter operation.
2. Filter criteria is submitted to server for processing via ajax-submit
3. Server-side data-filtering is performed via a data-filter handler. Included is a Java-based "Match text anywhere in string" algorithm (included with component), or via deferral to a data provider (db query based implementation).
- Client-‐side filtering is NOT required (would only work against subset of data currently rendered to client).
Issue Links
- blocks
-
ICE-6997
New ace:dataTable Component
-
- Closed
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Moved the filterEvent property from the column to the data table. Seemed foolish to allow inconsistent behaviour per-filter.
Added 'enter' (submit on enter key) and 'change' (400ms delay following last keypress submit) filterEvent options.
This feature recently encountered issues related to the removal of custom update. It resulted in the header being subject to updates which caused the focus of the browser to be reapplied to the component making the submit. However, the input field making the submit has just been updated due to the submission of the value within it. The result is a correct tab index, but the text entry caret being unset in the field.
To correct this I'd added code in the filter request onsuccess event, that would reset the value in the input with the value given during the submit. This value reset worked in all browser but Firefox.
To ultimately get the correct behavior I combined a jQuery approach I'd found that worked correctly for Webkit, with one from a toolkit for jQuery called a-tools that gave alot of effort towards compatibility between IE and Mozilla.
Filtering had been refactored to use a filterValueChanged boolean to track when refiltering should occur.
filterValueChanged is initialized to true to allow the table to process on load a filter from a previous session. When this functionality isn't desired, the true value causes a filter process on null filter values. This was a special case caught by the filter processing, however it refrained from setting filterValueChanged to false like it should. The result was a constantRefilter like effect where filterValueChanged was always true, until the first non-null filtering was applied.
Corrected handling of filterValueChanged has been added, fixing the above issue.
Added TableFilterEvent and FilterListener field to table.
TableFilterEvent provides the column that filtering occurred for, and the list of row data post-filtering.