Dieter Krachtus' Weblog *** pro bono lateral thinking

As much as possible, Metawidget does this without introducing new technologies. It inspects, at runtime, an application's existing back-end architecture (such as JavaBeans, annotations, XML configuration files) and creates components native to its existing front-end framework (such as Swing, Java Server Faces, Struts or Android).

Recently I had some discussions with the father of MetaWidgets (Richard Kennard). One questions I raised was later answered in his blog which you should read first to understand what follows. Before I pushed the send button in my mail client I decided to post my reply here:

 1. Separation of Concerns:

I still think the solution I gave is better in most cases and I give my reasons:

 2. Duplication of Declaration

One complain against the suggested metawidget.setFields("firstname","lastname","dateOfBirth"); is that it introduces duplication by using hardcoded strings named after the Bean's fields...but so is the MetaWidget AddressBook example by effectively restating that the domain has a firstname field by using the getValue(...) method:

mContactSearch.setFirstnames( (String) metawidgetSearch.getValue( "firstnames" ) );
mContactSearch.setSurname( (String) metawidgetSearch.getValue( "surname" ) );
String type = (String) metawidgetSearch.getValue( "type" );

To resolve this dilemma I suggested to define String-constants in your beans for some of its fields, and refer to them throughout your code: in bean annotations, the infamous metawidget methods setField(...) and getValue(...), etc.:

public class BusinessBean
public static final String FIELD_FIRSTNAME = "firstname"; // String constant
private String firstname;
@NamedField(name=BusinessBean.FIELD_FIRSTNAME)  // used to *name* the field/getter
@UiComesAfter(BusinessBean.FIELD_TITLE)
public String getFirstname() {return firstname;}

this way the original name of the field/getter is fully ignored and the new name is used whenever one calls a metawidget-method from the view:

instead of metawidgetSearch.getValue("firstname"), one writes:
metawidgetSearch.getValue(BusinessBean.FIELD_FIRSTNAME)
and instead of metawidget.setFields("firstname","lastname","dateOfBirth"), one writes:
metawidget.setFields(BusinessBean.FIELD_FIRSTNAME, BusinessBean.FIELD_LASTNAME, BusinessBean.FIELD_DATEOFBIRTH)

The String constants are used everywhere - in the Domains' annotations, metawidget method calls and possibly resource bundles. In my opinion this improves separation of concerns and clarity, reduces duplication of declaration and error-prone design. Even refactoring of your bean or GUI is now much more easily done now. I acknowledge that some people do not want to change their Beans by adding String constants (since I questioned the additions of @UiComesAfter, @UIHide myself). Still, I see the String-constants and the @NamedField annotation and the setFields(...) method only as an advantageous option for cases with specific concerns such as flexibility. I agree, the default behaviour of MetaWidget should be as it is now. You just take your Beans, modify it with @UiComesAfter, @UIHide and duplicate field names in error-prone getValue(...) method calls as long as one has the option to do otherwise.

3. Not just Java

With the exception of HibernateInspector which is usually already there I am no fan of writing additional XML as a way to define component sequence. It seems I have at least one supporter: (Richard's Interview at Javalobby.com):

"I remember the first releases of JPA were coming out. I thought being able to annotate your domain objects instead of writing XML mapping files was awesome - it had this real spirit of 'Don't Repeat Yourself'. We'd gone from having to manage duplicate field declarations in 3 places (your database schema, SQL statements, domain objects) to just 2 places (your domain objects and an XML mapping file) to just 1 place (an annotated domain object). I thought that was great."

Sometimes your own words fall back on you like blood-hounds on their master ;)