There is also a thread going on over on the Spring-Rich forums in regards to GUI builders (notably drag-n-drop form designers), and how Spring-Rich approaches the issue. The core message is that while GUI generators may make things easier to start with, and can be a great for quick and dirty prototyping, code maintainability can quickly become an issue. Frameworks, on the other hand, strive to simplify
1e00
—capturing common concerns that can be reused and easily coded by hand. Which is easier---managing 50 forms spit out independently by a GUI generator, or leveraging a form builder API to create decipherable code that can be packaged and reused?
Spring Rich’s form builder API is a layered API, integrated with its data binding framework, allowing for the construction of forms whose fields are automatically bound to backing domain objects.
This builder produces a form for editing a “Customer” object. The fields "name", "title, "company", etc are properties on the backing Custom domain object, in this case, a standard JavaBean (POJO.) The builder leverages a FormComponentFactory that uses metadata to drive default control selection—for example, auto-selecting a text field for you for the “firstName” and “lastName” field but a CombBox for the “state” field. Each field’s label is automatically added for you, pulled from an i18n message source.
In many ways the GUI Builder/Designer debate is very similar to good OO programming principles.