Validators for values in GUI

[tomas-knap]

Currently, when inserting too long name for the pipeline, e.g., an error occurs when trying to insert to db. But the value should be validated earlier.

Solution: Add Vaadin validator, which checks the length of certain text fields, using the same LengthLimits from commons-app, but the lenght limit is applied during validation in Vaadin. If the validation succeeds, the data is stored to db.

Apply to all fields in GUI (~10-20), which have restricted length in db.

Suggestion: custom TextArea s limit length?
Use LengthLimits class to hold all the limits. It is sufficient now, it is not needed to be able to specify the limits in a config file.

[ghost]

dpu_instance.tool_tip (512) - i think this is never used, should be removed from the code base
dpu_template.jar_directory(255) - see #1242 should be resolved there
dpu_template.jar_name(255) - same as above
exec_dataunit_info.name(2048) - i was unable to figure where any of the values in this field come from
exec_context_pipeline.directory(255) - does not seem to be JPA mapped
exec_schedule.name(1024) - is JPA mapped, but does not seem to be used anywhere
ppl_edge.data_unit_name(2048) - unsure what to do in this case. is it possible to use abbr. value for this? inst it used for something else anywhere? or should we replace the data type varchar with text?
sch_email.e_user(85) - see #1245 should be solved there
sch_email.e_domain(45) - same as above
usr_user.u_password(132) - does not need the checks - it is always a password hash

[ghost]

Tested, needs review of problematic fields - listed above. What to do with the, are they unused or ?

[tomas-knap]

Michale, the code seems to be ok.

Regarding
ppl_edge.data_unit_name(2048), I think that it cannot be specified directly, but it is build based on the label of the output and input of the next DPU

[tomas-knap]

When we merge your feature request, there is a TODO for us to go through the problems you have discovered and solve them.

[ghost]

Hi, well, I have created separate issue for each problematic field I mention in my comment. Just not to lose the track of what we do with each of them.
Updated list is:
dpu_instance.tool_tip (512) - remove, see #1253
dpu_template.jar_directory(255) - rework, see #1242 should be resolved there
dpu_template.jar_name(255) - rework, see #1242 should be resolved there
exec_dataunit_info.name(2048) - question, see #1273
exec_context_pipeline.directory(255) - question, see #1274
exec_schedule.name(1024) - remove, see #1255
ppl_edge.data_unit_name(2048) - question, see #1275
sch_email.e_user(85) - rework, see #1245 should be solved there
sch_email.e_domain(45) - rework, see #1245 should be solved there
usr_user.u_password(132) - does not need the checks - it is always a password hash

[ghost]

Resolved in #1263