Just to keep it in a more concrete level:
1) When the iframe loads, the event handler triggers an asynchronous
post request.
2) When the asynchronous call returns, a call back function is called
to do something with responseText.
3) In our case, the callback is the following:
function(text) {return(text)})
This effectively does nothing: The nett effect is that the load events
generates an asynchronous call to a function which returns a text
string which is not consumed by anybody. The function should look
something like this instead:
function(text) {
window.document.body.appendChild(document.createTextElement(text) )})
that is, it must explicitly do something with the 'text' argument, not
just 'return' it, because there is no 'caller'. (well, that's not
correct; the caller is the onload handler of the GM_xhr object, but it
does nothing with the returned value anyway).
On Sun, Jan 17, 2010 at 9:42 PM, Brian L. Matthews <[email protected]> wrote:
>
>>>> The post() function contains the GM_xmlhttpRequest() function, and (I
>>>> assume) GM_xmlhttpRequest() returns the target page, but it doesn't store
>>>> or
>>>> return the data returned by GM_xmlhttpRequest().
>>>>
>>>> You have this:
>>>>
>>>> function post(url, data, cb) {
>>>> GM_xmlhttpRequest({...});
>>>> }
>>>>
>>>>
>>>> I think you want this:
>>>>
>>>> function post(url, data, cb) {
>>>> return GM_xmlhttpRequest({...});
>>>> }
>>>
>>> I could be wrong, but I think an asynchronous GM_xmlhttpRequest always
>>> returns undefined, and a synchronous request always returns the response
>>> object. The return from the callbacks is ignored, so a return in one of the
>>> callbacks is pointless. If you want the callback to do something with the
>>> data it gets, you have do something explicit with it, which is usually add
>>> it to the page somehow.
>>
>> I think you're right - I forgot about synchronous vs. asynchronous (It's
>> been a while since I used an xmlhttprequest) It's the onload: function
>> defined within the command that is executed on completion of the command,
>> right? So that code needs to specify what to do with responseText (add it to
>> the page, or call another function to process it).
>
> Yes, onload is called when the request is complete (assuming it succeeds,
> onerror is called if it fails), so that's where if you want something done
> with the response (which is the usual case, although not the only one) you
> need to explicitly do something with responseText, like modify the page
> somehow.
>
> Brian
--
You received this message because you are subscribed to the Google Groups
"greasemonkey-users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/greasemonkey-users?hl=en.
