nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

"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)

Trouver plus de publications taguées avec

Accepted answers

All comments

TyroneLigon

I have a similar error using the 2.7 and 2.8 APIs; the error occurs when adding an image layer to the map. However, while using Firebug, the call to connect to the image layer returns JSON from the server, and it looks correct. Can't figure out what's causing the error.

HugoAhlenius

I got a similar error - if I don't add a certain graphics layer to the map, then the print action works ok

JeffJacobson

The first thing I would do is your JavaScript code* through either JSLint or JSHint to check for errors.

* If you are not writing JavaScirpt, but it is instead being generated by Kurogo, then run the generated JavaScript code through JSLint or JSHint.

StephenLead

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

Can you point us to the original demo, too? I can't find it online.

Thanks

derekswingley1

I think this conversation is muddying this thread

Agreed. Apologies to OP for highjacking the thread. Still hoping to see a simple repro case.

__Rich_

The reason I recommended an alternative approach is that in ~4 years of developing with the API, I cannot recall a single instance of solving a problem by using uncompressed vs. compressed Dojo source files. Is that how you're set up locally? To me, suggesting this approach seems like a rabbit hole that could easily be avoided by following the normal web dev approach of eliminating complexity to create a simple repro case, sharing that with the community and asking for help.

My setup and how I adjust it are based on the scenario I find myself in day to day, horses for courses, being adaptable and having the tools/knowledge to solve problems in the most appropriate way for the situation at hand, I find is a plus.

I think this conversation is muddying this thread, feel free to PM me if you like...

derekswingley1

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.

The reason I recommended an alternative approach is that in ~4 years of developing with the API, I cannot recall a single instance of solving a problem by using uncompressed vs. compressed Dojo source files. Is that how you're set up locally? To me, suggesting this approach seems like a rabbit hole that could easily be avoided by following the normal web dev approach of eliminating complexity to create a simple repro case, sharing that with the community and asking for help.

__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.

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_

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.

uncompressed.jpg

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.

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.

__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?

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

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.

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.

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.