| Server side mapping of validations coming from a backend [message #1270860] |
Thu, 13 March 2014 17:15  |
 Jeremie Bresson
Messages: 1252
Registered: October 2011 |
Senior Member |
|
|
Have you validations data that comes from an external Backend?
Most of the Eclipse Scout applications I know follow this paradigm:
1. Validation rules are encoded in the client
... a. With the field properties (for example min and max value properties on number fields. Depending of the definition of validation rules you take, you can also consider "master required" as a property that controls user inputs)
... b. With custom logic (using execValidateValue, or with even more custom logic that can be triggered everywhere [execChangedValue, execValidate, ...])
2. Only valid values are sent to the server and persisted in a database
What now if the validation logic is in an external backend?
You map the data contained in your formData into another layer (dto, tc, ...) and the backend provides some validation informations that you should display in the client.
In my opinion there is no solution already included in the scout framework to do this (because of the client-side validation paradigm).
What I tried for the moment is to include in the formData (server-side) is a couple: "field id" as String (corresponding to the FormFieldData) + "ProcessingStatus" (a message + an error level). Client side, after importFormData(..) for each defined couple, I set the ProcessingStatus on the corresponding field.
It would be much easier if the AbstractFormFieldData had a ProcessingStatus member.
Would other projects be interested in such a possibility? Or is it a bad idea? Why?
Another of my concern is:
Is it better to return a formData with the validation information or a typed exception containing the same information?
Side note:
Getting the correct "field id" for the FormFieldData is not trivial (AbstractFormFieldData#getFieldId() is not a good idea (it does not work with templates). You need to calculate the allFieldsRec map of the formData and search the field id corresponding to the FormFieldData in this map). This way you can in the client find your field exactly as the importFormData(..) does: with a FindFieldByFormDataIdVisitor.
If you have an opinion, I would appreciate feedback...
|
|
|
|
|
|
|
| Re: Server side mapping of validations coming from a backend [message #1361687 is a reply to message #1294087] |
Sat, 17 May 2014 09:22  |
Jeremie Bresson
Messages: 1252
Registered: October 2011 |
Senior Member |
|
|
Update:
I got an idea how this can be solved in a nicer way.
Instead of storing the field messages in a map (as I described before), if you have a template definition for each value field (1) used in your application, you can do this:
You define a new AbstractValueFieldData that will hold the processing status you want to transfert from the server to the client:
import org.eclipse.scout.commons.exception.IProcessingStatus;
import org.eclipse.scout.rt.shared.data.form.fields.AbstractValueFieldData;
public abstract class AbstractValueFieldDataWithStatus<T> extends AbstractValueFieldData<T> {
private static final long serialVersionUID = 1L;
private IProcessingStatus status;
public IProcessingStatus getStatus() {
return status;
}
public void setStatus(IProcessingStatus status) {
this.status = status;
}
}
On top of each of your application-specific ValueField templates you add:
@FormData(value = AbstractValueFieldDataWithStatus.class, defaultSubtypeSdkCommand = DefaultSubtypeSdkCommand.CREATE, sdkCommand = SdkCommand.USE)
public abstract class AbstractMyAppStringField extends AbstractStringField {
//... generic configuration relevant for all string fields of the MyApp application
}
After this you can set the processing status on each field-data, exactly as you would set the value:
formData.getName().setValue("Test");
formData.getName().setStatus(new ProcessingStatus("This is an error Message", IStatus.ERROR));
(1) With template for each value field I mean, you do not use AbstractXxxxField defined in Scout, but you use a specific class for your application instead:
- Not AbtstractStringField but AbstractMyAppStringField.
- Not AbstractIntegerField but AbstractMyAppIntegerField
- ...
In my opinion this solution is better than having to define a map on the form.
If someone is interested, I can share some code.
|
|
|
|
|
| Re: Server side mapping of validations coming from a backend [message #1422206 is a reply to message #1402200] |
Fri, 12 September 2014 13:44 |
|
|
I prefere to have the Field-Status in Scout standard. It makes absolutly sense for me to put this information next to the value. By the way it would also be nice to have validating information like getConfiguredMandatory, getConfiguredMaxValue, getConfiguredMinValue and so on also on the FormData instead on the Form itself. This makes it easy to make sure, that basic validations are done not only on the UI but also on the server side and that the same validations will take place.
|
|
|
| Re: Server side mapping of validations coming from a backend [message #1422245 is a reply to message #1422206] |
Fri, 12 September 2014 14:46 |
Jeremie Bresson
Messages: 1252
Registered: October 2011 |
Senior Member |
|
|
Erich Steiger wrote on Fri, 12 September 2014 15:44I prefere to have the Field-Status in Scout standard. It makes absolutly sense for me to put this information next to the value.
The approach I am describing (with AbstractValueFieldDataWithStatus) is really near to what a solution at framework level could be.
If you have a common abstract class for field and abstract classes for your fields this isn't a big deal at all to add it the way I described it.
We could integrate this in the scout standard, but in order to do so, multiple projects should show interest for the feature. As far as I know it isn't the case for the moment.
Erich Steiger wrote on Fri, 12 September 2014 15:44By the way it would also be nice to have validating information like getConfiguredMandatory, getConfiguredMaxValue, getConfiguredMinValue and so on also on the FormData instead on the Form itself. This makes it easy to make sure, that basic validations are done not only on the UI but also on the server side and that the same validations will take place.
This is already the case. All the getConfigured properties relevant for validation are replicated in the FormData, in a map of ValidationRules.
Example:
public static class MyString extends AbstractValueFieldData<String> {
private static final long serialVersionUID = 1L;
public MyString() {
}
/**
* list of derived validation rules.
*/
@Override
protected void initValidationRules(Map<String, Object> ruleMap) {
super.initValidationRules(ruleMap);
ruleMap.put(ValidationRule.MANDATORY, true);
ruleMap.put(ValidationRule.MAX_LENGTH, 100);
}
}
In this example MyStringField has the properties:
* getConfiguredMandatory() {return true;}
* getConfiguredMaxLength() {return 100;}
Those validation rules are used server side to ensure that the FormData is valid, before it is processed by the service in the server.
Some inputs on validation rules in the forum.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03387 seconds
] 
Search
Help
Register
Login
Home
