Vaadin Part Deux – Widgets, Forms, Validators

So I’ve been playing around with Vaadin for a few hours – I can’t help but wonder what the code looks like that is running in the browser. The easiest way to see this is to use either Chrome and its built in code browser or use Firefox with Firebug (my choice here). These tools will let you hover over elements in the page and then inspect them in a DOM browser. Firebug also lets you look at CSS and script file separately.

What you see in there will probably make you cringe if you are a CSS positioning purist or don’t care for in-line CSS or hate the use of tables and have banned them from your code (ok that’s me). Overall – its not too bad considering this is all stock generated code that I can probably tweak a bit. While I’m looking at code – the current application while running is now taking about 180MB of RAM on tomcat 7 and Win64. I’ll have to see if I can tweak the settings and/or server config to see if this can be tweaked.

Forms – Saving Data

Handling form events seems fairly simple – forms by default persist data immediately, but you can also set events and modes so that they save data only when clicking a save button. Here’s a form button handler event for this. One interesting function there is the “isValid()” call. You can register specific data validators for the form – like an email address validator  (more later on validation).

That looks pretty handy. In the forms sections of the tutorials the Vaadin guys are assuming you are on the ball – make sure you are implementing all parts of the listener stuff. I was getting a bit tricked up on making sure I had the correct constructor method arguments with the listener cast included.

I also had some trouble with populating combo boxes – I get extra blank lines in the combo box – not too sure why. I did some debugging and testing – which works quite nicely in the tools. I can see in the hashmap table for the combobox that there is one blank and then a value – debugger works and so does the code.

From what I can tell the tutorial tells you to enter a blank row so that you can add a value, but this is not really necessary as there is already a blank because the field has been set to allow new entries. Since I want to allow new entries I just removed the call to add a blank line. I also wrapped the calls to add new items in an if test to not add empty strings or nulls to the combo box – I also trimmed all the entries – probably not necessary:

//Setup the cities combobox values
cities.setNewItemsAllowed(true);
PersonContainer ds = app.getDataSource();
for (Iterator<Person> it = ds.getItemIds().iterator(); it.hasNext();)
{
String city = (it.next()).getCity();
System.out.println(“City=” + city);
if (city != “” && city != null)
cities.addItem(city.trim());
}

Validators

Validating data seems really easy. You can attach regular expression based data validation rules to fields in your forms. This is described clearly in the tutorial. If you haven’t messed with RegExp too much creating these can be painful, there’s decent online help and even books on the topic. The validation example in the tutorial of course doesn’t work here in the US since postal codes in the US can have leading zeros. You would need to go back all the way to the beginning and change out the postal code from a number field to a string to fix this issue.

How this would get internationalized is not clear to me either. I guess you could use an i18n bundle key for the regexp itself and then the string too. I updated the regexp to “[0-9]{5}” for the USA. For more complex data fields Vaadin offers some special help – for example EmailValidator.

This – use it

One thing I’ve noticed is that most of the tutorial and sample code omits the “this” object. Well that’s ok if you know the APIs by heart, but for newbies to Vaadin I think using “this” makes learning much easier. So when you are in the app class, panel classes,etc. use it – “this.get…” will popup the available methods so you can explore them.

Deployment on Tomcat 7

I did promise some information on Tomcat deployment of the app outside of Eclipse. Well with many frameworks this can be a painful experience with deployment descriptors, annotations, etc. So far with Vaadin (and the fairly simple app I have) it is simple a matter of using the export to war function to save out a war file, drop it into your app server deploy directory, and either do the hot deploy thing or bounce your app server. Pretty simple.

My basic tomcat server runs with no apps deployed using about 189MB of RAM. That’s a default configuration pretty much I think – although there might be some crap in there I’ve forgotten about. Loading up the the test app and playing around shows that memory use goes up 4-5 MB. That’s pretty good – for a simple app with not much going on. This holds up if I squeeze tomcat down to 64MB of RAM – I see about 4MB of memory use by the app and Vaadin framework. You will see more impact on private memory and the working area spikes a bit with a memory constrained system.