Maddon is now called Viritin

My colleagues teased me enough about the add-on name Maddon. M can mean Matti’s add-on, but it also had to dual nature meaning I always made helpers there when APIs in core Vaadin (possibly even written by me) made me mad when using it :slight_smile:

Anyways, the new name Viritin is a Finnish word, meaning tuner, and I think it describes the add-on pretty well too. It tunes Vaadin to be on the same frequency with you. English people might pronounce it almost like “wire it in” which also suits for the add-on as well, as lots of its
latest helpers
are related to binding your domain model to UI, wiring it in for the actual end user.

The add-on itself
(at least with its previous name) has become quite popular already. And there has been lots of active contributors, thank you! There is now also a viritin organization in the github and I hope to get even more contributions for it in the future, now that Viritin is no more just Matti’s add-on.

BTW. You can also expect some other cool Vaadin related things to pop up to under the governance of “Viritin organization”. That yet to be published helper might change the way you use Vaadin even more than the Viritin add-on itself.

Hi Matt

I am following your posts regarding Viritin over couple of days and i am new to Vaadin. I feel that lot my teething problems while using JPA container , beanfieldgroup and validation will simply go away if i use this addon. I am however struggling with very basic use cases ( am not a seasoned developer). Do you think there is some place where i can get my basic right about all this?

Best Regards


Check out the examples listed on
the github page
. There are both Spring and Java EE based examples. I strongly suggest to use either of them as a basis for your application.


Hi Matti,

I’ve started trying to adopt Viriting very recently, although I’ve been aware of its existance for quite a long time. I’m stil using Vaadin 7.7.13, and I’ve reached a critical point where the app I’m developing cannot scale any more due to its heavy usage of grids with large enough amounts of data and different performance problems with its different containers, SQLContainer (which theoretically supports lazy loading) very unusably buggy, and that on.

The Viritin version I’m using is, thus, v1.61.

Trying to learn how to use it is not an easy task. First of all, much of documentation and online examples are not working anymore. Code samples from the “Code Samples” (lol) tab in the plugin page are so simplistic that are not useful for real cases.
Most of “Related Links” do not work, too. None of the blog entries work anymore, displaying a big 404 page. The example app at does not work - even the domain doesn’t exist anymore. Other examples are not online anymore, either.

Nevertheless, I’ve managed to get it working somehow. My main interesit is to use the “lazy loading” of data in a Grid. What I’ve done so far is to populate a “classic” vaadin Grid setting its dataSource to a ListContainer.

By the way, one of the things I’d like to know is what’s the difference between using something like

Grid.setContainerDataSource(new ListContainer(new SortableLazyList<>(new SortableLazyList.SortablePagingProvider<...


MGrid<DemoBean> t = new MGrid<>();
final FilterableListContainer<DemoBean> lc = new FilterableListContainer<DemoBean>(new SortableLazyList<>(new SortableLazyList.SortablePagingProvider<DemoBean>() );

I mean: what’s the point of using Mgrid vs “classical” Vaadin Grid, if any?

Appart from that, my lazy loading of items was working fine while simply using LazyList with its PagingProvider. But it turned to be useless as I needed the sorting and ordering feature the Grid provides.

My problem now is that I don’t understand at all the scarce examples I’ve found on the net, the most useful of them being at

and referenced by yourself in some bug report. I’m finding it hard to reproduce your example in real life. After studying your code, I think that what you mean there is to replace the


parts with actual real calls to the DAO service and getting the proper “ranges of sets” needed to fetch the amount of data one is looking at each moment. That would also explain why you doo a


at the beginning, just ruining the whole purpose of lazy loading. Am I right?

Also, the

Collections.sort(listOfPersons, new BeanComparator<Person>(property))

part should again call in the end some DAO service method populating a collection of objects from a database query with the proper filtering parameters on it. Am I right, also?

I know I’m probably explaining myself very bad. But, in the end, is there any jdbc-oriented example which implements some real-world case using SortableLazyList with working filtering and sorting??

Hi Pascal,

The latest examples are for V8 and are quite a bit different, but the older examples should be visible from the github in branches. My suggestion is to use MGrid directly. It contains couple of hooks important for sorting and contains much more intuitive API, thanks to a proper typing.

Here are couple of helpful links to examples which should help you to get forward:

Multiple MGrid examples in Viritin projects vaadin7 branch:

A simple JPA addressbook example with lazy loading example in the end:

Similar simple CRUD for Spring:

I don’t remember if I have a plain JDBC example available, but creating once should possible as well.

Thanks for pointing out the 404 links in the Directory. The recent renewal brutally deleted old “personal blogs”. I’ll try to fix those too soon.


Thanks a lot, Matti! Both for clarifying the first point (I’ll try to switch to MGrid instead of using “classical” Grid) and for the very valuable links. And finally for letting us know that Viritin is still alive and well, also!

I’m going to take a look at the example links in a while. Will let you know about how it’s going ;).

Cheers and keep up the good work! :wink:

Hi again,

Now that I’ve taken a look to the examples, seeing that there is a example and a one, I’m wondering if it is possible to both multi sort and filter a MGrid with lazyloading. Because I’m currently allowing both actions in my regular Grids.

Second, I still see the

final List orig = Service.getListOfPersons(1000);

line at the beginning on the MultiSorting example, then the in-memory slicing of collections. What’s the meaning of this? Why if my total set of data is less than 1000 elements? It wouldn’t make any sense using LazyLoading if I get all the records at the beginning…

Hi, is not really a cleaned example, more of a PoC/test that multisorting can be done. By quickly looking at the example, I think it would be pretty easy to clean the test code behind a fake DAO, but I think I’ll spend my limited community development time for more recent Vaadin versions.


Thanks a lot for your reply, Matti. Of course I don’t want you to waste your scarce development time and I’m already very grateful of your contributions so I’m not asking for a full rewritten example… I thought the questions from my last post where more or less short and concrete:

  1. Is it possible to both have
    functionality at once?
    I mean, a Grid that lazy loads its contents (from a database query) and allows both to sort based on columns, by clicking on its column headers, and at the same time include a textfield for filtering in each column?

  2. What’s the point of loading 1000 elements, all at once, at the beginning, in the mocked up example? Doesn’t that defeat the whole purpose of lazy loading?
    Should I be loading “batches” of table rows via LIMIT and OFFSET when using a database query, instead of that mocked up collection slices? If that’s the case, what to do for the initial batch?

Please believe me that I don’t mean to be rude in any way. Maybe some Viritin user is able to point me in the right direction with an answer for those questions, so I can decide if I should spend more time investigating on this or maybe I should attempt a different approach.

Also this can be a great add-on, but please have present that without the addition of some sort of basic documentation a lot of users, maybe we the least experienced ones with these kind of approaches, won’t be able to benefit from it…

Okay, I’ll try to simplify me question even more.

I need to lazy load contents, sort by column (not necessarily multi sort) and be able to filter by multiple columns.

Is this definitely possible with Viritin?

By looking at the sources and at the examples, what I’m inferring is that THERE ISN’T any sort of “FilterableLazyList” class implementing the Container.Filterable interface – which is what I “mean” by “filterable”.

I mean: yeah, there is this kind of “lazy loading” and “filterable” example there:


But, as you said, that’s a proof of concept. If it doesn’t implement that Container.Filterable interface, I have to redo everything by hand and cannot take advantage of my existing code.

It would be very useful if someone reading this could confirm my suspices and/or add some kind of suggestion in case I am right…

Thanks again!

Hi Pere,

Sorry I haven’t found time to answer, been traveling this week.

That sure ought to be possible. You’ll just need to place multiple filter boxes and take those into account when doing the DB queries. I’ll try to find time next week to enhance the example a bit.


Matti Tahvonen:
Hi Pere,

Sorry I haven’t found time to answer, been traveling this week.

That sure ought to be possible. You’ll just need to place multiple filter boxes and take those into account when doing the DB queries. I’ll try to find time next week to enhance the example a bit.


Thanks again for your support, Matti.

In the meantime, I’m heavily struggling with this and doing some significant progress. Having already successfully accomplished sorting and tested a filtering “proof of concept”, I’m about halfway of implementing a “generic” method taking advantage in part of what I have already working, thanks to the “discovery” of StatementHelper methods (like generateSelectQuery) that can do the translation of my already existing Container filters to SQL (I didn’t know of them previously). This way I can keep track of all my column filtering and use them inside the findEntities(startIndex, order, columnProperty) method. Hopefully, I mean (as I don’t have it working yet).


Enhanced the examples a bit in plane. This probably makes it easier to figure out what you should do:

In your own service layer you’ll just need to do the sorting and filtering so that it happens in the DB, not in JVM like in the example.

If you have a lot of properties, it might be better to pass filters as a map to your service layer (to keep the API clean).



Last Friday I finally got it working, Matti, and as I accomplished the search functionality at the end of my working journey and didn’t touch a keyboard during weekend, completely forgot to mention anything in this thread…

Anyway, I’m taking a look at the upgraded examples and comparing them with what I’ve done.

Thanks a lot again, Matti!

Ok, I have this lazy loading mechanism “more or less” working with my own search solutions. Yet some other aspects need a bit of fine-tuning.

One big problem I’ve encountered recently is when I put my grid in selection mode. If I click on the “select all” button in the table header, this fires fetching ALL rows from the grid. This takes a lot of time as my Grid has tens of thousands of elements, and it’s even less efficient and much slower then doing it all at once, because it makes a number of queries as it is done in batches. SelectionListener does have a select method where you can count for the number of selected rows and maybe take some action accordingly (like maybe showing a dialog asking user for confirmation or letting cancel the action), but unfortunately this is fired after all rows have effectively been selected.

Can anyone think of a way of solving this? Is maybe a way of detecting inside PagingProvider if it as been fired after some selection?

Thanks a lot again in advance!

Hi again,

I’m experiencing some out of bounds exceptions and some sort of infinite loops inside findEntities or so, and I don’t know if it’s a bug in Viritin or if I’m doing something wrong.

The behaviour is reproducible. I filter by one column, then suppose I get my MGrid with filter results, erase the filter content (which is a TextField), then try to filter by any other column. First of all, I get a

java.lang.IndexOutOfBoundsException: toIndex = 85

exception. The toIndex value always seems to be 85 no matter the filtering result, so I bet it’s something related to my page size, which is 100.

After that, if I again erase the content of the filter TextField, then findEntities seems to get fired infinitely, or at least until it gets all rows of the MGrid (I don’t know it for sure, because as I have 90,000+ rows, I always end execution before reaching the end as it goes for ages and it puts my database cpu usage to more than 50%).

Inside my CountProvider I’m properly returning the total count taking all filtering into account, and inside findEntities I’m calling a service method which always gets it’s elements from a query which limites to results to, again, my page limit (100), so I have no clue what I’m doing wrong.

To me it sounds like after the first OutOfBoundsException some values of MGrid get in an incorrect state, making it to fetch all possible rows… But maybe I’m wrong.

Any clue would be greatly appreciated as, apart from these annoying exceptions (which renders it unusable), lazy loading is working properly and it makes a huge difference in terms of memory usage and efficiency… :frowning:

By the way:

What’s the difference between v1.61 and viritin-v7-compatibility-1.0 I see in the repository? Which one should I use if I’m still on Vaadin v7?? And what’s viriting-compatibility folder?

Very confusing…

1.X era is for Vaadin 7. The compatiblity module only if you are using Vaadin 8 and migrating from V7 code.

Can you post the code that is causing the problem as a project. It would make it easier to debug the issue. If you are not using any Grid specific issues, you might also try with MTable as you are in V7. That’s more stable and better tested component.


Thanks a lot for clarifying, Matti! Now I’m sure I just need to keep sticking to v1.61.

Regarding the issue I was having, I think I’ve found the problem - at least the one regarding the “almost-infinite-content-(re)loading” (I have yet to find if the 85 has disappeared as a “side effect” because this one is not that clear), and my own code is the one to blame. I had some code which would keep track of the current selected row (mostly by cliking on it) in order to display it in a kind of “navigator” (row X of XXXXX). If, for instance, I had row #25 selected, then I made a search, and this previously selected row was not in the filtered returned set, my code did a


to get the row number. In the case of this LazyContainer, this is what was firing the continuous page requests, probably not completely “hanging” the process but effectively doing it, as it would need 90,000 / 100 = 900 queries and everything to finally fetch the full datasource or so, until it was able to get the selected row index… Well, the explanation may not be accurate but more or less that’s what was happening.

Clearing up my inbox and noticed there was another question related to selection. AFAIK the current multiselection mode in Vaadin just can’t scale very well. I haven’t heard that there is programmatic way to disable the select all functionality, but I guess that could be disabled by hiding it using CSS.

Alternatively, if you still need that functionality, you’ll need to implement selection funtionally manually somehow so that it also scales for selection of all items. Not sure if it is easy to plug-in to the components functionality, but should be pretty easy if you just use a separate button for selecting all rows for certain action. You can simulate the selection of rows by addin a StyleGenerator and some CSS (or maybe stealing the classname of selected rows from the core theme).