I have a column in my grid that contains an embedded HTML table. Works great, looks just like I want it.
I have a problem, however, when trying to update data on the grid (sending to server with SaveChanges). When data is sent to the server, the table gets sent too and I get an error when trying to read the transaction from the response ("A potentially dangerous Request.Form value was detected..."). I understand why I'm getting the error, I'm sending embedded HTML in my request.
My question is, is there any way that I can NOT send that particular column when I post an update? I don't need that column in the update set (it's read-only and I don't need it at the server) but I can't see any way of not sending that particular column or otherwise not sending the embedded HTML. I tried an unbound column, I tried the "mapping" option on the column, neither work, the column with the HTML table still gets sent and there doesn't seem to be any way for me to "escape" the embedded HTML to avoid the issue.
Turning off the warning is not an option, and I'm wondering if there's any other solution short of manually serializing and sending the data?
This is in version 17.1
Thank you.
Well, I think I sort-of answered my question. I'm already handling saving manually, and on save I can iterate the transaction log from the grid and "null out" the offending column on each transaction row. A subsequent call to "SaveChanges" then works, I can receive and parse the response on the server without error.
So that seems to work OK for this situation. I'm still wondering if there's any way to just not send that column at all? That would be preferable but this'll work for now.
Thanks.
Hello Doug,
Thank you for the update that you found your code working.
I am not very sure if you can achieve the requirement without sending the column at all.
I would like to know how you set up your code and instantiate the grid.
Would be helpful if you could provide me a small isolated sample to investigate the scenario further.
As per online document of iggrid , making that html column as a unbound column would help you to achieve your requirement.
The Unbound Columns feature of the iggrid control enables defining of columns that are not directly bound to a field in the data source. Unbound column would display lists of items which doesn’t goes to the server.
To check this behavior in your sample I modified the sample little bit.I set autoCommit to true and set ‘ItemContentTable’ column as a unbound column.
Now I run the sample, open the console and check all the transaction (using ‘AllTransactions’ method of the grid)and found unbound column ‘ItemContentTable’ dint pass through .
For more information about unbound column please refer the below online document.
https://www.igniteui.com/help/iggrid-unboundcolumns-overview
Let me know if you need further assistance.
Well, yeah, of course it doesn't send the column, you're not actually populating it with data in your example. As I mentioned, I had already tried an unbound column but with data in the column, it still got sent to the server even though it was unbound.
If you actually populate the unbound column with data, does it get sent? If not then that would help me see where I went wrong -- you're using autocommit = true, I'll try that to see if it makes any difference.
Thank you for the update.
After going through our online document once again and discussed with the team I found the information about unbound column is that unbound columns do get send to the sever.This is described in the documentation also:
https://www.igniteui.com/help/iggrid-unboundcolumns-known-issues#updating In short, the unbound data is part of the data source so it will get serialized as part of the transaction. You can loop through the transactions log and remove the particular unbound field from the transaction, if you so desires, for example: var transLog = $("#grid").igGrid("allTransactions"); $.each(transLog, function (index, transRowObj) { delete transRowObj.row["Unbound"]; }); Where “Unbound” would be the key of your unbound column.
Please let me know if you need further assistance.
OK, thanks. that's precisely what I'm doing and it works, I just wanted to check to see if there was a better/less low-level way to do it. I'm OK with doing it this way, and I appreciate that I'm able to get at the data to do what I need to do so thank you for that!
Thank you for your help.