Package com.storedobject.vaadin

Class ObjectForm<D>

java.lang.Object
com.vaadin.flow.component.Component
com.vaadin.flow.component.Composite<com.vaadin.flow.component.Component>
com.storedobject.vaadin.AbstractForm<D>
com.storedobject.vaadin.ObjectForm<D>
Type Parameters:
D - Type of object to be edited
All Implemented Interfaces:
com.vaadin.flow.component.AttachNotifier, com.vaadin.flow.component.DetachNotifier, com.vaadin.flow.component.HasElement, com.vaadin.flow.component.HasStyle, Serializable
Direct Known Subclasses:
AbstractDataEditor.DForm
public class ObjectForm<D> extends AbstractForm<D>
Class to represent a "data entry form" for a particular type of object.

Form (see AbstractForm) contains "fields" (HasValue) and each field has a name. By default, "field names" are automatically determined from the attributes of the object under editing via reflection. So, getXXX (for example, getFirstName()) methods are used to determine the field names and its value types.

Field values can be loaded from the object instance that is being edited and edited values can be committed to the object instance. By default, getXXX/setXXX methods of the object class are used for this. However, a particular getXXX or setXXX method can be overridden by defining a method with the same name in the form itself. Yet another facility is to define some of those methods in some other class and set an instance of that class in the form using setMethodHandlerHost(Object). However, the signatures of the getXXX/setXXX methods that are overridden like this take the object instance as an additional parameter as its first parameter. For example, let's assume that our object class represents a "Person" and we want to override the "DateOfBirth" field's "set" method. In the Person class, we may be having the getDateOfBirth() method that returns "date of birth" and setDateOfBirth(Date) to set the "date of birth". So, the overridden "set" method in the form should have signatures as follows: setDateOfBirth(Person, Date). If we want to override the "get" method, it should look like getDateOfBirth(Person).

The order of precedence when it has to determine get/set methods - First preference is given to the available methods in the form, then the available methods in the "method handler host" (if ones is set) and finally, in the object class itself. If it can't determine the "set" method for a field, the field will be set as "read only".

If a getXXX method of the "host" should not be treated like this, it can be annotated with NoField.

What is the purpose of overriding get/set methods? One can implement extra logic such as value conversion, validation etc. before getting/setting the values from/to the object instance. (It is better to add validators if that is the only purpose - see AbstractForm.addValidator(HasValue, Function), AbstractForm.addValidator(HasValue, Function, String)). When extra fields (see next paragraph) need to be added, this mechanism is anyway required.

Any number of extra fields can be added using addField(String...), addField(Iterable), addField(String, Method, Method), addField(String, Method), addField(String, Function, BiConsumer), addField(String, Function), AbstractForm.addField(String, HasValue), AbstractForm.addField(HasValue). When you add additional fields, depending on the method you use, it can determine how to get/set values. If not enough information is provided as parameters (for example, methods addField(String...)), reflection is used to determine it as mentioned in the previous paragraphs.

An "object form" is not used directly in most cases. Instead, a View derived from AbstractDataEditor or DataEditor is used where an "object form" is already embedded. All overridable methods in the form can be defined in these "views" too.

Author:
Syam
See Also: