Mutate.update() flakiness?
essiene
I've just started trying out FORKjs (ok... i've just been using it for
all of 30 mins now), and basically, i'm trying to replace all my
prototype.js calls with FORKjs calls. So far, so good, I especially
like the ability to do straight PUTs and DELETEs, without
piggyback'ing on POST. Kudos!!!
I have a funny problem with FORK.Mutate.update(), I've set up a poll,
that looks like (it replaces a projototype Ajax.PriodicalUpdater()
call):
function realtime_status()
{
var el = document.getElementById('status');
new FORK.Ajax(
'GET',
'/status/',
{
onComplete: function(o) {
FORK.Mutate.update(el, o.responseText);
},
after: function(o) {
setTimeout(realtime_status, 10000);
}
}
);
}
It works perfectly, but once in a while, when I'm doing a page
refresh, I get this error in Firebug:
html has no properties
stripScripts(undefined)mutate.js (line 34)
_insert(p#status, undefined, undefined, function(),
function())mutate.js (line 131)
insertBottom(p#status, undefined, undefined)mutate.js (line 165)
update(p#status, undefined, undefined)mutate.js (line 55)
onComplete(Object status=0 statusText=communication failure)main.js
(line 59)
doCallback("onComplete")ajax.js (line 215)
middleCallback()ajax.js (line 312)
handleReadyState4()ajax.js (line 296)
onReadyStateChange()ajax.js (line 223)
onreadystatechange()ajax.js (line 53)
[Break on this error] return html.replace(this.scriptRegExp, '');
I guess this happens when I refresh during a Mutate update, I'm not
sure, but I think this traceback could help point it out to someone
more in the know (aka. Peter :P)
Peter Michaux
On 2/11/07, essiene <ess...@gmail.com> wrote:
>
> I've just started trying out FORKjs (ok... i've just been using it for
> all of 30 mins now), and basically, i'm trying to replace all my
> prototype.js calls with FORKjs calls. So far, so good, I especially
> like the ability to do straight PUTs and DELETEs, without
> piggyback'ing on POST. Kudos!!!
Without piggybacking? You are using ajaxRails.js or not? I don't think
it is a good idea to use straight PUT and DELETE calls in today's web.
That is why Prototype and the Fork ajaxRails.js scripts do piggyback
on POST. Anyway your problem below is with a GET and so this is a
different issue.
Do you have an example posted live?
When you look at the XHR in Firebug's console what do you see for the
GET request's response headers and body?
It looks like o.responseText is empty for some reason. This would mean
the Mutate library is ok and that something is going wrong with with
either ajax.js or your server side script that is responding.
I found an unrelated bug yesterday in ajax.js. On lines 309 and 310
change "status" to "this.status" two times.
Peter
--
Fork JavaScript: http://forkjavascript.org
Essien Essien
Hi,
On 2/11/07, essiene <ess...@gmail.com> wrote:
>
> I've just started trying out FORKjs (ok... i've just been using it for
> all of 30 mins now), and basically, i'm trying to replace all my
> prototype.js calls with FORKjs calls. So far, so good, I especially
> like the ability to do straight PUTs and DELETEs, without
> piggyback'ing on POST. Kudos!!!
Without piggybacking? You are using ajaxRails.js or not? I don't think
it is a good idea to use straight PUT and DELETE calls in today's web.
That is why Prototype and the Fork ajaxRails.js scripts do piggyback
I'm not using Rails anyways, its python framework whose author is ur truly :)
http://simpleweb.essienitaessien.com
Anyways, I don't really like the piggy backing... it makes debugging and
logging difficult, since the web server actually sees a POST, and only
the framework sees the tunnelled PUTs, DELETEs, etc. I properly resource
protect the method handlers and my HTML/Javascript interface just becomes
a normal REST service consumer like it rightly should. And anyways, most of
my applications do have commandline clients as well... so tunnelling doesn't
serve me well. maybe i'm not seeing something clearly though, but doesn't
proper resource protection safeguard the service from random bots/spiders?
No... i changed these to use element.innerHTML = XXXX; And that seemed to solve the problem.
When you look at the XHR in Firebug's console what do you see for the
GET request's response headers and body?
Didn't actually check for those :-s
It looks like o.responseText is empty for some reason. This would mean
the Mutate library is ok and that something is going wrong with with
either ajax.js or your server side script that is responding.
This what i think happened (sorry I can't revert and test now, I have a demo by 9.00am tmrw morning :) ).
This only happened when I manually pressed refresh a couple times too many. It seems to me that that act,
causes the XMLHTTPRequest object connection to drop, and like you say the responseText comes back empty.
Looking thru the code for Mutate.update(), I see there's a call to insertBefore, which calls _insert(),
_insert(), does stripScripts() on the passed in 'html' parameter, but from the traceback i sent, 'html' is said to have
no properties (its not even an empty string!), so stripScripts() borks trying to call .replace on it. If you look at my traceback
again, you'll see the line:
> onComplete(Object status=0 statusText=communication failure)main.js
Which like I suspect the communication failed because I hit reset a few too many times, I guess that once the underlying
XMLHTTPRequest communication fails, responseText is not even an empty string, its just undefined or null, which will cause
'html' to have *no* attributes.
I'm guessing this could be guarded against, by type checking in stripScripts(), and indeed any other point that needs to use
the value returned from responseText().
Hope that helps...
I found an unrelated bug yesterday in ajax.js. On lines 309 and 310
change "status" to "this.status" two times.
Thanks.... patched here now.
In other news... I'm using forkjavascript's ajax.js as the default ajax/js library in simpleweb, I've applied this to svn already,
and the next release will include it.
thanks for a small, neat and efficient library.
Peter Michaux
>
> On 2/11/07, Peter Michaux <peterm...@gmail.com> wrote:
> >
> > On 2/11/07, essiene <ess...@gmail.com> wrote:
> > >
> > > I've just started trying out FORKjs (ok... i've just been using it for
> > > all of 30 mins now), and basically, i'm trying to replace all my
> > > prototype.js calls with FORKjs calls. So far, so good, I especially
> > > like the ability to do straight PUTs and DELETEs, without
> > > piggyback'ing on POST. Kudos!!!
> >
> > Without piggybacking? You are using ajaxRails.js or not? I don't think
> > it is a good idea to use straight PUT and DELETE calls in today's web.
> > That is why Prototype and the Fork ajaxRails.js scripts do piggyback
>
> I'm not using Rails anyways, its python framework whose author is ur truly
> :)
> http://simpleweb.essienitaessien.com
>
> Anyways, I don't really like the piggy backing... it makes debugging and
> logging difficult, since the web server actually sees a POST, and only
> the framework sees the tunnelled PUTs, DELETEs, etc. I properly resource
> protect the method handlers and my HTML/Javascript interface just becomes
> a normal REST service consumer like it rightly should. And anyways, most of
> my applications do have commandline clients as well... so tunnelling doesn't
> serve me well. maybe i'm not seeing something clearly though, but doesn't
> proper resource protection safeguard the service from random bots/spiders?
There is a reason for the POST piggybacking. It has to do with proxys
between the client and the server. Not all proxies can deal with verbs
other than GET, POST, HEAD. This is what I'm told anyway. I think it
would be conservative to look into this in more detail if you are
going to start using other verbs for real. If the Rails folks could do
that I'm sure they would be doing it.
It's a little confusing. What kind of "refresh"? Browser refresh or
some html button you have built in the page? Perhaps you should be
calling the abort() property of the object returned by new
FORK.Ajax()? If there is a communicaiton problem then the solution is
not to touch the mutate code. The solution is to make sure that the
mutate code is only called if the ajax request was successful.
Essien Essien
You're right, I'll have to research this a bit more before I release the
next version of simpleweb. I guess the world would be a better place
if we all just RESTed, but till then... evil abounds :)
I think it
would be conservative to look into this in more detail if you are
going to start using other verbs for real. If the Rails folks could do
that I'm sure they would be doing it.
on point too. hmm...
Initially it happened when I did a form submit (actually a file upload, which is not an ajax request),
which causes the whole page to refresh. It was kinda weird so I did a manual browser page refresh
and found that it was repeatably reproduceable.
Perhaps you should be
calling the abort() property of the object returned by new
FORK.Ajax()? If there is a communicaiton problem then the solution is
not to touch the mutate code. The solution is to make sure that the
mutate code is only called if the ajax request was successful.
Yeah, this would work too. I'll split out the onComplete into onSuccess and onFailure.
Thnx.