12.0p improvement suggestion: Run serverside validators also on empty values in order to provide default values via validationContext.setResultingValue()

[Blama]

Hi Isomorphic,

I tried to implement a default value strategy using ValidationContext.setResultingValue().
This does not work, as my validator is not run for empty values. An attribute runForEmptyValue in .ds.xml-validator in order to enable this would be great.

Just to be sure:
There is no built-in way to define default values in .ds.xml, correct? Meaning something that would run before required="true"- and other validation and therefore pass these.
If so, this would be a nice addition as well, something like VelocityExpression defaultValue on ds.xml-DataSourceField.

What do you think of these two?

Best regards
Blama

[Isomorphic]

If you want to *suggest* a default value to the user, we would suggest that you do it via formItem.defaultValue, which is designed for this purpose, and executes on the client, avoiding a server trip.

You can also *force* values via <values> on an OperationBinding (DSRequestModifiers), or via DMI.

[Blama]

Hi Isomorphic,

We had the formItem-approach before, but then you have many problems:

• The dynamicForm (in a Tab of a lazy-load TabSet) must be loaded
• if loaded, also something must be changed, as the DynamicForm.valuesHaveChanged() does not recognize the change away from null to the default value.

I'm doing this in DMI which seems kinda correct. My problem is with required="true" fields - Here a DMI is too late to provide a default. validation runs and fails before. Therefore I had two ideas:

1. Have serverCustom validation optionally also run on null-values, then provide default via setResultingValue(), if needed.
2. Have a Velocity expression provide a default. Order then is
   1. Request
   2. Velocity to (perhaps) change null-fields to value
   3. Validation

As I don't have this now I add values in DMI and do validation in an SQLDataSource-subclass overridden validateRecord() method, knowing that the value will be later added in DMI if not already present. This is necessary as for empty values you don't run normal .ds.xml-validators.

Any other suggestion is highly welcome.

Best regards
Blama

[Isomorphic]

This isn't making much sense to us.. you seem to be hyper-focusing on validator.setResultingValue() when there are so many other and better ways to handle this.

First of all, the form is going to need to render before you can save, presumably, so the default value will indeed kick in. Even if this were somehow a problem, you could just inject a dynamic default value anywhere in your client-side save flow - there are lots of spots, like the click handler on the same button, or even including DataSource.transformRequest() if nothing else works.

If the field is not really required *for user input*, then don't declare it as required (because that's what required means..). Then you don't have a problem implementing either a validator or a DMI to inject a value even if you want to solve it this way, instead of the seemingly more obvious client-side way of handling this.

Note finally that DSRequestModifiers run before validation, so that injection point works even if you decline to handle this on the client side.

[Blama]

Hi Isomorphic,

I don't think that required fields with default values are such an uncommon thing. It's certainly not for us.
Yes, other client side approaches would also work. But IMHO what you are suggesting for client side (ClickHandler or RequestTransformer) are workarounds. And the presence of a defaultValue not triggering valuesHaveChanged() is strange.

Anyway I'd much more like to solve it serverside because it solved then two use cases at once. DSRequestModifiers have the problem of being a declarative security feature (and are therefore not present for servlet triggered mailimport or RESTHandler). This is also something I and others already suggested (e.g. here).
Having DSRequestModifiers configurable for client-only or client+server requests would be really great. This would also solve my default value use case and would invalidate the need for an attribute.
The attribute-solution has the advantage of being slightly more declarative, but DSRequestModifiers would be very fine (and actually because of all the other good things they bring, I'd like that solution even more!).

Best regards
Blama

[Isomorphic]

DSRequestModifiers and other declarative security rules apply to RestHandler and to any request marked as a client request.

Required fields with default values aren't uncommon, and are well-handled by the framework; we have described multiple approaches, all of which are simple. The idea of handling them via having validators optionally run on null values is what we would consider a very odd workaround, where none is needed.

[Blama]

Hi Isomorphic,

thanks. I got it working now my way.
DSRequestModifiers + BaseRequest.isClientRequest() might be a good solution as well. But DSRequestModifier docs should really mention that this is a declarative security feature that only applies to client requests and how to enable it for server started requests as well if wanted and what (if any) the side effects are.

Other than that, perhaps there are some minor wishlist features here in this thread for you as well.

• Client side treating forms with defaultValues as changed
• .ds.xml field attribute defaultValue (VelocityExpression)
• Run validators optionally run on null values

Thank you & Best regards
Blama

[Isomorphic]

We'll update the DSRequestModifier docs to make that explicit.

On your suggestions:

1. programmatic changes in general are not reported as user changes

2. this would be redundant with dsRequestModifiers

3. this seems like an extremely roundabout way to solve a problem that is already well handled, and we think it's extremely unlikely that anyone else would ever discover or use the feature if it were present, so we won't be doing this

[Isomorphic]

We've updated the DSRequestModifier docs and you will see them as of tomorrow's builds (May 08).

Regards
Isomorphic Software

[Blama]

Hi Isomorphic,

thanks, I can see the changes.

Best regards
Blama