Is there a sample somewhere of doing RESTFUL CRUD operations on the datasource?
I.e. I need to be able to have all changed records get posted in an json array to a PUT method, Inserts to a POSt in a json array, and deletes as the URL with a parameter repeated for each of the primary keys for the deleted records.
I'm not finding any documentation on how to do this at all, and the samples are only showing a single "update" url instead of broken down ones.
Thanks for any assistance!
Hi,
you don't need multiple URLs in order to achieve CRUD, because what's sent in the POST request (when your Update URL is hit) is a serialized JSON list of transactions, where each transaction has a type - update, delete, add, etc. So you need to handle the transaction list, as it is described in the following help link, and that should do:
http://help.infragistics.com/Help/NetAdvantage/jQuery/2012.1/CLR4.0/HTML/igGrid_Updating.html
if you aren't using .NET, you can take the ig_transactions param from the request and parse it using your server-side technology/language of choice . the "type" property of every transaction in the list specifies whether it's an "add", "delete", etc. "type" can take the following values:
1) "cell" - it means a cell was updated, then you can use the value property to get the new value
2) "row" - updating of a row
3) "addrow"
4) "deleterow"
Hope it helps. Thanks,
Angel
While this is a good hack for MVC.NET it is NOT REST.
REST ALWAYS has GET (Read), POST (insert), PUT (update) and DELETE functions that are called.
They are ALWAYS of the correct content type and request type in HTTP and ALWAYS follow specific rules.
If I wanted this to just work with MVC.net I'd use Infragistics (or anyone else's) mvc.net controls. There would essentially no reason to use a jquery based library because every mvc.net library I have ever seen uses jquery and works against MVC's anitquated web services and/or AJAX calls.
However THE STANDARD is REST + JSON. All libraries should follow this pattern. (i.e. if you were to use these controls in RoR then you would have to follow this pattern, because this is how it's done. Same with most other current languages.
That means that Updates, INSERTS and Deletes must be sent to their own endpoints. I'm obviously not going to write a wrapper in mvc.net to call REST services nor should that be expected given what jquery controls are all about.
Further, mvc.net 4 includes Web API which is fully restful and follows all of the rules as well. Again this is the defacto standard and is taking over rather quickly from SOAP web services.
Thus I expected a REST data source that can work in batch mode as well as single object mode. It should POST with a json array in batch and a single json object in non-batch (i.e. JSON.stringify()) for inserted records that need to be persisted, PUT in the same manner for updates to be persisted and send a list of IDs as parameters on the URL as described for deletes.
The request type should be set appropriately for each type of request.
My question is simply: Is this possible with Infragistics jquery or is it completely bound to mvc.net for some odd reason?
And if it's possible, what's the timeline for a true REST data source? (I would have expected that like Kendo it would have come with one out of the box because as I said, this is the standard for anything jquery.)
I'm trying to decide if I'm wasting my time with the infragistics controls or if it's worth pursuing. This is the one major roadblock and a surprising one that that.
FWIW, I'd very much like to see a standalone oData example with igHierarchicalGrid that can do oData CRUD operations on both the main level and child columnLayouts. All the current oData examples are read-only. Any chance someone could whip one up?
According to support it's not possible without using their hack.
Unfortunately it appears that Infragistics jquery is not ready for any REST applications, Odata or otherwise. (even though it clearly shows in the graphic about the data source that it does support REST)
I gotta wonder why so many companies will eagarly show you read, but can't get full CRUD right with REST. (i.e. every single one that does sort of support REST out there doesn't get deletes right and violates RFC rules and posts data to the body of DELETE, which isn't allowed, all parameters must be in the URI)
Infragistics this is your opportunity to shine if you get this right and give us a truly REST service that handles things correctly.
Thanks for the valuable feedback! :)
AFAIK, the OData itself doesn't define anything specific to REST, it's only defining how entities (resources) are being addressed, and how the URL should be constructed, in order to perform paging, sorting, filtering, querying (lazy /deferred loading), and so on. We do support OData in that sense, and we have a sample using the Hierarchical grid. Once REST support comes out of the box, it will and should work with the OData way of addressing resources, for sure.
I've started to work on a REST sample - meaning the REST API itself, as defined by RFCs, but haven't got a chance to complete it.
Also FYI, we have added this feature as top priority for our next release - 12.2.
Hope it helps, and again, thanks for sharing your thought guys - it really helps us improve the product.
I think what we are talking about is pretty simple and can easily be understood by looking at this page.
http://www.plippard.com/post/2010/10/06/CRUD-OData-WCF-Data-Services.aspx
He also links to Microsoft's javascript implementation which is similar in usage but I believe has support for batch operations as well which might be useful. All of this comes for free with a WCF Data Service - so in theory all you would need is one or more HTML pages with a grid in it, and a data services backend to accomplish quite a lot.
While I am well acquainted with silverlight xamgrid yesterday was the first time I had looked at your jquery offering and I have to say other than this issue, I'm fairly impressed with what all it can do and how well thought out the templating is. Much more flexible than xamgrid, even though I love c# and sometimes hate javascript with a passion. :-)
It's absolutely not as simple was WCF Data-Services.
Web API handles things VERY much differently and the writting is on the wall that WCF Data-Services is on the way out.
Web API + knockout + upshot = RIA for javascript and is the Microsoft way going forward. It is also the way that MS is going to support for standard REST services even if you don't use upshot. (which is crippled because it can't work against non-entities and doesn't support projections so it wastes resources by doing SELECT * on everything!.
Hence any implementation needs to work on true REST services. It needs to also be able to work on WCF Data-Services for backwards compatibility.