Let’s say I get a declarative design for a UI from some third party, maybe outputed from designer. Let’s say that for whatever reason the field names they use, such as “customerOrder”, does not match my data element, such as “order” or “Order” ( from XML and JAXB, where tag starts with capital letter ). If I were defining the view myself, I would do something like this:
@PropertyId( "Order" )
private TextField customerOrder = new TextField();
But with UI defined via a declarative design from designer, I cannot do that as easily, unless I break the rules set by designer and update the Java file provided by designer directly. Obviously, since a third party is providing this, I can get away with doing this in my case ( I can easily merge future changes with my copy ). That said, this seems wrong. Is there an easy way to specify the propery id in the derived class instead?
One way that occured to me was to do the following:
fieldGroup = new BeanFieldGroup<FacilityType>(FacilityType.class);
fieldGroup.bind(customerOrder, "Order" );
// Later in code, in a setter or binder method
fieldGroup.setBuffered(false);
fieldGroup.setItemDataSource(site);
fieldGroup.bindMemberFields(this);I did not like that because I normally just use BeanFieldGroup.bindFieldsUnbuffered, which does some of the steps above “under the hood” and does not require me to keep the field group around ( I do keep it around because i need it for validation, but I do not always need it for validation ). Just hoping I am missing a better way of setting the “property id” for a field from a declaratively defined UI.