Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
PropertyId and declarative design from Designer
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.
I guess there's no way around the fact that you can't modify the generated Java file and thus can't add those annotations.
Maybe you should just make a helper class which does the calling of fieldGroup.bind() and saves you from some repetitive coding.
To bad. I was sort of hoping there was a way to set a property id at the "field" level, I guess.
So long as you do it correctly, doing it in the sub-class of the Designer Java produced class, like I originally did, it would probably work. I think just abstracting/mimicing "bindFieldsUnbuffered" would work, in which I could set the property ids BEFORE calling the bindMembers method.
I just heard that this @PropertyId annotation support is finally coming to Designer in version 2.1. Alpha version is already available.