BeanItem - Boolean getter convention

Hi all!
Im using a Form with a BeanItem as ItemDataSource. The Pojo of the Item have some Boolean values like:

private Boolean adminUser;

public Boolean isAdminUser() {}

public void setAdminUser(Boolean admin) {}

But, the form shows the property as ReadOnly. I can only write the property, if I create a getAdminUser() method on the Pojo. This is the correct Behavior?

Many thanks by atention!

I’m not 100% sure that I remember correctly but I would say that if the type is Boolean the getter should be “getField” and only if the type is boolean (the primitive) the getter should be “isField”.

Yes… Ive read in some blogs about this convention, but in true, I dont know why.
Anyone concern that theres no pratical difference between a boolean and Boolean? I know they are different in a lower level, but, in pratical terms, I belive that the conventions for access both types must be the same, as they represent the same type of data.

In this case, I will need to change my persistence layer, to include the getFields for this types :frowning:

I’ve made tests, changing the datatypes to boolean instead Boolean, and using only the the getter with “is” prefix.

It works nice, but I want to use the Wrapper type, because its a domain object, and some of them can be null sometimes in database.

Any changes for Vaadin accept the “is” convention for Boolean? :grin:

You can use “public Boolean getValue()” in a bean to have a Boolean object type for the property, but then the object value must not be null.

If you really want to allow null values for the properties, you must override the setInternalValue() in the CheckBox and handle the null value somehow.

For example:

        protected void setInternalValue(Object newValue) {
            // Allows null values for Boolean properties
            if (newValue == null)
                newValue = false; // Handle it somehow


Hi Marko! Many thanks by your help.

Im my model, I dont have boolean fields that can be null. I dont like to use this behavior on my database rules. So, in this case, I can use the boolean primitive without problems, and now, is working fine with the "is"Property(), as it is the Bean spec.

But, many thanks by your tip. It haves many uses. Thanks to Vaadin modular design. :slight_smile:

I would argue there needs to be some sort of workaround for the public Boolean IsProperty() problem. It’s a mistake to assume that Vaadin UI developers have control over the method signature of the accessors and can freely add a public Bolean getProperty() method. In our case, we are hooking a Vaadin UI up to a WebService back-end. The java beans in the Vaadin container are generated from WSDL; and the conversion engine we are using generates an IsProperty() method for Boolean types. Because Vaadin expects the accessor to be:

public Boolean getProperty();

instead of

public Boolean isProperty();

the property is not found; for instance, in calls to table.setVisibleColumns.

It would be nice to have Vaadin check for the property of BOTH accessors; for both booleans and Booleans, and use whichever one is available…

Internally, the Vaadin class MethodProperty (used by BeanItem) would support such isXyz() accessors with Boolean as the return type.

However, the list of properties for a BeanItem and their accessors is obtained using java.beans.Introspector, which follows the JavaBeans specification and does not accept isXyz() accessors for any return type other than boolean.class. In fact, the specification is a little vague on this point (talking about “boolean properties” without mentioning either “Boolean” or “primitive” as far as I remember), but I would argue Introspector would be “correct” as the reference implementation.

If you really need to customize BeanItem properties, you could have your own subclass of BeanItem (with modified versions of getPropertyDescriptors() and getBeanPropertyDescriptor()) and use those from your custom BeanItem constructor. Then, in a subclass of [Abstract]
Container, in the constructor, remove all properties and then add your custom ones, and override createBeanItem().

This is a bit of a hack but probably should work.