Demo Adressbook Application Combobox shows wrong citynames
i have a problem with that code. its the sample code of the adressbook application

if i select a row of the personallist the show me the wrong cityname in the combobox of the city row in the formular to testing the app you need to create a database in mysql called “test” in that database execute following sql dump

thanks you help


i think the problem is in line: RowId(new Object[] { newDataSource.getItemProperty("CITYID").getValue() }));

if i select a row with city helsinki he show in the combobox in the personform berlin.


there seems to be an implicit assumption in the code that the city ID’s start at the index 0. This is not very good, you may want to file a ticket about this to the Vaadin trac. In the meantime, you can fix this in your code by either modifying your SQL script to start the ids at 0, or change how the getCityName(int cityId) method in line 220 of works.


MySQL autogenerates keys starting with “1” so I just adjusted the random number generated for reference to the city table to be 1-14 instead of 0-13.

Actually, that solved my combobox problem-- but then I noticed the city names in the table weren’t right. The tutorial code In DatabaseHelper.getCityName() looks like this:

public String getCityName(int cityId) {
    Object cityItemId = cityContainer.getIdByIndex(cityId);
    String cityName = cityContainer.getItem(cityItemId)
    return cityName;

I had to decrement cityId in order to get it to work. But isn’t there a bigger problem? This seems to assume the contents of the CITYID column not only begin at zero but ARE THE SAME AS CONTAINER ITEM INDEXES. Isn’t that assuming a lot? Shouldn’t the city item be found by looking for the matching cityId’s value?

I agree, this is quick and (too) dirty code. However it should work nicely, since the city id is auto increment and does not come from any unique index (i.e. always starts at 0 or 1), and the user has no way to delete cities. So actually the city id should always correspond to the container index. Of course this should not be relied on, and I think the tutorial needs to be fixed also.


The tutorial does seem to do this in the shortest way possible and assuming it is in full control of the database - not how you would do it in a real production application.

You could
create a ticket
to improve the tutorial code.