Vaadin Best Practices

Starting to a thread to capture vaadin best practices from the community. Please share any tips or best practices! Hopefully this thread can be a 1 stop shop for newbies and veterans alike. I am too new to this so I don’t have anything to contribute yet. :slight_smile:

Thank you.

To support your idea, here is an older OO pattern:

to create logical UI modules with only data/domain-level API methods and hide all the related UI implementation into this class.

For example in
typically at least one such UI module exists for every entity in your data model:
AddressBook extends CustomComponent
TaskList extends CustomComponent
UserManager extends CustomComponent
, and so on.

In contrast to the typical approach of extending a
directly, this pattern makes it easier to reuse and reorganize your UI. For example consider if you need to move a
to a separate window, tab or change the implementation to
later on.

I looked at CustomComponen documentationt. In several places, the JavaDoc states “this method is not supported by CustomComponenent” – what does that mean ? Does it mean that the method does nothing ? There is no exception declared, which does not mean that none will be thrown (it could be wrapped in a RuntimeException).

If I remember correctly, CustomComponent creates an extra wrapper div in the DOM tree, so for very complex layouts, maybe CustomComponent isn’t the best choice? (Although, premature optimization is the root of all evil)

From the source code of CustomComponent can be seen that these methods throw an UnsupportedOperationException:

public void addComponent(Component c) {
    throw new UnsupportedOperationException();

My comment was a hint to update the JavaDoc so that one does not need to read the source – as the exception is not inherited from the implemented interface.

Small tip from me:
When developing your own client side widgets, put your style sheets and image files into a sub-folder of “public” folder, named after your widgetset. That will help preventing file collisions with other widgets, especially when you like to name your style sheet “styles.css” :wink:

Added to make documentation better…

thanks for the tips. Keep them coming. Glad we got a ticket out of it too. :slight_smile:

My pet peeve is the confusing use of Listeners, especially in views with many buttons.

A view itself should rarely implement a Listener. These should be done by either local anonymous listener instances (if the method body is just one or two lines long), or, preferably, private inner classes.

Having your main view implement “Button.ClickListener”, and handling each button with an endless chain of “else if (event.getButton() == myButton)” will make the code very hard to read and skim. Instead, if you have an inner class by the name “SaveButtonListener”, your IDE will immediately tell you in the overview where you need to update the logic behind the save button.

Any tips on session serialization / deserialisation as well?

eg. How should we go about it? Or should we not do it at all for non-clustered environments?