I have been evaluating Vaadin for my company and have a concern. It seems the model of coding is to make member variables private by default. This makes extending components difficult or impossible because you do not have access to those member variables.
One example is the ComboBox. I tried to extend this to make a ComboBoxCode that would take a database field value, and convert that into a human readable string to show the user. I found that overriding the Commit method would let me do this in a simple manner, but the commit method sets and clears the following member variables from the core class AbstractField:
Next, I looked for getters and setters for them and did not find setters for any of them and did not find getters for most of them. This means that I can not extend the commit for ANY AbstractField class. Since a lot of components extend this, I think this would be a problem when trying to incorporate this framework into an environment that may have some special needs.
My questions are these:
Question1: Is there a reason that these member variables are private and not protected, or at least have getters and setters?
Question2: Would it be possible to make those variables protected so that they can be used by extending classes?
This also leads to my next question. If we adopt Vaadin as our web framework, it would be beneficial to become contributers, so that the work does not have to fall on the existing contributers.
Question3: Would it be acceptable and what would be the process of being added as a contributor to the Vaadin project and what would be the requirements of being a contributor?
AbstractField is indeed one of the problematic cases, and this issue is made worse by the fact that implementing the Field interface correctly is a lot of work.
The
CustomField add-on can help in some cases - it can also be used to wrap a field and perform the conversions. There is probably a new version of it coming soon, or at least some better examples on how to use it.
Another option (in some cases) is to use PropertyFormatter and containers and items that wrap the real property with property formatters, but this is often rather clumsy.
Admittedly many conversions, formatting etc. between containers and UI components are unnecessarily hard with Vaadin 6, and there are plans to improve these in Vaadin 7.
Protected fields are problematic as they eliminate many options for improving the core components in the future without breaking subclasses. In many cases, protected setters and getters or splitting some methods to make extending the classes easier would be preferable, but this needs to be done to some extent on a case-by-case basis.
Expect at least some improvements in Vaadin 7 in key areas such as fields and forms.
While it is possible to become contributors to the project, direct commit access is not given lightly - there are usually many more considerations than what the average developer takes into account when implementing the specific feature he needs, and the core team needs to maintain all the changes and features in the core.
Defect and enhancement
tickets with high-quality patches are appreciated, and writing such is the best way to demonstrate your potential to contribute to core. The patches should follow our
coding conventions .
In addition, anybody can publish extensions as add-ons in the
Directory outside the core.