JSON.Stringify fails on Scripting.Dictionary objects

Javascript’s for...in construct (which is used in the JSON serializer you refer to) only works on native JS objects. To enumerate a Scripting.Dictionary’s keys, you need to use an Enumerator object, which will enumerate the keys of the Dictionary.

Now the JSON.stringify method has a nifty way of allowing custom serialization, by checking for the presence of a toJSON method on each property. Unfortunately, you can’t tack new methods on existing COM objects the way you can on native JS objects, so that’s a no-go.

Then there’s the custom stringifier function that can be passed as second argument to the stringify method call. That function will be called for each object that needs to be stringified, even for each nested object. I think that could be used here.

One problem is that (AFAIK) JScript is unable to differentiate VBScript types on its own. To JScript, any COM or VBScript object has typeof === 'object'. The only way I know of getting that information across, is defining a VBS function that will return the type name.

Since the execution order for classic ASP files is as follows:

• <script> blocks with non-default script languages (in your case, JScript)
• <script> blocks with the default script language (in your case, VBScript)
• <% ... %> blocks, using the default script language (in your case, VBScript)

The following could work — but only when the JSON.stringify call is done within <% ... %> brackets, since that’s the only time when both JScript and VBScript <script> sections would both have been parsed and executed.

The final function call would be this:

<%    Response.Write JSON.stringify(oProd, vbsStringifier)%>

In order to allow JScript to check the type of a COM object, we'd define a VBSTypeName function:

<script language="VBScript" runat="server">    Function VBSTypeName(Obj)        VBSTypeName = TypeName(Obj)    End Function</script>

And here we have the full implementation of the vbsStringifier that is passed along as second parameter to JSON.stringify:

<script language="JScript" runat="server">    function vbsStringifier(holder, key, value) {        if (VBSTypeName(value) === 'Dictionary') {            var result = '{';            for(var enr = new Enumerator(value); !enr.atEnd(); enr.moveNext()) {                key = enr.item();                result += '"' + key + '": ' + JSON.stringify(value.Item(key));            }            result += '}';            return result;        } else {        // return the value to let it be processed in the usual way            return value;        }    }</script>

Of course, switching back and forth between scripting engines isn’t very efficient (i.e. calling a VBS function from JS and vice versa), so you probably want to try to keep that to a minimum.

Also note that I haven’t been able to test this, since I no longer have IIS on my machine. The basic principle should work, I’m not 100% certain of the possibility to pass a JScript function reference from VBScript. You might have to write a small custom wrapper function for the JSON.stringify call in JScript:

<script runat="server" language="JScript">    function JSONStringify(object) {        return JSON.stringify(object, vbsStringifier);    }</script>

after which you can simply adjust the VBScript call:

<%    Response.Write JSONStringify(oProd)%>

I ended up writing a function to serialize the Dictionary type myself. Unfortunately, you'll have to go in and do a find & replace on any failed dictionary serializations. ({}) I haven't the time to figure out an automated way to do this. You're welcome to fork it on BitBucket.

Function stringifyDictionary( key, value, sp )  dim str, val  Select Case TypeName( sp )    Case "String"      sp = vbCrLf & sp    Case "Integer"      sp = vbCrLf & Space(sp)    Case Else      sp = ""  End Select  If TypeName( value ) = "Dictionary" Then    str = """" & key & """:{" & sp    For Each k in value      val = value.Item(k)      If Not Right(str, 1+len(sp)) = "{" & sp And Not Right(str, 1+len(sp)) = "," & sp Then        str = str & "," & sp      End If      str = str & """" & k & """: "      If TypeName( val ) = "String" Then        If val = "" Then          str = str & "null"        Else          str = str & """" & escapeJSONString( val ) & """"        End If      Else        str = str & CStr( val )      End If    Next    str = str & sp & "}"    stringifyDictionary = str  Else    stringifyDictionary = value  End IfEnd FunctionFunction escapeJSONString( str )  escapeJSONString = replace(replace(str, "\", "\\"), """", "\""")End Function

This was written as a function to use with JSON.stringify's replace argument (2nd arg). However you cannot pass a VBScript function as an argument. (From my experience) If you were to rewrite this function in JScript you could use it when you're calling JSON.stringify to ensure that Dictionaries do get rendered properly. See the readme on BitBucket for more on that. Here's how I implemented it:

dim spaces: spaces = 2dim prodJSON: prodJSON = JSON.stringify( oProduct, Nothing, spaces)prodJSON = replace(prodJSON, """Specs"": {}", stringifyDictionary("Specs", oProduct.Specs, spaces * 2))

Known issues:

• The closing } for the Dictionary serialization will be the same number of indentations as the properties it contains. I didn't have time to figure out how to deal with that without adding another argument which I don't want to do.

JSON does not inherently encode any type information at all. What JSON enables you to represent is an arbitrary data structure involving either an object or an array of values. Any such object may have an arbitrary number of named properties such that the names are strings and the values are either the constant null, the constants true or false, numbers, strings, objects, or arrays of values.

How such a data structure is realized in any given programming language runtime is your problem :-) For example, when de-serializing JSON into Java, one might use ArrayList instances for arrays, HashMap instances for objects, and native types for simpler values. However, it might be that you really want the objects to be some particular type of Java bean class. To do that, the JSON parser involved would have to be somehow guided as to what sort of objects to instantiate. Exactly how that works depends on the JSON parser and its APIs.

(edit — when I said "no type information at all", I meant for "object" values; clearly booleans, strings, and numbers have obvious types.)