How to setErrors on a field in the ListGrid

[homer84]

For a listGrid, there is the setRowErrors() method that will set errors for fields in a row. I am able to set the errors, but how in the world are we suppose to display them next to the field. I keep getting the 'undefined' next to the fields instead.

[Isomorphic]

Make sure the fieldNames used in setRowErrors() match the fields declared for the grid or its DataSource. If that doesn't solve it, can you show your code for calling setRowErrors()?

[homer84]

gridName.setRowErrors(rowNumber, {fieldName:"Network does not match state"});

I get the row number by using :
gridName.getEditRow();

for some reason, it seems like this sets the error, but does not display it next to the field.

[Isomorphic]

Hi Homer,
From a quick investigation it looks like we may have a bug here if your listGrid has an unset "canEdit" attribute.
Can you try setting canEdit:true on your grid and see if you still don't see the error.

Let us know if this solves this for you (and we'll make sure this issue gets fixed for our next release).

Thanks
Isomorphic Software

[Arjan Mels]

Dear Isomorphic,

I am encountering the same issue when I return validation errors from a WSDataSource (validation error is shown in listgrid, but with text "undefined" instead of my custom text).

My listgrid has canEdit set to true.

Any suggestions?

Also second question: If I set the error code to -1 and a text in the data field I only get to see a warning in case of a "fetch" operation, not for the other operations (update, add). Is this by design? How can I change this?

Best Regards,

Arjan Mels

[Isomorphic]

I doubt this is related to the other posts..

On your first question, at the end of DataSource.transformResponse(), what are the contents of dsResponse.data? It should be the error string.

On the second question - same question.

[Arjan Mels]

Dear Isomorphic,

Thank you for the weekend service!

If I understood it correctly for validation errors the status should be -4 and dsResponse.data should not matter, but the error should be in dsResponse.errors.

In the mean time I progressed a couple of steps. If I force the following in the transformResponse overload:

          dsResponse.errors={field1:{errorMessage:"testerror"}};

the message "testerror" is shown properly. (Note that the "errorMessage" indirection seems to be mandatory with this exact field name; I did not see this clearly stated in the documentation!)

So now it boils down to getting the xml properly translated into dsResponse.errors with a WSDataSource.

Option1:

... (non essential parts left out)
<errors xsi:type="xsd:Object"><field1><errorMessage>test1</errorMessage></field1></errors>
... (non essential parts left out)

This gets translated into: [{errorMessage:test1}] (so field1 gets lost)

or

... (non essential parts left out)
<errors xsi:type="xsd:Object"><row1><field1><errorMessage>test1</errorMessage></field1></row1></errors>
... (non essential parts left out)

Here I get an error inside the getElementText (or isTextNode: firebug stack trace says isTextNode, but the script line shown (and arguments) is for getElementText) function: _3 is undefined

or :

... (non essential parts left out)
<errors xsi:type="xsd:Object"><row1><field1>test1</field1></row1></errors>
... (non essential parts left out)

(this is what I did originally, and which gives the validation error with text undefined, which is understandable as the errorMessage field seems to be mandatory)

I think option 2 is the "correct" one if I look at the source (which takes into account potentially multiple row results, however I always get the error in tthe isTextNode function...) Of course I can fix it with custom code in the translateResponse, but I would like to know how I should do it with the default code.


With regards to the second question (no warning upon update/add/remove). What I can see from the source code it is by design: (RPCManager.handleError will not be called as the willHandleError is set to allow for the validation).

As a workaround I overloaded the editFailed mehtod in the listgrid itself as following:

            editFailed: function (rowNum, colNum, newValues, oldValues, editCompletionEvent, dsResponse)
            {
              if (dsResponse.status==isc.DSResponse.STATUS_FAILURE && dsResponse.data!=null)
              {
                isc.RPCManager.handleError(dsResponse,null);
              //  isc.warn(dsResponse.data);
              }
            },

(I do not really like this solution as I have to do an override in yet another place. I also tried to overload handleError in the datasource, but this does not seem to get called. And I do not understand why.)

Looking forward to your rseponse.

Best Regards,

Arjan

[Arjan Mels]

And another coupl eof steps

Dear Isomorphic,

And another couple of steps further: The problem stems from the fact that in my WSDataSource the fields are defined in the schema.
Now in case of an error the same field name must be used and the toJS function then recognizes this field as having a type defined in the Schema and the type is a simple type (in my case a string). You end up in the code path on line 114 in the source code.

However for an error it should not be a simpletype, but an object containing the "errorMessage" field...

The real problem comes from the transformResponse code in the WSDataSource: the WSDataSource itself is passed as the datasource to the toJS function.

I created the following patch (this also includes the patch for the issue with the data field not being passed on in case of an error condition.)

The patch:

isc.WSDataSource.addMethods({transformResponse: function(_1,_2,_3)
{
  _1.status=_3.selectString("//status");
  if(isc.isA.String(_1.status))
  {
    var _4=isc.DSResponse[_1.status];
    if(_1.status==null)
    {
      this.logWarn("Unable to map response code: "+_4+" to a DSResponse code, setting status to DSResponse.STATUS_FAILURE.");
      _4=isc.DSResponse.STATUS_FAILURE
    }
    else
    {
      _1.status=_4
    }
  }
  if(_1.status==isc.DSResponse.STATUS_VALIDATION_ERROR)
  {
    var _5=_3.selectNodes("//errors/*");
    _1.errors=isc.xml.toJS(_5,null,null /* instead of: this */)
  }
  _1.totalRows=_3.selectNumber("//totalRows");
  _1.startRow=_3.selectNumber("//startRow");
  _1.endRow=_3.selectNumber("//endRow")

  // fix for error message
  if (_1.status==isc.DSResponse.STATUS_FAILURE)
     _1.data=_3.selectString("//data");
}
});

This will accept XML formed like:

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><SOAP-ENV:Body><updateResponse><status>STATUS_VALIDATION_ERROR</status><invalidateCache>false</invalidateCache><data>test1</data><startRow>0</startRow><endRow>0</endRow><totalRows>0</totalRows><errors xsi:type="xsd:List"><item xsi:type="xsd:Object"><field1><errorMessage xsi:type="xsd:string">test1</errorMessage></field1></item></errors></updateResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>

Do you agree that the patch as suggested indeed is appropriate? (And can you include it in the 7.0 release version?)

Best Regards,

Arjan Mels

[Isomorphic]

The intended response format for dsResponse.errors is documented here. It's simpler than the approaches you're showing. Your WSDL response should not contain xsi:type indicators, and this is possibly causing a problem.

Set the DSResponse status to -1 (general error) to cause error handling to occur. Setting it to -4 (validation error) is an error that a form knows how to handle - it won't call the central handleError() because that's only for unknown errors.

[Arjan Mels]

Dear Isomorphic,

The link you refer to is indeed the javascript format. However going from xml (for WSDataSource) to this internal format is going through a number of steps.

The following code in WSDataSource.transformResponse:

var errors = xmlData.selectNodes("//errors/*");
dsResponse.errors = isc.xml.toJS(errors, null, this);

demands the extra level of indirection above the field names.

parseServerErrors (in the listgrid control) is the one that demands the "errorMessage" extra step.

(So this xml format should also be documented imho.)

For the necessity of the patch, please compare line 66 in WSDataSource.js versus line 535 of RestDataSource.js (source version of 6.5.1):

dsResponse.errors = isc.xml.toJS(errors, null, this);
=>
errors = isc.xml.toJS(errors);

On topic 2: even if I set the DSResponse.status to -1 no warning will be shown for update,add or remove requests...

Best Regards,

Arjan Mels

[Isomorphic]

Hello Arjan,

Have you tried this without the xsi:type indicators? What we meant with the last response is that with the soap encoding specified in the WSDL, xsi:type should not be sent, and doing so influences how translation to JavaScript occurs. The expected format for errors should match the format used for RestDataSources, and in the absence of xsi:type markers, this should just work - can you try that?

Note we agree that we do need to explain the errors format in the WSDataSource doc...

On error handling: can you show an example where you're not seeing a warning for a status of -1 and an error message being set as dsResponse.data ? This shouldn't differ for WSDL vs other data formats, the code is all the same.

[Arjan Mels]

Dear Isomorphic,

On error handling: The warning for status of -1 is not shown when you update data by having a listgrid with canEdit:true, double clicking a row changing something and then double clicking another row.

The warning is shown properly when you use the updataData method as in the example RestDataSource - Edit and Save example...

So to reproduce add the canEdit:true to the "RestDataSource - Edit and Save" example; update the country_update.xml file to shwo an error and update via double clicking.

BTW. The programatic version does NOT HANDLE validation errors properly, while the double click to edit does... Instead the programatic version (using updateData will always show a warning dialog if the <data> field is set even with status code -4...)

On the first issue, please compare the source of transformResponse for the WSDataSource and the RestDataSource:

WSDataSource:

            var errors = xmlData.selectNodes("//errors/*");

RestDataSource:

                var errors = data.selectNodes("//errors");

The difference is teh extra /* in the xpath expression. This forces an extra level of indirection!

So the format for WSDL has to be:

<error>
<extralevel>
<field1>
<errorMessage>
This is the error
</errorMessage>
</field1>
</extralevel>
</error>

While for REST:

<error>

<field1>
<errorMessage>
This is the error
</errorMessage>
</field1>

</error>

(On the whole the entire WSDL implementation is a bit bugridled, a fresh copy and paste or at least carefull compare with the RestDataSource transformRequest + transformResponse XML parts would solve a lot of issues I think: sortBy, oldValues, validation errors...)

Best Regards,

Arjan Mels