CodePlex Home
Register | Sign In | CodePlex Home
8 votes
closed
JsonResult does not take JavaScriptConverter into consideration

Description

 
The JsonResult does not take JavaScriptConverters registered in web.config into consideration when serializing.

File Attachments


No files are attached


Closed Aug 21 at 12:32 AM  by eilonlipton

The converters in web.config are only used when processing an asmx web service. They are not meant to be used during arbitrary JSON serialization. If you want you can write a custom ActionResult that reads the list from web.config and write passes it into the serializer. If you look at the source code for the built-in JsonResult you'll see it's only a few lines of code so adding the functionality to your app shouldn't be too hard.

Comments

most recent at top (show oldest at top)
auriel wrote Mar 24 at 11:58 PM
You are free to write that helper for your own use; it was out of scope for 1.0 RTM. If in a future release we have access to Web.config (as I hope we will; read my earlier comments), then that extra helper won't be necessary and probably won't be included.

kazimanzurrashid wrote Mar 24 at 10:17 PM
Okay, forget about the web.config part, at least give us someway to register those JavaScriptConverters. ;-)

Pls do the following two things,

1. Add a JavaScriptConverter Collection/List as Property of JsonResult Class.
2. Create a overloaded method in Controller.

protected virtual JsonResult Json(object data, string contentType, Encoding contentEncoding, IEnumerable<JavaScriptConverter> converters)
{
return new JsonResult
{
Data = data,
ContentType = contentType,
ContentEncoding = contentEncoding,
Converters = new List<JavaScriptConverter>(converters)
};
}

And in JsonResult ExecuteResult method register those converters.

And I hope this will not be an Issue for the future release.

auriel wrote Mar 24 at 7:20 PM
Part of the goal of MVC was to see how far the ASP.NET libraries could be extended by third-party developers. That is, how far can we go *without* changing the System.Web assemblies? (And note that for MVC to be friended / InternalsVisibleTo System.Web, it would require a modification to System.Web.) This was actually a success since it identified areas that we need target in future versions of ASP.NET, such as not being so strict about accessing Web.config settings. If we simply friended MVC and System.Web, we would never have experienced this issue, but since we did experience it we can change it in a future release so that *all* developers can benefit from it.

As for friending the two assemblies, AFAIK there are no plans to do this since it would defeat the purpose of what I mentioned above. As areas of ASP.NET are opened up to public access, MVC can begin consuming them.

kazimanzurrashid wrote Mar 24 at 1:14 PM
Did you mean InternalVisibleTo by "friended" or whatever it is, what is the issue following the same direction of System.Web.Extension, with the current version it is not possible to set the JavaScriptConverters, so we need it in the next sp/release/version.

auriel wrote Mar 24 at 9:12 AM
SWE is friended to System.Web, so it fundamentally has more access to ASP.NET internals than does Routing / MVC.

kazimanzurrashid wrote Mar 23 at 8:54 PM
I think there is some communication gap. Neither the JavaScriptSerializer nor JavaScriptConverter is in the Core ASP.NET. These are the classes of System.Web.Extension dll which was introduced in ASP.NET Ajax Framework and later on merged into the ASP.NET 3.5. If those can access the web.config in medium trust, I don't see any issue in ASP..NET MVC Framework to do the same.

Also this is a Designing flaw as there is no way to set the converters programmatically, I have posted it in my blog with the resolution maybe it can help to understand it better:
http://weblogs.asp.net/rashid/archive/2009/03/23/submitting-my-first-bug-after-asp-net-mvc-1-0-rtm-release.aspx

auriel wrote Mar 23 at 8:01 PM
Neither Routing (3.5 SP1) nor MVC (1.0 RTM) is able to access Web.config since accessing many of those settings requires a high trust level, and only ASP.NET itself is able to access them directly without jumping through hoops. (Remember that Routing and MVC simply ride on top of ASP.NET; they're not integrated into the core of the product itself.) For now, many of the things that originally could be specified in Web.config have to be specified programmatically, and JSON serialization is one of those things.

Updating...
© 2006-2009 Microsoft | About CodePlex | Privacy Statement | Terms of Use | Code of Conduct | Advertise With Us | Version 2009.10.27.15987