I just released a new add-on,
FilteringTable . It was supposed to be named FilterTable but someone had already taken that name even though the add-on is no longer available.
Anyway, FilteringTable is basically a customized Table which just adds optional filtering components between the header and body of the Table. The components and filters are generated automatically based on the property types in the container. You can also provide your own filter implementations for any property by implementing the FIlterGenerator interface.
The filter components can not currently be generated by the developer, instead a set of components is provided: enum and boolean properties will get a ComboBox, Date properties get a custom date interval selector and all other types get a simple TextField. For example of implementing Integers with the TextField, see the code examples in the add-on page in directory.
You can also provide some customizations to the automatically generated filtering components, as you can see from the demo application. For example you can set the item captions and icons in the ComboBoxes and various captions in the date interval selector.
I welcome any further development ideas and bug reports, so please post them directly to this thread!
Currently known issues:
Focusing when keyboard-navigating between filter fields does not work correctly
FilterDecorator must be set to the table before the container is set
Your plugin suits exactly a use case I would like to implement this week. But I am using a tree table (and not a table). I guess FilterTable extends Table.
Any idea how hard it would be to suit this add-on to tree table as well? Also, I am happy to dig in the code and implement that myself. Is the code available somewhere?
The widget seams great, however I am having trouble compiling it. I get the following error on compilation:
[ERROR]
28-Feb-2012 16:28:27 com.vaadin.terminal.gwt.widgetsetutils.ClassPathExplorer getAvailableWidgetSets
[ERROR]
INFO: Widgetsets found from classpath:
[ERROR]
com.vaadin.terminal.gwt.DefaultWidgetSet in jar:file:C:/dev/mvnrepo/com/vaadin/vaadin/6.7.5/vaadin-6.7.5.j
[ERROR]
com.abc.widgetset.Vaadin_pushWidgetset in file://C/dev/workspaces/WS_AdminTo
main/resources
[ERROR]
org.vaadin.artur.icepush.IcepushaddonWidgetset in jar:file:C:/dev/mvnrepo/org/vaadin/addons/icepush/0.2.0/
[ERROR]
org.tepi.filtertable.gwt.FilterTableWidgetset in jar:file:C:/dev/mvnrepo/org/vaadin/addons/filteringtable/
[ERROR]
[INFO]
Using ‘UTF-8’ encoding to copy filtered resources.
[INFO]
skip non existing resourceDirectory C:\dev\workspaces\WS_AdminTool\AdminTool\modules\admin-web\src\test\resources
[INFO]
[compiler:testCompile {execution: default-testCompile}]
[INFO]
No sources to compile
[INFO]
[surefire:test {execution: default-test}]
[INFO]
No tests to run.
[INFO]
[gwt:compile {execution: default}]
[INFO]
auto discovered modules [com.abc.widgetset.Vaadin_pushWidgetset]
[INFO]
[ERROR]
BUILD ERROR
[INFO]
[INFO]
GWT Module org.vaadin.hene.popupbutton.widgetset.PopupbuttonWidgetset not found in project sources or resources.
If I remove the dependency to the widget from my pom file and leave only the Icepush addon dependency my project compiles. So Im not sure what the problem here is. Any idea?
Great widget, should be standard feature of Table and TreeTable !
But a few notes:
the very first feedback when I showed this to a user was “it should be possible to filter as soon as I stop typing”
so I went ahead and extracted the source from the jar
and I created two maven projects, one for the jar, and one for the demo.
and I made the requested improvement
Please find enclosed a zip file with the two Maven projects.
In my variation, FilterDecorator class now has one more method isTextFilterImmediate(Object propertyId). If this method returns true, then the TextField is created with a TextChangeListener (see FilterTable).
It would be great if you made the source available in a repository, and preferably in Maven format. 12219.zip (4.95 MB)
I second that. I still would like to use that for tree table and, Jean-François, I exactly wanted to implement that feature as well, you’ve been too fast, thanks !
I think you’re missing the PopupButton jar from the widgetset build path. The FilteringTable requires also the PopupButton add-on, and it’s included in the zip file. Please make sure that the compiler can find it while compiling the widgetset.
Thanks! This does seem like a good feature. Of course one might want to be careful with the text change timeout expecially if each filtering event goes all the way to the database through an SQLContainer or something similar.
I’ll try to get it into github as soon as I have the time. I’ll be sure to include your change :).
Looking at the code of TreeTable (and VTreeTable) I don’t immediately see an ‘easy’ way of integrating this add-on with it. I’ll probably have to make a separate version of the add-on for TreeTable. I think most of the code can be reused though.
The source code of the add-on is currently available only in the add-on jar file, you can extract it from there. I’ll try to get it into a repo as soon as I have the time for it.
You were right, the problem was I was missing the PopupButton addon. Thanks! The addon is great, good job.
I found one issue however, If I have my table placed in a horizontal spit layout, for some reason the search text fields get disabled and I am not able to perform any searches. Any suggestions??
Perhaps decorator methods could have variations to set the setInputEventTimeout() and perhaps the LAZY/TIMEOUT method of the text field. We actually use the field with SQL-based containers and the default behaviour is actually pretty good (waits just long enough before reacting)
Anything you want, since you can generate the filter as you wish.
Not currently – though this would not be difficult to do since a simple field is used.
Not currently – though this would probably be easy to add.
Paging is done by the underlying container. So if you use a paging containert hat implements the Filterable interface such as JPAContainer, JPA Criteria LazyQueryContainer, etc. it will work just fine.
Not sure.
1, 2, 4 and 5 would be easily handled if there was a FilterFieldGenerator in addition to the decorator. The current code is just a 20-line routine that, at first glance, could be factored out.
Hello Jean…, Thanks for the quick response, we are evaluating vaadin for one of our new project, is there a way to extend filtering table to accommodate these requirements?
For the first requirement, the filter generator is only providing the ability to change the values, but not providing the ability to bind the list of values.
And also there is another issue with this component, the headers are not matching the filters, attached a screenshot, do you see any fix for it pls?
Looking at the source, it seems straightforward to add a method to the FilterGenerator, one that would create the corresponding field use for filtering. In the database filtering case it would return a select bound to the desired values. Something like getFilteringField() would make sense to me. In that way, one could do a select in a database, find all unique values in the column, and create a select based on that. Voilà, instant Excel-like filtering.
Something like that is likely less than a day of coding/testing. Hopefully Tepi is following the discussion and can add that in. Else, either you or me or anyone else can add it if we need it. That’s what open source is all about…
I am not the author, Tepi is. Whereas I am quite comfortable with the server-side stuff, I’ve never had much need to look at the client-side rendering. So someone else will need to pitch in.
I am using a PagedTableContainer as the datasource for a FilterTable, but my
shows up empty, could this be because
PagedTableContainer
implements Container, Container.Indexed, Container.Sortable
whereas IndexedContainer used in the example also implements
Container.PropertySetChangeNotifier, Property.ValueChangeNotifier,
Cloneable, Container.Filterable,
Container.SimpleFilterable
This is the reason I started work on JPA 2.0 Criteria LQC – I wanted to be able to use the standard JPA 2.0 API for creating filters without manipulating textual SQL. JPA 2.0 Criteria LazyQueryContainer is actually a wrapper, it delegates most calls to LQC and does not modify it.
In Vaadin 6.6,. Filterable was added, and Vaadin now supports it in SQLContainer and JPAContainer, should you prefer those over JPA 2.0 Criteria LQC.
