On Aug 12, 9:38 pm, "Michael Geary" <[EMAIL PROTECTED]> wrote:
> JSON syntax is indeed executable JavaScript code - almost. It is a subset of
> the JavaScript object literal notation.
> ...
> Now try this:
>
> function myCallback( json ) { alert( json.test ); }
>
> myCallback({ "test":"value" }); // JSONP
>
> It should open an alert box with "value" in it. Straightforward stuff,
> right?
Awesome. I think I am getting the idea now. I can better relate to
what you mean it is part of the JS object system. Its a way to store
data in JS memory per se.
So in our server WCT template system, when we do this:
@SET test = value@
or
@SET nodes[] = [1,"mike", "00:05", "Reading Mail"]@
to load template memory, we are effectively doing the similar thing
with JS memory at the client side?
But with JSON, we have added power of "name association" per field.
If WCT had same name association syntax, it would be:
@SET nodes[] = [node: 1, user: "mike", time: "00:05", activity:
"Reading Mail"]@
Correct? if so, then I got the "AH HA!" :-)
Hmmmmmmmmm, in fact, with this revelation, I can add a new @JSON@ WCT
command that will help create a migration bridge with existing
applications that are using WCT memory space.
So for example, an WCX application populates WCT memory such that:
@SET nodes[1].node = 123@
@SET nodes[1].user = "mike"@
@SET nodes[1].time = "1:00"@
@SET nodes[1].activity="Reading Mail"@
@SET nodes[2].node = 456@
@SET nodes[2].user = "hector"@
@SET nodes[2].time = "2:30"@
@SET nodes[2].activity="Writing Mail"@
I can offer a new @JSON variable_spec@ command that will create JSON
code for the client side to handle:
@JSON Nodes*@
will create:
{
"nodes": [
{
"node": 123,
"user": "Mike",
"time": "1:00",
"activity", "Reading mail"
},
{
"node": 456,
"user": "Hector",
"time": "2:30",
"activity", "Writing mail"
}
]
}
Am I on the right track here? Oh man, this will greatly simplify
things to better support backward compatibility!
In other words, like right now, html-who.wcx, reads a WHO.HTM template
to render the HTML display. If someone wanted to use the WCX as a
JSON/XML service, then simply passing a format option to use a
different WHO-JSON.HTM template using this @JSON@ command to print
JSON code would do the trick! I don't have to alter the WCX!
> That test() function call is JSONP, and it's a complete executable statement
> that will *run some code*.
>
> Why is that important?
>
> Suppose you want to support cross-domain downloads of your REST API directly
> from JavaScript without using a proxy server on the customer's website. The
> best way to do that is with a dynamic script tag. But to use the data, you
> need to have the script *run some code*. The way to do that is with a
> function call as in that last example.
>
> That's all JSONP is: JSON data wrapped inside a function call. You define
> the function before loading the dynamic script tag. When the script loads,
> it calls that function and passes it the JSON data as an argument.
Ok, but I am not sure how to relate the "cross-domain" functionality
here. I see from your example, the usefulness but not from a "cross
domain" standpoint. Don't Original Site Policy contrainst still apply
regardless of how this JSON data is generated?
If you are referring to "tag injection" tricks, then I guess I can see
how its possible.
> This is why I've been asking whether you want to allow your customers to
> access your REST API directly, cross-domain from JavaScript code. If you do,
> then you need to use dynamic script tags and JSONP. If you require your
> customer to set up a forwarding proxy on their own server, then they can use
> AJAX.
I still don't see how XS relate to this. Let me read this a few more
times and think about it..
ok, best to do with real example:
We already offer some REST API functionality, either in authenticated
or non-authenticated (public) mode.
Here is one - Retrieves a XML list of the new files uploaded in the
last 100 days.
http://www.winserver.com/public/code/html-wcrpc.wcx?cmd=rpcNewFiles&args=days=100
This produces a XML output for a public request AT our server. For
all intent and purposes the WCX exposes our Server API for a non-
authenticated session thread context and 100% secured managed local
site API call.
Now, for the second part, the customer may want to create a local
script/web page at his web server that collects various "new files"
listing from various Wildcat! sites.
So he might have 3-4 calls in his local web page script:
var url = "/public/code/html-wcrpc.wcx?
cmd=rpcNewFiles&args=days=100";
$('#window1').load("http://site1.com"+url);
$('#window2').load("http://site2.com"+url);
$('#window3').load("http://site3.com"+url);
>From what I understand, browsers will restrict cross site AJAX calls,
so we have to provide a local WCX proxy in order to customes to do
remote AJAX calls from their local site web page:
var url = "/public/code/html-wcrpc.wcx?
cmd=rpcNewFiles&args=days=100";
$('#window1').load("/code/html-ajaxproxy", "http://site1.com"+url);
$('#window2').load("/code/html-ajaxproxy", "http://site2.com"+url);
$('#window3').load("/code/html-ajaxproxy", "http://site3.com"+url);
Correct?
If so, then other than the JSON format vs XML format, how does JSONP
resolve this XSS restriction without using a local proxy that is
specifically design to managed this request?
--
HLS
