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.
To support your idea, here is an older OO pattern:
Extend
CustomComponent 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
CRUDs 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
VerticalLayout or
Window directly, this pattern makes it easier to reuse and reorganize your UI. For example consider if you need to move a
UserManager to a separate window, tab or change the implementation to
AbsoluteLayout 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)
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”
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.