ValuesManager server/client validation issue

[mpretorian]

Using smartgwtpower-3.1p.2013-03-18, Firefox 19.0.2, Windows 7 64b.

Please see attached the modified FormValidationSample.java example.
I need to use a datasource bound form with several form items that has also a canvas item that contains as its canvas a nested form with two form items. All items are defined in a datasource.
This construction is meant to display the canvas item as one field with two subfields in one column (or 2 columns if the title is counted).
name1: [_________]
name2: [_________]
name3: [___] [____]
name4: [_________]
1) Is the usage of CanvasItem/nested form the right approach for such use case?
2) While using this approach I encountered a problem with the values manager validation.
In case a validation error exists for the one of the nested fields (name3_1 or name3_2) I need to display the error icon/message for the name3 field.
For that I overrode the showErrors of the nested DynamicForm. That is called when client validation is executed, but not when the server validation returns errors.
2.1) On client validation, although the showErrors is executed, still the error set manually is not shown on the canvas item. Do you see why? I succeeded in my project to see that but not in this shwocase.
2.2) Why the showErrors is not executed when the server validation returns errors?

Regards,
Mihnea

[Isomorphic]

When you add the forms embedded in the CanvasItems to the ValuesManager, at that point error display will be automatic, with no need to override showErrors().

However, you are adding the forms to the ValuesManager *before* you've called setDataSource() or setFields(). This is too early; the ValuesManager doesn't know what to do with a form that doesn't even have the same DataSource, and as far as the setFields() call, it doesn't know what part of the overall DataSource fields your forms are intended to be managing.

[mpretorian]

Hi,

I set the values manager after datasource and fields on each form. No difference. I think it doesn't matter the order, but I didn't check the smartclient code.
I overrode the showErrors method to re-route the errors on the subfields (itemName,SKU) to the canvas item field (compositeFieldName). I don't want to get two error icons, one on each subfield, but only one on the canvas item field. See previous 2).
In the attached file I managed to do that but only for client validation. For server validation it doesn't work because the overridden showErrors method is not called at all.
1) Is it a bug, or is meant to be like that, or can be done differently?
2) Besides that in the previous post I had 3 questions. Could you please answer to all of them? I'm trying to get more answers at once to move faster with this issue. Otherwise we talk few days until we clarify the issue.

Thanks,
Mihnea

[mpretorian]

Any news on this issue? I posted a question 5 days ago, but I've got no answer anymore.

[Isomorphic]

We have a developer looking into this issue. We'll follow up soon

Regards
Isomorphic Software

[Isomorphic]

Responses to ValuesManager questions:


Hi Mihnea,
To respond to your questions:

1) Is the usage of CanvasItem/nested form the right approach for such use case?

This depends on exactly what your usage is. If all you're trying to do is to modify the layout of the form such that two items from the dataSource (in this case "SKU" and "Item") appear on the same row, with a single title to the left, there's no need to go down this route.
You could simply achieve the desired appearance by
- modifying the "numCols" of the form (to 3, say), and
- setting "colSpan" to 2 on each of the items
- ... except the itemName and SKU items which would span only one column
- have showTitle set to false for the SKU item so you see the title for itemName (which you could customize) at the start of the row, but don't have a title (or title cell) for SKU
- modify colWidths explicitly for more control over item and title sizing.

This won't be appropriate for every usage / every appearance however - so you could indeed break the items up into separate forms and use a ValuesManager to combine their values for saving. In this case you could use a CanvasItem to manage the layout, or you could simply
use nested layouts, etc.

So in short - what you are doing should be ok, though there may be other ways to achieve this.

2) While using this approach I encountered a problem with the values manager validation.
In case a validation error exists for the one of the nested fields (name3_1 or name3_2) I need to display the error icon/message for the name3 field.
For that I overrode the showErrors of the nested DynamicForm. That is called when client validation is executed, but not when the server validation returns errors.

2.1) On client validation, although the showErrors is executed, still the error set manually is not shown on the canvas item. Do you see why? I succeeded in my project to see that but not in this shwocase.

2.2) Why the showErrors is not executed when the server validation returns errors?

We don't see the problem with 2.1 on your latest sample. Let us know if this one specifically is still causing you trouble.

On 2.2: this is slightly tricky. The problem is that the valuesManager logic to show errors from a failed server-side save like this doesn't automatically run through the "showErrors" override at the form level.
We will review this area and see if there's a neater way to handle this, but even if we decide to change things, it's likely not a change we'd be making for the 3.1 branch.

However - you could handle this yourself. The easiest solution would be to modify your saveData() call to pass in a custom callback, and a requestProperties block with "willHandleError" set to true.
In the callback you can then check for the reported status being < 0 [indicates some kind of error occurred], and specifically for RPCResponse.STATUS_VALIDATION_ERROR.
In this case you can use DSResponse.getErrors() to extract the errors, modify them as appropriate, and apply them directly to the ValuesManager or member forms via setErrors().

[mpretorian]

Is anything done to solve 2.2 in the framework, especially in 3.1p, or I have to handle the server error manually like you proposed?

[Isomorphic]

You should handle it manually with the suggested approach.

[mpretorian]

While reading smartgwt documentation about validation I had the impression that you want to support the same handling of client and server validations.
Now I see that in some cases the handling is different and I cannot just change a validation from server to client or vice-versa and expect the same the same behavior.

Could you please describe the main differences between client and server validations and handling of errors?

Thanks,
Mihnea

[Isomorphic]

We're not sure where you perceived a client vs server difference, you'll need to be more specific.

There are of course "serverCustom" validators that execute only on the server side, but we're assuming this is not what you're referring to.

[mpretorian]

See point 2 from my first post. There I explained what is the difference between client and server validation error handling: showErrors is not executed when the server validation returns errors.

[Isomorphic]

This difference is the result of an implementation quirk. Client side validation validates each form in the ValuesManager directly which runs the "showErrors()" method on each form (where errors are encountered) explicitly.
When validation fails due to server errors, the errors are displayed via an API call on the ValuesManager as a whole, which simply redraws the forms without explicitly running through the showErrors() API.

After some consideration we're acknowledging this to be basically a bug - you'd expect the Form level showErrors method to be invoked for each form in either case.

We'll be fixing this on the 4.0p / 4.1d branch going forward (fix will likely hit nightly builds in a couple of days). We do not plan to backport this change to 3.1p. You should be able to use the approach described in this thread to get the behavior you need on 3.1p

Regards
Isomorphic Software