what I like about the Wicket framework, was the following:
I coult add a component to the UI and override mehods like “isVisible” to control the beavior of the component dependend on the model object and thus encapsulate the visibility logic inside the component. In vaadin it seems as if I can only the component from “outside” using methods like “setVisible” and as a result the design of the application is not es good as it should be. What other alternatives do I have to achieve a better design?
That sort of use is indeed not possible with Vaadin, because Vaadin doesn’t update the entire page in a HTML response, but makes minimal changes with AJAX responses. Calling a setter not only sets a property, but also triggers serialization of the change to the client-side.
I’m not so familiar with Wicket, but I’ve understood that its processing model is mainly that of a traditional non-AJAX web framework, where the entire page is (re-)generated on each submit, and the page generation can call all the property getters. This is a completely different processing model from Vaadin.
With Vaadin, you are always recommended to modularize and encapsulate different parts of the view as tight and neat as you can, either with CustomComponent composites (which provides better encapsulation) or by extending layout components or other components (see
component composition in the book). Especially the FieldGroup form data binding and declarative designs support this form of encapsulation, through binding by member variables.
Many Vaadin users like to encapsulate logic and initialization in single-use inner classes, or even in anonymous classes. However, there’s
some differences of opinion about their use in Java.