validating existing records in a listgrid

[acarur01]

Hi,

We've had this issue before and were unable to find a solution. I know that validation on records in listgrid only happen on user edit action, but we are in need of validating rows that are coming in. We cannot guarantee that the records we initially provide to a list grid is valid as they are potentially coming from an external system in which we have no control of user input to begin with. Many things can also happen to the database which we do not have control over. We need a way to either send over the validation errors per field on initial fetch (this is desired) OR have a way to call update on specific rows that we have marked is invalid after the fetch returns the data to the browser.

We would like to resolve this issue as soon as possible. Please let me know any workarounds for this. Thanks

We are using upgrade to SmartClient_v82p_2013-01-21_PowerEdition

[Isomorphic]

To have record values treated as though they are untrusted data that might have validation errors, add them to the grid as editValues.

For larger data volumes, the best way to do this is to provide records to the grid with the values you consider valid, then take all the values that have validation errors and apply them via setEditValues().

Note also that while there are APIs such as setFieldError() that will allow to provide validation errors to the grid, we don't recommend this approach, because it doesn't provide the grid with any information about when this error should be cleared. Instead, the best way to provide validation errors to the grid is to provide validators that will return those errors; then there won't be a need for setFieldError() at all.

[acarur01]

Does this mean I have to do a fetch twice? Once for the 'valid' data and the other for the invalid data? At this moment everything is returned in one fetch - if so, where do you propose I add the second fetch? in dataArrived?

[Isomorphic]

You should avoid two serial fetches of course. There are a lot of ways to do so.

One would be to embed information in the records that you can use to call setEditValues() (for example, rename all attributes that are expected to have errors something like error_originalFieldName).

[acarur01]

I can try that out. Where do you suggest putting the setEditValue call?

[acarur01]

I've tried this out in a sample - when you click the button, setEditValue is called on population - but the validation isn't fired until I click on the record and then click out. Is this what I am supposed to be seeing? I'd like to see the error right away.

isc.ListGrid.create({
    ID: "countryList",
    width:550, height:224, alternateRecordStyles:true, cellHeight:22,
    dataSource: countryDS,
    fields:[
        {name:"countryCode", title:"Flag", width:40, type:"image", imageURLPrefix:"flags/16/", imageURLSuffix:".png", canEdit:false},
        {name:"countryName"},
        {name:"continent"},
        {name:"member_g8"},
        {name:"population", formatCellValue:"isc.Format.toUSString(value);",
            validators:[
                {type:"integerRange", min:1}
            ]
        },
        {name:"independence"}
    ],
    autoFetchData: true,
    canEdit: true,
    editEvent: "click"
})



isc.Button.create({
left: 700,
click: function(){
   
countryList.setEditValue (1, 4,"test");
}
})

[Isomorphic]

You could call validateRow() immediately after calling setEditValue()

[acarur01]

I see - that works. Do you recommend doing this in dataArrived then?

[Isomorphic]

Most likely yes

[acarur01]

One more thing about the validation errors - we cannot provide validators to the listgrid since we do not know what the validation is until the data is updated in the server. Currently, we have a dsResponse.addError call in our dsUpdate() method. What is the equivalent of this on the browser side so that I can have the same behaviour without calling update() on the row?

Note also that while there are APIs such as setFieldError() that will allow to provide validation errors to the grid, we don't recommend this approach, because it doesn't provide the grid with any information about when this error should be cleared. Instead, the best way to provide validation errors to the grid is to provide validators that will return those errors; then there won't be a need for setFieldError() at all.

[Isomorphic]

So again, as the text you quoted mentions, you need to provide validators or there is no way for the grid to know whether an error should be cleared.

If the determination of errors is done server-side, provide a server-based validator (type "serverCustom").