IE - swapDOM
Rune Hansen
Bob Ippolito
On Dec 6, 2005, at 1:48 PM, Rune Hansen wrote:
> Working with MochiKit is fun. Working with IE on the other hand..
>
> I have, for the time being, hit a show stopper (for this particular
> application anyway):
> Using this code:
> return TABLE({'class':'grid','id':'swaptable'},
> THEAD(null, TR(null, TD(null,'ID'),TD(null,'NAME'),TD
> (null,'ACTIVE'))),
> TFOOT(null, TR(null, TD())),
> TBODY(null, map(table_row, rows))
> );
> I'm swapping DOMs to my hearts content - that is, when using
> Firefox/Safari and so on.
> (I'm calling methods to update data in database and I need to
> reload and swap the DOM for each update)
> With IE I get the DOM once. And once more after I restart the browser.
>
> Does anyone know of a way to force IE to call the method again?
You might just want to try having the table in the HTML, and doing
replaceChildNodes("tbody_id", map(table_row, rows))
Anyway, you didn't show enough code to reproduce the problem... so
it's kinda hard to say much else.
-bob
John Wehr
after - you swap. Not 100% sure but I think that's the issue.
Rune Hansen
On Dec 6, 2005, at 1:48 PM, Rune Hansen wrote:
Working with MochiKit is fun. Working with IE on the other hand..I have, for the time being, hit a show stopper (for this particular application anyway):Using this code:return TABLE({'class':'grid','id':'swaptable'},
THEAD(null, TR(null, TD(null,'ID'),TD(null,'NAME'),TD(null,'ACTIVE'))),
TFOOT(null, TR(null, TD())),TBODY(null, map(table_row, rows)));I'm swapping DOMs to my hearts content - that is, when using Firefox/Safari and so on.(I'm calling methods to update data in database and I need to reload and swap the DOM for each update)With IE I get the DOM once. And once more after I restart the browser.Does anyone know of a way to force IE to call the method again?
You might just want to try having the table in the HTML, and doing replaceChildNodes("tbody_id", map(table_row, rows))Anyway, you didn't show enough code to reproduce the problem... so it's kinda hard to say much else.-bob
Bob Ippolito
On Dec 6, 2005, at 2:15 PM, Rune Hansen wrote:
> My problem is that IE calls the loadJSONDoc in function
> requestSourceColl once and only once. It seems like it's cached
> somehow. The alert message in the function is displayed every time.
>
> I have set <META HTTP-EQUIV="Pragma" CONTENT="no-cache"/>, <META
> HTTP-EQUIV="Expires" CONTENT="-1"/> which according to
> microsoft.com should negate any form of caching.
Ok, so it sounds like your problem has nothing whatsoever to do with
DOM, it's the fact that IE is very aggressive at caching. You need
to set the appropriate HTTP headers on the JSON, or just add a random
slug to the JSON URL.
http://en.wikipedia.org/wiki/
XMLHttpRequest#Microsoft_Internet_Explorer_Cache_issues
-bob
Peter Hansen
> Ok, so it sounds like your problem has nothing whatsoever to do with
> DOM, it's the fact that IE is very aggressive at caching. You need to
> set the appropriate HTTP headers on the JSON, or just add a random slug
> to the JSON URL.
>
> http://en.wikipedia.org/wiki/
> XMLHttpRequest#Microsoft_Internet_Explorer_Cache_issues
From the sounds of that, using POST instead of GET would avoid the
issue. It appears MochiKit.Async uses GET to do its work. What would
be the downside of using POST instead?
-Peter
Bob Ippolito
That sounds absolutely terrible.
At least adding some random stuff to the URL doesn't change the
semantics, but it's not typically that hard to add a header or two on
the server side to remove the need for that.
-bob
Peter Hansen
As someone who is using AJAX to access only his own servers (i.e. I'm in
control of both sides) I don't fully understand why it would be
absolutely terrible. From my point of view, POST vs. GET is a total
wash. My server code generally doesn't know which was used (for forms,
anyway... am I off-base in the world of AJAX services?).
I assume there are services where you *must* access it using only GET.
And, since MochiKit doesn't use POST even as an option, I also assume
there are no useful AJAX services which require a POST. And since there
are limits on the size of GET URLs in many places (as I recall) I
further assume nobody is concerned about being force to use GET.
As a non-expert in this whole area, I'd be happy to have my assumptions
all shot down... :-)
-Peter
Josu Oyanguren
just a little question.
In MockiKit.DOM.formContents, in the test for checked inputs, i think it has to check for checkboxes too. Something like:
if (elem.tagName == "INPUT"
&& (elem.type == "radio" || elem.type == "checkbox")
&& !elem.checked
)
don't you?
Regards,
Josu.
Bob Ippolito
On Dec 6, 2005, at 6:58 PM, Peter Hansen wrote:
>
> Bob Ippolito wrote:
>> On Dec 6, 2005, at 6:20 PM, Peter Hansen wrote:
>>> Bob Ippolito wrote:
>>>> http://en.wikipedia.org/wiki/
>>>> XMLHttpRequest#Microsoft_Internet_Explorer_Cache_issues
>>>
>>> From the sounds of that, using POST instead of GET would avoid
>>> the issue. It appears MochiKit.Async uses GET to do its work.
>>> What would be the downside of using POST instead?
>> That sounds absolutely terrible.
>> At least adding some random stuff to the URL doesn't change the
>> semantics, but it's not typically that hard to add a header or two
>> on the server side to remove the need for that.
>
> As someone who is using AJAX to access only his own servers (i.e.
> I'm in control of both sides) I don't fully understand why it would
> be absolutely terrible. From my point of view, POST vs. GET is a
> total wash. My server code generally doesn't know which was used
> (for forms, anyway... am I off-base in the world of AJAX services?).
It's just semantics. POST requests are for posting data, and
loadJSONDoc doesn't do that.
Since you control both sides, you can issue proper cache headers, or
a URL based workaround.
> I assume there are services where you *must* access it using only
> GET. And, since MochiKit doesn't use POST even as an option, I also
> assume there are no useful AJAX services which require a POST. And
> since there are limits on the size of GET URLs in many places (as I
> recall) I further assume nobody is concerned about being force to
> use GET.
There are plenty of useful AJAX services which require a POST, but
loadJSONDoc and doSimpleXMLHttpRequest are only designed for simple
idempotent operations. As you may have noticed, most of MochiKit is
currently focused on just making JavaScript less painful, not
facilitating domain specific things.
There are several reasons that MochiKit currently doesn't have baked-
in support for anything but very simple GET
- That's all we (as in the sponsors/developers of MochiKit) need
right now
- The support for anything but GET and POST is poor cross-browser
(this is largely Safari's fault)
- There are at least three common ways to send POST data (url
encoded, JSON, and XML)
- It's often the case that you would also like to set custom headers
when doing something other than GET
MochiKit does support all of these rather well, but there simply
isn't a one-liner. We haven't come up with a good one-liner that's
generic enough to make it into MochiKit for the above reasons.
Here's how you do Anything But Simple GET:
1. getXMLHttpRequest() to get yourself an XMLHttpRequest object
2. Give it a method and a URL
3. Set any custom headers you need
4. Serialize your content for the post (typically via serializeJSON
or queryString)
5. dispatch with sendXMLHttpRequest(req, theContent)
I'm definitely open for API ideas, but I have a feeling it's just
going to be something like:
aDeferred = dispatchXMLHttpRequest({
method: "POST",
url: "...",
headers: [
["Content-Type", "text/x-json"]
],
content: serializeJSON(...)
}).addCallback(evalJSONRequest)
I'm just not sure it's worth bothering with that, because it seems
almost harder to deal with than a plain old XMLHttpRequest object.
-bob
Bob Ippolito
With no value attribute specified, the current 1.1 code works fine,
but if a value attribute is set then it does not. I've committed a
fix that will be in 1.2.
-bob
John Wehr
postJSONDoc = function (url, postVars) {
var req = getXMLHttpRequest();
req.open("POST", url, true);
req.setRequestHeader("Content-type", "application/x-www-form-
urlencoded");
var data = queryString(postVars);
var d = sendXMLHttpRequest(req, data);
return d.addCallback(evalJSONRequest);
}
(Credit goes to Bob for writing it some time ago, I've used it
extensively on Tagalag.)
> baked-in support for anything but very simple GET
Ian Bicking
> - That's all we (as in the sponsors/developers of MochiKit) need right now
> - The support for anything but GET and POST is poor cross-browser (this
> is largely Safari's fault)
> - There are at least three common ways to send POST data (url encoded,
> JSON, and XML)
> - It's often the case that you would also like to set custom headers
> when doing something other than GET
Well, I think there's at least one obvious implementation would be
symmetric with doSimpleXMLHttpRequest, like:
function postSimpleXMLHttpRequest(url/*, ...*/) {
var self = MochiKit.Async;
var req = self.getXMLHttpRequest();
var postBody = ''
if (arguments.length > 1) {
postBody = m.queryString.apply(null, m.extend(null,
arguments, 1));
}
req.open("POST", url, true);
req.setRequestHeader(
'Content-type', 'application/x-www-form-urlencoded');
return self.sendXMLHttpRequest(req, postBody);
}
That's the only kind of non-GET request I've needed so far, and the only
kind I expect to need for some time. I can imagine a JSON body, but I
personally I don't need it, and I think a normal POST request is
generally more likely to be useful.
While it didn't take me long to figure this out on my own, it also
wasn't entirely obvious. I think this would cover 80% of all POST
requests (and probably much more than that; it covers 100% of all the
POSTs I've needed ;).
--
Ian Bicking / ia...@colorstudy.com / http://blog.ianbicking.org
Jorge Godoy
> It's just semantics. POST requests are for posting data, and loadJSONDoc
> doesn't do that.
Isn't there also some convention for "reloading" pages? POSTed pages would
issue a warning that you're relaoding a page where you submitted some
information while GETed pages would happily reload without any warning?
--
Jorge Godoy <jgo...@gmail.com>
Dieter Lunn
---------- Forwarded message ----------
From: Dieter Lunn <code...@gmail.com>
Date: Dec 7, 2005 10:50 AM
Subject: Re: [mochikit] Re: GET vs POST in MochiKit.Async (was Re: IE - swapDOM)
To: Jorge Godoy <jgo...@gmail.com>
Not with XMLHttpRequest. However because POST allows different data types beyond GET it is difficult to come up with one function to rule them all. I myself use JSON and previously I used XML.
Dieter Lunn
http://www.coder2000.com
--
Dieter Lunn
http://www.coder2000.com