It seems that the BeanItemContainer or IndexedContainer supports Container.Filterable that takes a ‘filterString’ that appears to be either ‘contains’ or ‘starts with’ along with the option of ‘ignore case’. Even an exact match seems to not be supported.
What does it mean to make a simpler regex type filter? That is, with a regex, you can generally take that ‘filterString’ and make it an exact match, starts with, ends with and ignore case.
How can you get those containers to apply different filter logic (like regex) instead? I seems like an exact match (with or without case matching) should be a pretty common filter need.
Just noted the protected void filter(Filter f) method. So is the only method to subclass BeanItemContainer to override addContainerFilter() along with my RegexFilter class built like Filter that does this for me? I was hoping to just write the RegexFilter and somehow set it into BeanItemContainer. Any plans to allow a Filter to be set without subclassing the BeanItemContainer itself?
Hi
Am Beginner to vaadin. Am really not getting idea how to implement container.Filterable .Can you please share me your code of implementation of container.Filterable to search in an container. It really helps me a lot.
Swetha, if I undestood correctly you are asking how to use the filtering already available in Vaadin? The way to use the current fiterable API is to have a IndexedContainer or BeanItemContainer (possibly others) and call something like:
container.addContainerFilter("name", "foo", true, false);
This means that it will look into the container for the property “name” in every item, and only show those items that contain “foo” in it anywhere in the value, disregarding the letter casing.
This might come a “tad” late for your needs, as you write the message in April, but I’m glad to say that more flexible filters are looked into right now. Just to give a nudge on the matter, I wrote a patch yesterday that allows filtering with own code. You basically write an own implementation to one method of a filter, which returns true or false depending on if it passes the filter. You can easily write filters like regexp and date matching. The patch can be found here:
http://dev.vaadin.com/ticket/6157
The patch is written and implemented into IndexedContainer right now, but I have locally done it for BeanItemContainer as well, and it is just as easy. I don’t think the patch will directly get into core Vaadin but I hope it will speed things up. In the meanwhile you could apply the patch locally as it should work perfectly. Sadly, it requires that you subclass the BeanItemContainer, that you hoped to avoid, or build your own custom Vaadin package.
Thanks, but having patched, unsupported code is not something we’d like to do right now. We’ll have enough of our own issues without having to maintain a patch with each new release.
I wrote in
a previous posting what seemed like such a simple solution to the core that would let us add current style filters without breaking existing code.
The idea was simply to expose an addFilter() method and then change the current addContainerFilter() method to call it after it builds the only type of Filter that it allows now. The existing method would work exactly like it did before, but the ability to add the filter would be made available. The filter still only worked on a single property so it’s a bit limited (versus your LogicFilter that appears to give me access to the Item instead, which is a good thing to be sure), but would be available and should cause no issue with the core platform as it is today, yet give us the flexibility to use more than the one type of filter allowed.
I hope something like your LogicFilter is put into the core, too. It seems simple enough and appears to let me filter the on the object (Item) instead of just a single field (Property). It makes good sense, so wish it would just become available generally.
The fixed addFilter() method would give us power right away without really changing anything, and your method would let us build AND/OR filters too. Keeping my fingers crossed…