Using IE8 v. FF 3.5.7, MT 1.2.3, windows XP SP 3.
Request.response.xml seems not to be a mootools extended object. I.e.
it doesn't have method 'get' nor does it have other mootools methods.
With Request, I retrieve some xml data from a server. I want to walk
through this data and retrieve some attribute data. In FF, I use the
get method, but it's not available in IE. (it's available in FF,
Opera, Chrome, Flock).
Unfortunately, I cannot tell my clients not to use IE, so I need an
other solution. Any idea's? My best hope is that IE objects would be
mootools extended. There might be other objects that are not.
Wo.
Wrapping in $() should fix up such irregularities, no?
IE8 did add support for extending natives, and IIRC Moo will be
expanding their feature detection accordingly (don't remember if in
1.3 or 2.0).
-- Sandy
On Jan 20, 10:11 am, Sanford Whiteman <sa...@cypressintegrated.com>
wrote:
> > Unfortunately, I cannot tell my clients not to use IE, so I need an
> > other solution. Any idea's? My best hope is that IE objects would be
> > mootools extended. There might be other objects that are not.
>
> Wrapping in $() should fix up such irregularities, no?
No, it doesn't. i.e. $(request.response.xml) returns null becaouse
request.response.xml.toElement does not exist.
>
> IE8 did add support for extending natives, and IIRC Moo will be
> expanding their feature detection accordingly (don't remember if in
> 1.3 or 2.0).
Well, in the mean time, I have to write another routine I guess.
>
> -- Sandy
You might try wrapping the IE `xml` attribute using Elements.from:
http://mootools.net/shell/2dupv/2/
-- S.
During testing, I've discoverd one thing. IE requires that the xml has
a name space. Without it, Elements.from returns a large flat array
with all elements. FF doesn't require xmlns but handles it without
problems.
~W~
On 21 jan, 05:01, Sanford Whiteman <sa...@cypressintegrated.com>
wrote:
[1] Because it is not always available: this example is an RSD feed,
among hundreds of popular XML-based formats. When you don't control
the service nor an intermediate gateway, you don't control the format.
[2] Becase XML may be the native retrieval (or even storage) format:
modern RDBMSs have FOR XML and store XML in the database. I don't know
if any have native JSON.
[3] Because XML is self-documenting and, despite its relatively heavy
weight, is a much more robust format that many find easier to read in
plain text.
Not that JSON is a bad thing, but the two are not truly
interchangeable.
-- Sandy
We talked about this a while back in another thread. I think IE is
doing the right thing. After all, (X)HTML does not have an
anything-goes DTD. If you want to inject els into the DOM, validating
them against the allowed tags or expecting them to declare a NS seems
sensible to me... it is not in a spec but I think to reinforce
standards in general this would be a good practice for other browsers.
-- Sandy
I agree totaly. I find JSON much easier to use. But I cannot change
the XML from my server to JSON because other people depend on it. For
myself I've written an xml2json translation so I can easily use the
results. I only have to parse the xml once and then my javascript
application can use that.
I've written a test to show the namespace problem in IE versus other
browsers: http://mootools.net/shell/ydfXe/
I've written a test to compare xml2json conversion with mootools
routines and without them. Both run on most browsers. The moo
conversion uses Elements.from, the pure one uses xml.documentElement.
The pure conversion is much faster so I'll go for that one. See:
http://mootools.net/shell/Hug2A/.
W.