"json is undefined"

[KevinPerry1]

I'm a long-time programmer, but new to using the ArcGIS API.  We are attempting to implement a website based on the Kurogo framework, an open source webapp framework that includes a mapping module which interfaces with ArcGIS map services.  Very cool.  They provide a demo which uses a nice map of Boston, and the demo runs on our server just fine.  When we attempt to re-configure it to use a locally-created map, though, it blows up in the ArcGIS JSAPI code, with "TypeError: json is undefined".  The stack trace from FireBug (below) is not very helpful, considering that lines 14 and 48 of the JSAPI v=2.4compact code are each a huge mass of unreadably compressed JS.

Obviously, I'll be posting a question on the Kurogo forum shortly as well, but I was wondering whether anyone here has useful guidance on how one is supposed to debug such problems buried deep in the JSAPI code?  Or - hoping for a miracle - perhaps a suggestion about exactly what is wrong in this particular case.  Thanks.

Stack trace:

TypeError: json is undefined
()?v=2.4compact (line 48)
()?v=2.4compact (line 14)
()?v=2.4compact (line 48)
()?v=2.4compact (line 14)
()?v=2.4compact (line 48)
()?v=2.4compact (line 14)
_144()?v=2.4compact (line 14)
_142()?v=2.4compact (line 14)
()?v=2.4compact (line 14)
_144()?v=2.4compact (line 14)
_142()?v=2.4compact (line 14)
()?v=2.4compact (line 14)
()?v=2.4compact (line 48)
()?v=2.4compact (line 14)
()?v=2.4compact (line 14)

[derekswingley1]

Look for references to a variable named "json" in your code, or possibly the Kurogo code. That should point you in the right direction for the source of this error.

[KevinPerry1]

Nope, there are no variables named "json" in any of the application code, as far as I can tell.  And as I mentioned, the error seems to be coming from code within the ArcGIS JSAPI code, not the application code - unless FireBug is lying to me.  One guess would be that it's happening in the load callback of a dojo.xhrGet() call, where it's attempting to convert the (JSON) result of a GET into a JS object.  This would presumably be a dojo.xhrGet call made by something in the ArcGIS code. The Kurogo code is just a thin layer on top of the ArcGIS JSAPI. 

But I don't know how to figure out what, exactly, it is trying to do, that's failing.  I don't see any obviously bad requests when looking at a "LIve HTTP Headers" log, so maybe it's not xhrGet after all.

Still stumped.

[StephenLead]

the demo runs on our server just fine.  When we attempt to re-configure it to use a locally-created map, though, it blows up in the ArcGIS JSAPI code, with "TypeError: json is undefined".

Can you strip the example right back so it's just a simple map with a single basemap, and see if that works? Then progressively add features until it breaks.

Are you able to share your site's URL?

Steve

[__Rich_]

v2.4 shipped with uncompressed version of dojo.xd.js.uncompressed.js so you could try serving that, then if the cause is in there it will at least be readable.  If it's in the ESRI stuff then you could pretty-print the JS on download and attach breakpoints (manually, if it's not automatically breaking)

Some versions of the JSAPI shipped with uncompressed versions of (nearly?) every file so that makes debugging, much easier, looks like v3.0 might have been the last though - any chance you can upgrade?

Otherwise, is there anything in your network trace?  e.g. HTTP status 500 responses from the server or malformed JSON etc.  (I can see you've been looking at the ""LIve HTTP Headers" - don't know if you mean client or server side?)

Have you got all proxy paths etc. configured correctly?

[derekswingley1]

v2.4 shipped with uncompressed version of dojo.xd.js.uncompressed.js so you could try serving that, then if the cause is in there it will at least be readable.  If it's in the ESRI stuff then you could pretty-print the JS on download and attach breakpoints (manually, if it's not automatically breaking)

This is not true, 3.0 is the only version of the API where uncompress files were (mistakenly) included with the API download.

[derekswingley1]

Can you strip the example right back so it's just a simple map with a single basemap, and see if that works? Then progressively add features until it breaks.

Are you able to share your site's URL?

Doing one or both of these will be the simplest way for us to help you find a fix.

[__Rich_]

This is not true, 3.0 is the only version of the API where uncompress files were (mistakenly) included with the API download.

What's not true, Derek?

This?  "v2.4 shipped with uncompressed version of dojo.xd.js.uncompressed.js"

[ATTACH=CONFIG]17152[/ATTACH]

Oh I see, the bit about some versions shipping with nearly every file uncompressed - yep, probably just v3.0 (I was a bit over zealous/hopeful there), but it was a very helpful 'mistake' someone made 🙂

Either way the dojo file is uncompressed and might help this chap find his issue.

[derekswingley1]

Either way the dojo file is uncompressed and might help this chap find his issue.

My opinion is that the best approach to getting to the bottom of this error is to post a simple page that can reproduce the error. That way we'll quickly be able to find out if the error being described is in his code or in the JS API.

It's more trouble than it's worth to configure your local environment to use uncompressed Dojo files, IMO.

[__Rich_]

My opinion is that the best approach to getting to the bottom of this error is to post a simple page that can reproduce the error. That way we'll quickly be able to find out if the error being described is in his code or in the JS API.

It's more trouble than it's worth to configure your local environment to use uncompressed Dojo files, IMO.

I agree that is one approach, depends how easy/quick it is for the OP to snap off just the bit that's causing issues, always worth having other approaches.  To return that one dojo uncompressed file (for many people) means changing one line in the handler that returns it, IMO that's not a hardship.

Not everyone is aware of all the options.