Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » scout » Server side mapping of validations coming from a backend
Server side mapping of validations coming from a backend [message #1270860] Thu, 13 March 2014 17:15 Go to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 820
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 #1273137 is a reply to message #1270860] Wed, 19 March 2014 15:16 Go to previous messageGo to next message
Bertin Kiekebosch is currently offline Bertin KiekeboschFriend
Messages: 310
Registered: August 2011
Senior Member
Hi Jeremie,

we had some discussion about this topic in the past. See Link http://www.eclipse.org/forums/index.php/mv/msg/274605/776521/#msg_776521.

Does this adress your problem or is it a different one.

Regards Bertin

Re: Server side mapping of validations coming from a backend [message #1277603 is a reply to message #1270860] Wed, 26 March 2014 07:55 Go to previous messageGo to next message
René  Eigenheer is currently offline René EigenheerFriend
Messages: 36
Registered: July 2009
Member
Hi Jeremie,

did you find a solution which fits to your requirements?

Actually I study the same problem Wink

cu
Re: Server side mapping of validations coming from a backend [message #1278468 is a reply to message #1277603] Thu, 27 March 2014 11:25 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 820
Registered: October 2011
Senior Member
We haven't decided yet. I will keep you informed.
Re: Server side mapping of validations coming from a backend [message #1294087 is a reply to message #1278468] Sun, 13 April 2014 06:02 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 820
Registered: October 2011
Senior Member
Hi,

I didn't get any other feedback, so we decided to go with the solution I have sketched here (additional variables on the Form to transfer the information in the FormData, interceptor in importFormData() to set the Field Error Status).

If you are interested I could share some code.

If this pattern (sending field errors from the backend) is often used, it would make sense to include it in the scout framework. We need more feedback than one or two project.

Something I had forgotten in my first implementation:
When you set the error status coming from the server on the fields, you also need to clear them when the user enters a new value. Otherwise the user cannot save the form again.
Re: Server side mapping of validations coming from a backend [message #1361687 is a reply to message #1294087] Sat, 17 May 2014 09:22 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 820
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 #1402195 is a reply to message #1361687] Wed, 16 July 2014 17:13 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 820
Registered: October 2011
Senior Member
The proposed implementation looks like complex, so I thought it could be interesting to share some code on GitHub: scout_serverside_error

Almost all the interesting code is in the package sandbox.client.ui.forms.field:


1] Fields for each type of field.
It is a common practice to have specific Field for your application. In this example I have used "Sdbx" as second prefix (because of the naming convention the first prefix):
* Date field: AbstractSdbxDateField.java
* Integer field: AbstractSdbxIntegerField.java
* Long field: AbstractSdbxLongField.java
* Smart field: AbstractSdbxSmartField.java
* String field: AbstractSdbxStringField.java
* ... I should create an abstract class for each value field type of field I want to use in my application.

The SDK can help here. See: Default Super Classes Preference Page.
Bug 421079 could also help a lot (feel free to vote for this bug or to let a comment if you are interested)


2] other classes
The classes described in 1] rely on the same code:
* SdbxFieldUtility is a utility class for the code shared by the different value field.
* ServerFieldStatus is a special ScoutFieldStatus to markt he Status as comming from the server.
* IValueFieldWithStatus is a common interface for fields being able to handle the ServerFieldStatus


3] Example form
AForm and AService use the described mechanism.

index.php/fa/18564/0/

Setting a Status in the Server is as simple as:
formData.getFirstName().setStatus(new ProcessingStatus(TEXTS.get("WARN_CheckSpelling"), IStatus.WARNING));



I hope this helps you to understand what I have described in the previous post. You can notice that the implementation is much nicer now that in my first post.

Re: Server side mapping of validations coming from a backend [message #1402200 is a reply to message #1402195] Wed, 16 July 2014 17:24 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 820
Registered: October 2011
Senior Member
Tore Van Grembergen wrote on Sun, 13 July 2014 07:55

Given the importance of being able to to server side validation.
Is there any indication when there will be a native approach in Scout to do this ?

(link to the original Forum post)


Well this is a good question.

As you can see, it is not a lot of code. The question of bringing this to Scout RT depends on the interest of the community.

To complete my small proof of concept, there is work to do:

* Find out if the behavior is good for the majority of scout application out there
* Check if the new API makes sense (Naming convention, public methods...)
* Write unit tests to ensure the verify that the behavior works as expected
* Testing
* Documentation

For the moment I know one project that has this requirement. We have implemented it directly in the application. "René Eigenheer" seems also to have interest but for the moment I did not hear anything concrete from him.

Before to include something in Scout RT, we need to be careful and double check if there is common interest. Otherwise we are building something in Scout for a single application.

Maybe there is something between the PoC and the complete integration: provide the feature as extension that can be consumed from any application (something like AbstractIntegerFieldWithServerStatus, AbstractLongFieldWithServerStatus... without the whole example application)

It would be one step direction integration in scout RT.

This could be realized in as part of the services we provide around Eclipse Scout and/or as open Source Project lead by you.


Re: Server side mapping of validations coming from a backend [message #1422206 is a reply to message #1402200] Fri, 12 September 2014 13:44 Go to previous messageGo to next message
Erich Steiger is currently offline Erich SteigerFriend
Messages: 13
Registered: September 2013
Junior Member

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 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 820
Registered: October 2011
Senior Member
Erich Steiger wrote on Fri, 12 September 2014 15: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.


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:44
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.


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.
Re: Server side mapping of validations coming from a backend [message #1429556 is a reply to message #1422245] Tue, 23 September 2014 11:52 Go to previous messageGo to next message
Erich Steiger is currently offline Erich SteigerFriend
Messages: 13
Registered: September 2013
Junior Member

Found out, that Scout is able to do Basic Server Side Validations but it does not work out of the box. It is neccessery to extend the DefaultTransactionDelegate (https://www.eclipse.org/forums/index.php/t/768546/
) and overwrite the following method

  protected void validateInput(IValidationStrategy validationStrategy, Object service, Method op, Object[] args) throws Exception {
    defaultValidateInput(validationStrategy, service, op, args);
  }




Re: Server side mapping of validations coming from a backend [message #1430632 is a reply to message #1422245] Wed, 24 September 2014 15:37 Go to previous message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 820
Registered: October 2011
Senior Member
Jeremie Bresson wrote on Fri, 12 September 2014 16:46
Those validation rules are used server side to ensure that the FormData is valid, before it is processed by the service in the server.


After we discussed it with Erich Steiger, I thought it would be good to explain how it works. See: @InputValidation and validation rules

As Erich told, nothing is activated out of be box.
Previous Topic:Fine grained permissions
Next Topic:Why are the createRow(...) methods not in the ITable interface?
Goto Forum:
  


Current Time: Mon Dec 22 02:19:01 GMT 2014

Powered by FUDForum. Page generated in 0.02726 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software