Hi jchau,
We did some work on limiting the properties that get Json serialized to only those defined as <ext:RecordField> items.
The functionality will now work with objects added to the <ext:Store> .DataSource property or when the .DataSourceID is linked to a control of type IDataSource, such as <asp:SQLDataSource>, <asp:ObjectDataSource, <asp:LinqDataSource>.
You can set the .DataSource property with any IEnumerable object, such as a Generic List<Customer> and the <ext:Store> will filter the data returned to only include the properties with a matching <ext:ReaderField>.
There's one exception to the list of objects we're able to ignore... currently the filtering/ignoring will not work if the .DataSource is a typeof Array, such as object[].
The <ext:Store> will filter the results automatically. The filtering can be "turned off" by setting the <ext:Store> .IgnoreExtraFields property to "false". The default value is "true". The following code sample demonstrates how to disable the filtering/ignoring of superfluous fields.
Example
<ext:Store ID="Store1" runat="server" IgnoreExtraFields="false">
We can add the filtered serialization feature because when using a .DataSource or .DataSourceID properties, the data is returned inline to the page and is already being serialized into Json by the <ext:Store>. We just throw out properties that don't match up with the <ext:ReaderField>'s.
The DataSource and DataSourceID properties can be filtered, but... if using the <HttpProxy> we can not filter the data.
If using the <HttpProxy>, the Store will call (via ajax) to an external uri/url to retrieve the data. The data may be returned as Json, Xml or a simple object Array. The <ext:Store> "reads" the data as per the settings of the <Reader>. To read Json, you need to use the <ext:JsonReader> and define fields that should be parsed from the Json data.
This external Http data call is asynchronous, decoupled from the original Page logic and the <ext:Store> and <ext:GridPanel> have no influence over how the data is structured. They only know where the data should be coming from and hopefully how it should be structured. It's impossible for us to automatically filter what gets serialized and sent back in the response.
In general, the data endpoint (webservice/url/uri) shouldn't know (or care) what's consuming it's response. Because of this decoupling, if you want to somehow filter or limit the data being returned by the Json feed, then you must only return what you need.
Json serialization is probably the way to go. It's extremely flexible, easy to do, a widely accepted format and the data is self describing (similar to xml).
The Coolite.Ext.Web.Serialize() Method is a generalized all purpose serialization utility... actually it's just a convenience wrapper around the Newtonsoft Json.NET Serialize() Method. The .Serialize() Method will take an Object and convert it into a Json string. Very simple, but it serializes all properties, unless decorated with the [JsonIgnore] attribute, as noted earlier.
Of course generic "all-or-nothing" serialization is not the only option.
If you only want certain properties serialized, or have some unique requirements, the Newtonsoft Json.NET library includes several EXTREMELY powerful techniques for custom serialization. The Json.NET library is well
documented and includes several custom serialization examples including LINQ-to-JSON. I would encourage you to read through the Json.NET documentation and
James Newton-King's website.
We're building a Coolite Toolkit "Examples Explorer" to demonstrate everything within the Toolkit, and I'll make sure we include a couple samples demonstrating custom Json serialization.
Summary...
- Automatic Json property filtering is now default functionality when adding data to the <ext:Store> via the .DataSource or .DataSourceID properties. To disable filtering set IgnoreExtraFields="false".
- If using <ext:HttpProxy>, the Toolkit can not filter the results, so it's up to the data end point to decide what should be return.
Hope this helps.