I have a Grid that shows JavaBean data (i.e. I’m using a BeanItemContainer). A couple members are numbers (for efficiency sake) that represent user ids in our database. Obviously, the end user of the app shouldn’t see those numbers. So I thought the best thing to do is simply write a StringToIntegerConverter and overwrite the convertToPresentation() method. Everything works well.
But my Grid also has column filters (I pretty much followed the Vaadin Book’s example of how to do that) - and when I start entering a user id for which I see data in the Grid, the Grid immediately goes clear - because the filter is operating on the number rather than the presentation! If I enter a number, the correct rows are filtered.
So the question is: shouldn’t Vaadin’s filtering mechanism operate on the “Presentation” Strings - i.e. values returned by any Converter?
Is this a bug or am I just not understanding some basic concept?
Thanks for all info,
Tom
p.s. I’m using Vaadin 7.7.6 in case that makes a difference.
I’m no authority on the subject, but my first thought that there’s no general way of determining of how to interpret the presentation value. It could be, for example, a HTML snippet to be used by a HTML Renderer, where the obvious string-matching solution wouldn’t be the expected behavior.
So if something like this is returned from the Converter so that every value is bolded:
"<b>" + value + "</b>"
you still probably don’t want a text filter “b” to match every row.
Hi Ollie & Tatu,
I can appreciate the problem of the presentation being something that is not easily filtered on - but the problem you describe (of HTML causing problems) is really under my (the app developer’s) control: if I want to provide a filter textbox, I better make sure I don’t also write a renderer or converter that generates HTML that might cause problems.
What choice do I have when filtering is done at the container level? You say it’s by design, but why? To me, a filter box is something a user enters stuff into - i.e. it’s part of the UI/presentation. And a renderer/converter shows the String a user actually sees. Again - presentation. So why should the filtering be done at the Container level - something that can have values the user may have no understanding/knowledge of?
I think the example I gave is a good one: my end users interact and know about “user ids” - e.g. “twolf”. They have no idea that in my database and the rest of my application that user id is represented by the number 3928. So when I show a Grid containing some records, one attribute of which is the user id of the user who created a given row, my end user needs to see “twolf”, not “3928”. If they want to see all the rows created by “twolf”, they’ll start entering 'two…" into the relevant column filter.
Again, we can disagree on this. But if you insist on doing filtering at the Container level instead of first running it through available converters/renderers, then how do I accomplish what I describe above? I don’t think I’m trying to do something exotic here - surely, people write applications all the time where one or more of the fields in the Java objects being presented are numbers rather than user-understandable strings?
Creating your own filters is easy - see the Book of Vaadin’s chapter
Implementing Custom Filters . You can also compose logical chains with the built-in Or, And and Not filters.