DMI validation issue

[ramis]

SmartClient Version: SC_SNAPSHOT-2011-02-19/PowerEdition Deployment (built 2011-02-19)
Browser: Firefox 3.5.3

I have setup a relatively simple DMI validator on a ListGridField and I'm experiencing an issue that I'm hoping I can get some help with.

After entering data and exiting the ListGridField or the ListGrid row for the first time, the DMI validates and flags any errors successfully.

If I now go back into the same field and exit, the DMI validator does not fire and the flagged error is dropped upon exiting the field regardless of whether the field value was changed.

The next time I go into the field, and exit, the DMI validator is called and any errors are flagged.

This pattern of alternating calls to the validator continues, and is the issue I'm experiencing.

Here is the code I am using. Any thoughts on why this is happening would be greatly appreciated.

Field Definition

<field name="packCompItemNumber" title="Component Item Number" type="text"  width="180" primaryKey="true" canEdit="true" customSQL="true">
     <validators>  
          <validator type="serverCustom">  
               <serverObject lookupStyle="new" className="com.islandpacific.gui.server.customDataSource.PackComponentValidator"/>  
               <errorMessage>$ErrorMessage</errorMessage>  
          </validator>  
     </validators>  
</field>

ListGridField Definition

FormItem componentItemNumberTemplate = new FormItem();
componentItemNumberTemplate.setValidateOnExit(true);

ListGridField componentItemNumber = new ListGridField(PACK_COMPONENT_ITEM_NUMBER);
componentItemNumber.setRequired(true);
componentItemNumber.setEditorType(componentItemNumberTemplate);

Thanks

[Isomorphic]

We're not reproducing this - can you put this together as a complete test case so we have something we can run to reproduce the problem?

[ramis]

I haven't put together a test case, however I have stripped down the code that I'm working with and I believe I have identified the culprit. I'm hoping you can still help me without requiring a complete test case.

It comes down to these 3 properties or functions being set on the grid:
grid.setSaveLocally(true);
grid.setSaveByCell(false);
grid.setValidateByCell(true);

It turns out that when I comment out setSaveLocally(true), the validation works everytime. I need to have it in play though.

When all 3 are uncommented the alternating validation pattern that I've described above occurs.

When setSaveLocally is set to true, its supposed to avoid the grid from attempting to save / retrieve data from the server. I'm not so sure that it makes sense for it to interfere with validation though.

[jay.l.fisher]

Any news on this? We need to use setSaveLocally(true) but we also need to do validation on one of the fields using a DMI call to the server.

[Isomorphic]

We're looking at it. What we've found is that saveLocally expects to do a synchronous save, and this is a valuable feature for this mode, but interferes with remote validation logic. We are looking into either adding a flag that makes saveLocally asynchronous or suggesting another approach for your use case.

[jay.l.fisher]

Any update?

[Isomorphic]

Ok we've added a new flag "useRemoteValidators" to listGrid.
It's a Boolean.
When saveLocally is true for the grid and this flag is set, when the user edits and then attempts to save data, we check for any server-validators on the ListGrid's dataSource and will execute them before updating the local data array with the user-entered values.
This means the save is asynchonous in this case -- the data gets updated only after the (asynchronous) remote validators have run and returned their results.

[ramis]

Thank you for the fix. However, we still seem to have an issue here.

While the DMI validation is now consistent thanks to your fix (rather than on/off as in my original post), it is now validating all fields in the row whenever a change is made to any field.

Is there a way for it to only validate the field that was just edited and not the entire record?

Thank you

[Isomorphic]

Validators can have inter-dependencies (eg one validator depends upon other validators having been run and normalized values in the record to a known state) so currently we need to run all validators. We may in the future add a mechanism that allows you to specify that a particular validator can run in isolation and does not require other fields to be validated as well.

[jay.l.fisher]

I'm not sure I understand the logic regarding inter-dependencies. If each validator requires all other validators to have been run, which one goes first? I think what you mean is that data type validations must be done for all fields first, so that validators can rely on an integer field being an integer, dates being dates, etc.

But that doesn't mean that all application level validation logic needs to be run on all fields before validating any one field. Even if you stick with the approach of validating every field in the record when any one field is validated, it seems that you would only validate each field in the record once.

What we seem to be seeing is multiple calls to validate the same field during one round of validations on the record. If each field validation triggers a new validation on every other field it seems that the number of calls to validators would increase exponentially with each new field. Is that really the way it is supposed to work?

[Isomorphic]

In addition to data type validators, validators such as "mask" can modify the data during validation. So it's not just data type validators that may need to be run before other validators.

Order of validation is order of the fields in the DataSource.

Server validators normally run once per record per request, but an explicit call to validate() will of course cause them to be run again. There's no way for an exponential number of calls to happen. If you think there's some kind of flaw here please explain how to reproduce it.

[jay.l.fisher]

We have a ListGrid which has a number of fields in it, one which has a DMI validator, the others have only client-side validators. The users want immediate feedback as they exit each field if there is a problem so we're using validateByCell. The problem in this scenario is that as we exit each field the DMI validator gets called again, causing a delay as you tab through the fields. Is there some way to avoid the extra DMI calls?

Another aspect of our problem is this. The DMI validation we're doing also depends other hidden fields to be present in the record. When the user starts editing a new record we populate those hidden fields in the new ListGridRecord by using an EditorEnterHandler and calling setEditValue(). The first DMI validation call is triggered by exiting the field which has the DMI validator on it. That one works fine, but on subsequent calls to the DMI validator when exiting other fields in that record, the value we placed in the record via setEditValue() is no longer present.

[Isomorphic]

On the first question: are you saying you want local validators to run but remove validators to be skipped?

On the second: can you add code to a sample to demonstrate this behavior? Should be trivial to do if it's really a framework problem.

[jay.l.fisher]

On the first question: are you saying you want local validators to run but remove validators to be skipped?

Ideally we'd like only the validators for the field being validated to be run with validateByCell, but if they're local it doesn't have much of a performance impact if they get re-run for every field. It's the remote validators that have the server turnaround delay.

On the second: can you add code to a sample to demonstrate this behavior? Should be trivial to do if it's really a framework problem.

We have seen the same behavior in a couple of different contexts which is why I didn't suspect our code first. I'll take a closer look and see if I can create a stand-alone test case.

[Isomorphic]

OK, then the first question was really a reiteration that you'd like some way to declare dependencies in order to avoid running all validators (asked before in another thread) - right?