ListGrid startEditingNew() carrying over error icons from previous row

[DBoultbee]

SmartClient Version: v8.3p_2013-11-10/Pro Deployment (built 2013-11-10)

Hi,

I'm having trouble when adding a new row to a ListGrid using startEditingNew() where one of the fields is flagged for server only validation.

If this field fails validation an error icon is displayed correctly against it. The user is allowed to complete the row, even though a field failed validation, and add

a further new row. But on adding the next new row an error icon is displayed incorrectly against the field in the new row that corresponds to the field that errored in

the previous row.

Below is a test case that illustrates the problem.

Thanks in advance for any help.

Test Case :

    var ds = isc.RestDataSource.create({
        dataProtocol: "postParams",
        dataFormat: 'json',
        useStrictJSON: true,
        dataURL: "grid.ashx",
        fields: [
          { name: "ID", type: "integer", title: "ID", primaryKey: true },
          { name: "job",
              type: "text",
              title: "Job",
              validateOnExit: true,
              validators: [{ "serverOnly": true}]
          },
          { name: "number", type: "float", title: "Value" }
        ]
    });

    var grid = isc.ListGrid.create({
        ID: "grid",
        dataSource: ds,
        width: 500,
        height: 500,
        autoFetchData: true,
        canEdit: true
    });

    var vlayout = isc.VLayout.create({
    });

    var tstrip = isc.ToolStrip.create({
        ID: "ToolStripModes",
        width: "100%"
    });

    var addbutton = isc.IconButton.create({
        ID: "btnAdd",
        title: "Add",
        icon: "[SKIN]/actions/add.png",
        click: "grid.startEditingNew()"
    });
    tstrip.addMember(addbutton);

    vlayout.addMember(tstrip);
    vlayout.addMember(grid);

JSON response from the server for the inital data fetch :

{"response":{"status":0,"errors":[]}}

JSON response from the server from validation of the 'job' field in the first row :

{"response":{"status":-4,"errors":[{"job":"invalid job"}]}}

[jason.saunders]

Is this problem being investigated by someone at isomorphic?

[jason.saunders]

The problem occurs regardless of the user accepting the row.

If you generate the validation error and then press escape to discard the row, starting a new row via startEditingNew shows the error icon.

Is there a way for us to clear the errors?

[jason.saunders]

Is this problem being investigated by someone at isomorphic?

[DBoultbee]

Hi,

I've been looking for a work round for this problem and had no joy. But did notice one thing that maybe relevant.

As a test I changed the validator from a server only validator to be a client custom validator on the field 'job', as below :

validators: [{
   type: "custom",
      condition: function (item, validator, value, record) {
          if (value != "C232") {
             validator.errorMessage = "Job " + value + " is Invalid.";
             return false;
          }
          else
              return true;
      }
}]

When an invalid job code is entered on the first row of the grid and then a new row is added, the error icon is not appearing on the second new row. It works ok. Unlike for the server only validator, as stated in the original forum post.

So the problem of the error icons carrying over incorrectly to a new grid row only happens when using a server only validator, when using a client custom validator it all behaves correctly.

Hope this might be of use.

[Isomorphic]

Your description sounds like some bad behavior certainly but there's not enough information here for us to investigate.
Firstly, you are working against a very old SmartClient version, on a branch a couple of branches behind the latest.
We'd recommend you start by testing against the latest nightly build - ideally from the most recent SmartClient branch (10.0) and see if you're dealing with an already-fixed problem.

If the problem persists, and you believe it to be a framework bug rather than an application issue, so would like us to investigate, we'd need a way to reproduce the problem.

This basically means we'd want to see a simple, complete test case we can run on our end without modification which clearly shows the problem (along with steps to reproduce).
If (as in your case) it involves dataSources, we'd recommend you either
- create a clientOnly dataSource with test data which replicates the results, or
- modify one of the shipped samples in the feature explorer or similar, making use of one of the shipped (and known-working) dataSources with whatever small modifications are required to reproduce the problem.

We do take bug reports on the forums seriously, but can only investigate when we have enough information to definitively indicate a framework bug.

Note - if you'd like guaranteed responses, you may want to consider purchasing commercial support. We do still request the same level of information described here in bug reports from our supported users as this eliminates the possibility of invalid bug reports for already-fixed issues, or problems in application code we don't have (or even real issues which can't be reproduced on our end without time-consuming steps of guessing at the real-world configuration of an app, etc).

Thanks
Isomorphic Software

[DBoultbee]

Hi,

Thank you for the reply, I've now tried this in smartclient v10.0p LGPL nightly build 24-03-2015 and I still get the same problem with the error icon as in the v8 build we're using.

Have, hopefully, rectified the problems with my test case so it's of more use to yourselves to track this down.

    var ds = isc.RestDataSource.create({
        dataFormat: 'json',
        useStrictJSON: true,
        dataURL: "validate.json",
        fetchDataURL: "fetch.json",
        addDataURL: "fetch.json",
        operationBindings: [
            { operationType: "fetch", dataProtocol: "getParams" },
            { operationType: "add", dataProtocol: "getParams" },
            { operationType: "validate", dataProtocol: "getParams" }
        ],
        fields: [
          { name: "job",
              type: "text",
              title: "Job",
              validateOnExit: true,
              validators: [{ "serverOnly": true}]
          },
          { name: "description",
              type: "text",
              title: "Description"
          }
        ]
    });

    var grid = isc.ListGrid.create({
        ID: "grid",
        dataSource: ds,
        width: 500,
        height: 500,
        autoFetchData: true,
        canEdit: true,
        listEndEditAction: "none"
    });

    isc.VLayout.create({
      members: [
        isc.ToolStrip.create({
            ID: "ToolStripModes",
            width: "100%",
            members: [
              isc.IconButton.create({
                  ID: "btnAdd",
                  title: "Add",
                  icon: "[SKIN]/actions/add.png",
                  click: function () {
                    grid.startEditingNew();
                  }
              })
            ]
        }),
        grid
      ]
    });

The static file fetch.json contains the following to represent the response from the server :

{"response":{"status":0,"errors":[]}}

And the file validate.json contains the following :

{"response":{"status":-4,"errors":[{"job":"Invalid Job"}]}}

To get the error now, run the page and click the Add button. Enter any text in the Job field and tab to the Description field. The error icon appears against the Job field correctly.

Enter any text in the Description field and tab off the row to complete it. Next click the Add button again and you'll notice that the Job field in the next row has the error icon showing against it incorrectly. It doesn't call validate.json before showing the second row so I'm unsure why it would flag that field as in error?

Hope that's of more use.

Thanks,
David.

[Isomorphic]

There's a couple of issues in this test case:

1. there's no primaryKey in the DataSource. This is required for editing (per docs) and forgetting to have one would definitely cause this kind of issue

2. we don't actually document how to use the "validate" operationType with RestDataSource, if you a really using a RestDataSource in your actual app you are off in unsupported territory. We'll take a look at making this officially supported usage, but it would probably be a change made for a future release.

[jason.saunders]

1. Added primaryKey: true to ID field in dataSource. No difference.

2. If I understand you correctly you're saying you do not support server side validation with RestDataSource? That would be quite scary since we've been using it for 4 years... However, it all feels a bit odd - surely startEditingNew should unconditionally clear all errors as a new row has no relationship to a previous operation? Is there any (undocumented or otherwise) call we can make to clear the errors?

[Isomorphic]

1. Just adding primaryKey:true wouldn't fix your test case, you need to actually implement the PK field properly, which would involve a correct response for the "add" operation including a valid PK value. It sounds as if, from how you are testing, you are actually triggering the "add" operation, "fetch.json" is being returned, and this is obviously invalid.

2. Yes, as we previously covered, there is no documentation of how the "validate" request and response should be formed for a RestDataSource, and things which are not documented are not supported.

As far as where the problem is, because of the primaryKey/"add" response issues, we haven't seen a valid test case even assuming it's OK to rely on the undocumented feature of "validate" operationType with a RestDataSource. And our attempts to replicate this problem with other kinds of DataSources have all shown no issue. So we still don't even have evidence of a flaw even with the undocumented feature you're trying to use..

[jason.saunders]

Can you follow the replication as per my comment #3.

Full replication:

Click Add
Enter X in ID and press tab. Error icon is shown in job column
Press escape. Row is discarded.
Click Add. Error icon is shown in job column

In this process no "add" sent to the server, because no rows is added.