`madura-vaadin` ties together the back-end Madura projects ([Madura Objects](https://github.com/RogerParkinson/madura-objects-parent) and [Madura Rules](https://github.com/RogerParkinson/madura-objects-parent/tree/master/madura-rules) , and delivers them with a Vaadin UI . So it is worth taking a brief moment to review what those back-ends do: * Madura Objects builds your domain objects as annotated POJOs from an XSD file (using JAXB). The resulting objects behave just like POJOs except, when configured with the Madura Objects validation engine, they self validate as well as maintaining field metadata such as choice lists, permissions, locale-sensitive labels etc. * Madura Rules plugs into the Madura Objects validation engine to support a rules/constraints based environment that does cross-field validation as well as deriving new values (eg total of the invoice lines on this invoice). It does 'truth maintenance' which means when the data changes rules might be 'unfired', keeping the derived data always 'true'. The rules can also operate on metadata which means they can change the list of valid choices on a choice field, make a field visible or read-only etc. This project wraps those tools to make them easy to use in a Vaadin application. The result delivers highly dynamic applications with very little application code. For example: * All field captions are fetched from the relevant XSD label and translated to the current locale. * All validations on all fields are handled automatically eg range checks, regex checks etc, but it also means rules based validation if you have configured it. The application code is unaware any validation is active. * Error handling and delivery of any messages is synced with Vaadin's error message delivery and messages are locale translated. * Fields annotated with a permission have that enforced (field not rendered or disabled). * Fields marked Secret are rendered as Password style fields. * Default values, if specified in the XSD, will be loaded in the obvious way. * Required fields are indicated as such using Vaadin defaults and submit button automatically disabled until they are entered. * No restrictions on what Vaadin widgets can be used. In addition, if you have configured a rules plugin, such as Madura Rules, into your validation engine: * The validation can include cross field validation. * Choice lists dynamically change as the available choices change. * Fields may change to/from read-only or invisible or required as rules fire. * Buttons may be enabled/disabled by rules. The API is very minimal and applications rely on Spring's @Component to keep configuration simple. It also supports Touchkit for mobile applications.