How do I programatically initialize validator when using ListGrid.addData?

[nitroamos]

If I use this code:

isc.ListGrid.create({
    ID: "countryList",
    width:500, height:224, alternateRecordStyles:true,
    data: countryData,
    canEdit:true,
    fields:[
        {name:"countryCode", title:"Flag", width:50, type:"image", imageURLPrefix:"flags/16/", imageURLSuffix:".png"},
        {name:"countryName", title:"Country", required:true, valueMap:["a","b"]},
        {name:"capital", title:"Capital"},
        {name:"continent", title:"Continent"}
    ]
})


isc.IButton.create({
    title:"Add Data",
    left:0, top:240, width:160,
    click: function () {
        countryList.addData({});
        countryList.startEditing(countryList.getTotalRows()-1);        
    }
})

isc.IButton.create({
    title:"Is Valid?",
    left:200, top:240, width:160,
    click: function () {
        isc.say("has errors: "+countryList.hasErrors());       
    }
})

in this example:
https://www.smartclient.com/smartcli...e/?id=localAdd

then I'd expect the grid to have an error after I click add data (because I've marked countryName as required and I didn't provide it initially). However, the listgrid doesn't have any errors until I open the menu for the countryName field specifically. My reason for not using startEditingNew is I want to avoid unsaved records so I can use other functionality to help users set the fields (which requires the records to exist).

Triggering startEditing isn't sufficient because if I end editing w/o visiting the countryName field, the requried validator still hasn't been added.

[Isomorphic]

Validation errors are shown in the grid for user entry. You are doing a programmatic addData(), so errors would be reported in the callback.

Note it's also odd to be going down this path without introducing a DataSource.

[nitroamos]

I (the programmer) know that there are errors -- what I'd like is for users to see the red exclamation mark, or at the very least, for me to be able to prevent users from clicking my submit button.

So are you saying that I should store and manage an error flag of my own? i.e., mark it as having an error when I create the record, and then clearing my flag when I know that the ListGrid sees the error?

My use case doesn't call for a DataSource because there are 2 server software layers between the ListGrid and the database tables where the data is stored.

[Isomorphic]

First: you should revisit the concept of DataSources (start with the QuickStart Guide), because you are eliminating them from this use case wrongly. The number of software layers between client and server could never be a reason not to use DataSources.

As far as your use case, if you want to introduce edits that you know to be invalid and have them immediately flagged as invalid, you can do this via editValues: see the ListGrid Editing overview.

[nitroamos]

Hello Isomorphic, thanks for the advice. Calling setEditValue to null on all my required fields gives me the behavior I am looking for. One thing that confused me, which I didn't write above, was that I actually have 2 required fields, and the validator for one was being initialized but not the other. I couldn't figure out what the difference was until today when I noticed that a startEditing command was initializing the one that was getting marked required. Anyway, with this solution, if I don't call saveAllEdits, then the user isn't confronted with the errors until after they click away, which is nice.

As for DataSources, maybe I can word it differently -- the data I'm managing lives in a 3rd party database for which I should use the 3rd party REST api, and I have my own business logic to impose beside. It seems like a fair amount of effort to configure and use a RestDataSource when it's not clear I'd benefit from any DataSource specific features. That is, I wouldn't use caching, paging, there's no login, and there aren't many users. A pure clientOnly DataSource doesn't seem better than a no-DataSource ListGrid for its own sake (i.e., you state it's for prototyping purposes only). But don't get me wrong, I love ListGrid even if you don't implement anything I've posted in your wish-list. :-)

[Isomorphic]

The point of using a DataSource for grid editing that it gives the grid a clear set of operations to use for saving, and a way for you to report success and failure and for the grid to respond appropriately. So the purpose of using a DataSource here is not related to any of the features that you mentioned would not apply here.

It's not clear what other approach, rather than a DataSource, that you intend to use to contact the server - raw use of RPCRequests? That definitely would not make sense.

Note also that if you have a pre-existing REST service, and you can't change it, you do not use RestDataSource, you use DataSource. See the QuickStart Guide, Data Integration chapter.

[nitroamos]

I'm using jQuery.ajax to communicate with a grails server (which in turn communicates with the 3rd party rest api). The server side of my app itself has about 3000-4000 lines of groovy code, a mostly meaningless number, but as far as I can tell, "transforming requests" is not a simple matter. I don't claim to have worked out the best approach, but I'm basically done and it's already working well for me (with minor glitches/wishes that I've posted on your forums). The main thing I don't have implemented is when when the servers report back errors, they're not shown in the grid, but that wouldn't be easy for me to implement because it would require me to reverse engineer the descriptive based errors the 3rd party tool emits.

I'm a little bit surprised at the level of interest you've shown in what I'm doing. I don't know if my use case (scientific software) is common for your technology, so it might be mutually beneficial for me to do a demo for you. Or if you have reps going to the Strata conference in NYC this Sep we could meet up.

[Isomorphic]

If your error handling is, of necessity, just throwing up a dialog for any failure and not doing per-cell errors, that's one less thing DataSources would do for you, but you still end up with logic to clear out editValues and such, which is otherwise unnecessary.

You seem to be worried about some odious task of request transformation, but it doesn't work like that - be sure to revisit the docs here, as you can even keep your existing jquery calls (see dataProtocol:clientCustom). The DataSource simply gives you an API where you receive the data the grid wants to save and it's up to you to save it, and report success/failure. This is a couple of steps easier than trying to figure out when the grid is apllying changes, rolling them back manually on failure, etc.

Your app closely tracks applications we have built for other life sciences customers, including details like nested grids to show assay results. We don't have current plans to attend Strata, but we'll be in touch about this.