How to generate standard bean validators for custom field

Hi

I just discovered that if a field in an editor is custom, CUBA does not generate the standard bean validators (e.g DecimalMax and so on).

This could seem quite logical, but in our case we are enforcing attributes at entity level and we do not want to have a specific validation process for custom fields in screen.

Is there a way to tell CUBA to define the standard bean validators on a custom field ?

Mike

Ok found it : initBeanValidator() in WebAbstractField. But I also found out that this is not exactly my issue.
I wanted to create a custom field which displays a text field with a unit on the right (percentage, days, currency, etc.). It’s a small need, no need to go Vaadin add-on/GWT/Javascript road for that.
So I simply built it through composition as you can see in the code below.


public Component createField(Datasource datasource, String property) { 
    HBoxLayout hBox = componentsFactory.createComponent(HBoxLayout.class); 
    hBox.setSpacing(true); 
    hBox.setWidth("100%"); 
    Field valueField = createValueField(); 
    valueField.setDatasource(datasource, property); 
    for (Field.Validator v : getValidators()) { 
        valueField.addValidator(v); 
    } 
    hBox.add(valueField); 
    hBox.expand(valueField); 
    Label unitLabel = componentsFactory.createComponent(Label.class); 
    unitLabel.setAlignment(Component.Alignment.MIDDLE_CENTER); 
    if (styleName != null) 
        unitLabel.setStyleName(styleName); 
    unitLabel.setValue(unit); 
    hBox.add(unitLabel); 
    return hBox; 
} 

I saw that the valueField by default has the BeanValidator set because it is linked to a dateasource+property, which is great. Problem is that the hbox is the component that is finally integrated in the FieldGroup.
During validation the FieldGroup scans all field Components in order to look for Validatable ones. And HBox is not of course. However it would be nice if the scanning process of the FieldGroup detect field Components that are Containers and scan the composition, as the frame do.
Mike

Hi,

Thank you for the topic, we will discuss it in the team. It seems that we have to provide validation trigger for custom fields of a FieldGroup. It cannot be done in bug fix version and we will try to introduce new behavior in the upcoming Release 6.6.

At the moment, you can trigger validation of a custom field from from a screen postValidate method.


@Override
protected void postValidate(ValidationErrors errors) {
    super.postValidate(errors);

    try {
        textField.validate();
    } catch (ValidationException e) {
        errors.add(textField, e.getDetailsMessage());
    }
}

Thanks Yuriy,

We chose another path, which solves 2 issues at once. We try to have the minimum specific code in our screens, as we have a lot to develop, so the more generic we stay the less code we will have to produce.

The second need we have is to be able to create a new CUBA Component by simple composition of existing ones. It’s more lightweight than creating custom Component from GWT/Javascript/Vaadin add-on.

So we developped a CUBAValidatableContainerWrapper class wrapping a Container, and implementing through delegation Component, Component.Wrapper, Component.Container, Component.Validatable, Component.Editable.

For Component, Wrapper, Container, method calls are delegated to the wrapped Component/Container. For Validatable & Editable, they are applied to the components tree. The validation logic mimicks FieldGroup one.

It works but it’s not perfect in my eyes. For instance I had to use FieldGroup.FieldsValidationException to generate validation errors so that they are processed correctly by ComponentsHelper.fillErrorMessages. More generally this is dependent on CUBA internals, so it may be impacted by further evolution of such internals.

Anyway it will allow me to wait for a way in CUBA to define a custom Component through composition of existing ones, while solving my validation problem.

Mike

:ticket: See the following issue in our bug tracker:

https://youtrack.cuba-platform.com/issue/PL-9289