Filtering Table Components Across Multiple Browsers

Vaadin Friends,

I have a singleton data container for a table component in my Vaadin Project. The container is persistant with adatabase table and I’m using ICEPush to keep browser sessions in sync when users are viewing the table component in their browser.

Currently, users can addItem to the table component in their browser and the item will instantly show up in other browsers, which is awesome. However, I want each user to be able to filter on their data in their table componenet without forcing the filter criteria on others browser sessions. I added the Filter addon to my project and the filtering works great, but it is forcing a browser’s filters to all the other browsers simultanesously.

How do I design the solution so that a browser can create their own filters without filtering other browsers, but if a browser updates the container by adding items, deleting items or setting different values then those changes will automatically push to all other browsers.

I keep thinking that a table component is just a mask on the container and that the component is filtering without actually changing the container data, which should make my objective possible. However, I have not been able to get this to work yet.

Any suggestions would be appreciated, thanks in advance!

Jacob

Hi,

actually the filtering is done on container level, so any filtering applied for the table object just passes that on to the container. This is why you’re seeing the same filtering in each browser. I can’t immediately think of how you could achieve the single container approach with user-specific filtering. You may need to have one “main” container (a shared instance) and additionally a container for each user. The latter container would mirror the item-level changes from the main container but perform the filtering immediately. I haven’t actually tried anything like this so unfortunately can’t approximate how easy it would be with the stock containers of vaadin.

-tepi

If the data is small enough to keep in memory, it should be feasible to write a wrapper container which just delegates most operations to the underlying container. The actual data can be in the original container, only a sorted and filtered list of IDs and some listener lists are needed in each wrapper.

The wrapping container would need to implement Container.getItemIds(), Container.size(), Container.Ordered., Container.Indexed. and (if used) Container.Sortable.*. Furthermore, it should implement ItemSetChangeNotifier (and possibly PropertySetChangeNotifier).

The tricky bits are making sure the containers listening to the master container are unregistered when appropriate to avoid memory leaks and to make refreshes efficient if the master container is modified. For the former, the listener methods of the child containers could perhaps check if they are have listeners that are attached anywhere and remove themselves from the parent if not, though covering all the cases this way is not quite trivial.