JSON extracting data

[Reiver]

hi,
I am told that the data I need is held in JSON format and is
available at the following address
http://ws.geonames.org/gtopo30JSON?lat=47.01&lng=10.2

could somebody show me how to extract that data in javaScript

completely new to JSON and the examples I can find on the web are far
to complicated, could anybody go through the basics with me.

 

[Robert Tomsick]

hi,
I am told that the data I need is held in JSON format and is
available at the following address
http://ws.geonames.org/gtopo30JSON?lat=47.01&lng=10.2

could somebody show me how to extract that data in javaScript

completely new to JSON and the examples I can find on the web are far to
complicated, could anybody go through the basics with me.

JSON *is* Javascript -- you access data in JSON much the same way as
you'd access any other sort of data in Javascript.

Have you checked out the documentation and introduction at JSON.org ?

 

[Reiver]

JSON *is* Javascript -- you access data in JSON much the same way as
you'd access any other sort of data in Javascript.

Have you checked out the documentation and introduction at JSON.org ?

Yes, unfortunately it dosnt tell me what I need to know. Lets have
another go at explaing what I am trying to learn. For sake of example
lets assume the following URL http://ws.geonames.org/gtopo30JSON?lat=47.01&lng=10.2
is a link to the array of named pairs {w:2,e:3,r:4}

What would be the correct syntax of importing that data into a script,
I know the following would not work but it may give you an idea of
what I am trying to achieve.

var cCdes = newArray('http://ws.geonames.org/gtopo30JSON?
lat=47.01&lng=10.2');
alert(cCdes.e);

 

[Thomas 'PointedEars' Lahn]

JSON *is* Javascript -- you access data in JSON much the same way as
you'd access any other sort of data in Javascript.
Nonsense.

Have you checked out the documentation and introduction at JSON.org ?

Have you?


PointedEars

 

[Jorge]

hi,
 I am told that the data I need is held in JSON format and is
available at the following address http://ws.geonames.org/gtopo30JSON?lat=47.01&lng=10.2

could somebody show me how to extract that data in javaScript

completely new to JSON and the examples I can find on the web are far
to complicated, could anybody go through the basics with me.

See:
http://www.geonames.org/export/JSON-webservices.html

The key is the callback. You *must* provide a callback. E.g.:

copy-paste this in the console:

(function (scriptElement) {
window.display= function display (receivedObject, txt, property) {
txt= "";
for (property in receivedObject) {
if (receivedObject.hasOwnProperty(property)) {
txt+= property+ ": "+ receivedObject[property]+ "\r\n";
}
}
alert(txt);
}
scriptElement= document.body.appendChild(document.createElement
('script'));
scriptElement.type= "text/javascript";
scriptElement.src= "http://ws.geonames.org/gtopo30JSON?
lat=47.01&lng=10.2&callback=display";
})();

And it should alert the data.

 

[Scott Sauyet]

I think of myself as a fairly competent JavaScript user, but I'm
curious as to the reason for a syntactic convention here. What's the
advantage of the following:

(function (scriptElement) {
// [ ... ]
  scriptElement= // [ ... ]
// [ ... ]
})();

over the (arguably) clearer:

(function () {
// [ ... ]
var scriptElement= // [ ... ]
// [ ... ]
})();

Just wondering...

-- Scott

 

[Jorge]

I think of myself as a fairly competent JavaScript user, but I'm
curious as to the reason for a syntactic convention here.  What's the
advantage of the following:

(function (scriptElement) {
  // [ ... ]
  scriptElement= // [ ... ]
  // [ ... ]
})();

over the (arguably) clearer:

    (function () {
      // [ ... ]
      var scriptElement= // [ ... ]
      // [ ... ]
    })();

Just wondering...

I write the code, and when I'm finished, I "parse" the source
searching for ought-to-be-var-declarations and copy-paste one
identifier after the other -there, in the parameters list- as if they
were parameters. There's no advantage, it's just that I've got used to
do it so. At some point later -sometimes- it makes me wonder how many
of them were the actual, expected -required ?- parameters, if
any...

Some people prefer to declare the vars at the point where they first
use them in the source (as in your "arguably clearer" example), I
don't like that. I agree that it's easier to do that during the
initial writing phase: "I need a var here, therefore I just type var
'whatever' here and I'm done". Later, it bites you back when you want
to check if/that a certain var has been properly declared, because
you've got to look everywhere from top to bottom searching for the var
'whatever' declaration. It's much easier/faster to look -just- into
the parameter list, imo.

 

[Thomas 'PointedEars' Lahn]

I think of myself as a fairly competent JavaScript user, but I'm
curious as to the reason for a syntactic convention here. What's the
advantage of the following:

(function (scriptElement) {
// [ ... ]
scriptElement= // [ ... ]
// [ ... ]
})();

over the (arguably) clearer:

(function () {
// [ ... ]
var scriptElement= // [ ... ]
// [ ... ]
})();

Just wondering...

There is no advantage if no arguments are passed.


PointedEars

 

[Eric Bednarz]

Some people prefer to declare the vars at the point where they first
use them in the source (as in your "arguably clearer" example), I
don't like that. I agree that it's easier to do that during the
initial writing phase: "I need a var here, therefore I just type var
'whatever' here and I'm done". Later, it bites you back when you want
to check if/that a certain var has been properly declared, because
you've got to look everywhere from top to bottom searching for the var
'whatever' declaration.

That’s the royal “youâ€, I suppose.

In my editor, for example, undeclared and redeclared variables are
simple to spot as part of syntax highlighting (I actually see way
more redeclared ‘i’ variables in multiple for-loops than undeclared
variables in other people’s code ;-).

 

[David Mark]

That’s the royal “you”, I suppose.

In my editor, for example, undeclared and redeclared variables are
simple to spot as part of syntax highlighting (I actually see way
more redeclared ‘i’ variables in multiple for-loops than undeclared
variables in other people’s code ;-).

JSLint is good at spotting those too. No bizarre arguments-as-
variables scheme needed.

 

[Jorge]

JSLint is good at spotting those too.  No bizarre arguments-as-
variables scheme needed.  

LOL, after all your ramblings, you're actually using JSLint ?

 

[Scott Sauyet]

There's no advantage, it's just that I've got used to do it so.

Bummer. I was hoping to learn some arcane secret here.

Some people prefer to declare the vars at the point where they first
use them in the source (as in your "arguably clearer" example), I
don't like that.

I'm conflicted about that. Sometimes I really want a common location
at the top for all my "var" declarations, so I always know where to
find them; this consistency can be helpful. But then I'm often
frustrated looking at something further down not knowing at a glance
whether this particular variable is freshly defined here or is
replacing some earlier definition. So as always when I'm conflicted
about something, I'm not overly consistent about it.

In any case, thanks for the response.

Cheers,

-- Scott

 

[Thomas 'PointedEars' Lahn]

There's no advantage, it's just that I've got used to do it so.

Bummer. I was hoping to learn some arcane secret here.

Some people prefer to declare the vars at the point where they first
use them in the source (as in your "arguably clearer" example), I
don't like that.

I'm conflicted about that. [...]

Your gut feeling does not mislead you here. Defining local variables as
named arguments exposes them to the calling context, therefore carries with
it the risk of code injection. For example, if you happen to forget to
initialize the value, the calling execution context can take control over
the inner workings of the called one until a value is explicitly assigned:

/* bar is just supposed to be a local variable */
function foo(bar)
{
/* forgotten initialization */
// bar = false;

if (bar) return 42;

bar = 10;

// ...

if (bar < 42) return 0;

// ...

return 1;
}

/* 0 */
foo();

/* 42 */
foo(1);

You can also see that this bad style forces you to initialize each and every
named argument used as a local variable (regardless if you ever use it in
the process, consider early returns and the like) if you want to prevent the
calling context from taking control.

Hopefully, now you have learned something.


PointedEars

 

[Scott Sauyet]

I'm conflicted about that. [...]

Your gut feeling does not mislead you here.  Defining local variables as
named arguments exposes them to the calling context, therefore carries with
it the risk of code injection.  For example, if you happen to forget to
initialize the value, the calling execution context can take control over
the inner workings of the called one until a value is explicitly assigned:

Well, that's not what my conflict was about. It was a matter more of
coding *style* than one of semantic difference.

You're right of course that actual usable function parameters are ill-
conceived substitutes for local variables, but Jorge's example was
different as it involved an anonymous function executed immediately,
and didn't suffer from the problem you describe, to wit:

(function(myVar) {
// define and use myVar
})();

I frequently use a superficially similar pattern:

(function(myVar) {
// use myVar
})(myValue);

and when I saw Jorge's code, I was assuming he was doing something
like this. When I noticed that he didn't pass a parameter for the
variable, I wondered if there was something deep in the
implementations of JS that perhaps used less memory for a function
argument than a local variable or made it easier to garbage-collect
one. It looks as though there was nothing of the sort going on.

Hopefully, now you have learned something.

Maybe, but it's not the deep, dark secrets I was imagining!

Thanks,

-- Scott

 

[Thomas 'PointedEars' Lahn]

Well, that's not what my conflict was about. It was a matter more of
coding *style* than one of semantic difference.

In this case, both apply, would you not say?

[...]
I frequently use a superficially similar pattern:

(function(myVar) {
// use myVar
})(myValue);

Yes, it helps to avoid unwanted closures and to solve the "`this' problem"
without another variable or inefficient wrapper.

and when I saw Jorge's code, I was assuming he was doing something
like this. When I noticed that he didn't pass a parameter for the
variable, I wondered if there was something deep in the
implementations of JS that perhaps used less memory for a function
argument than a local variable or made it easier to garbage-collect
one. It looks as though there was nothing of the sort going on.

Exactly. And I, too, find it confusing to define arguments when nothing is
supposed to be passed *there*. (There are other occasions where it should
not be confusing as long as the signature is clear [e.g., per JSdoc]; not
all arguments need to be named.)


PointedEars

 

[David Mark]

LOL, after all your ramblings, you're actually using JSLint ?

Here's a thought. Search the archive for my name and "JSLint".

 

[Jorge]

Here's a thought.  Search the archive for my name and "JSLint".

Here's another: do a search for his name and crockford.

 

[Jorge]

(...)
For example, if you happen to forget to initialize the value,
the calling execution context can take control over
the inner workings of the called one

If you happen to forget to declare any local var, it will be exposed
as well in some outer context, probably the global one.

You can also see that this bad style forces you to initialize each and every
named argument used as a local variable (regardless if you ever use it in
the process, consider early returns and the like)

I told you before -and tell you again-, Pointy: if you don't -ever-
use any uninitialized vars all will be fine.

Just follow my advice and forget these "code injection" fairy tales.

Hopefully, now you have learned something.

Yes. That you don't change.

 

[Jorge]

Bummer.  I was hoping to learn some arcane secret here.  


I'm conflicted about that.  Sometimes I really want a common location
at the top for all my "var" declarations, so I always know where to
find them; this consistency can be helpful.  But then I'm often
frustrated looking at something further down not knowing at a glance
whether this particular variable is freshly defined here or is
replacing some earlier definition.  So as always when I'm conflicted
about something, I'm not overly consistent about it.

For that, an editor with panes like the one in XCode is a good thing:
you can be seeing the line with the declarations in a -small- pane at
the top while freely scrolling in the 2nd -bigger- pane along the body
of the function.

In any case, thanks for the response.

You're welcome.
Cheers,

 

[Jorge]

If you happen to forget to declare any local var, it will be exposed
as well in some outer context, probably the global one.

Sheesh, the more I think about it, the more clearly I see the caliber
of the nonsense that you've said, Pointy, because no matter what you
do, there's no single line of code in a JS program that's not exposed:
just set a breakpoint, enter the debugger and freely inject or touch
whatever you want.