Err, I small detail I, uhh, ahem, forgot to mention. I wasn't testing
against Safari. :^) I was testing against the WebKit nightly build.
--Paul
Andrew Eberhard wrote:
Hi Paul,
Thanks for responding (and sorry my post was inadvertently directed only
to Eric). I did run into the problem that you mentioned and I patched
sarissa.js to do exactly what you suggested (I used "temp"). Most of
the sarissa test cases now run successfully (very good news), but the
problem I mentioned is actually a separate issue.
When creating an XML document, sarissa assumes that the output of
document.implementation.createDocument implements a method called
"load." This allows the XML document to load XML from an XML file using
a standard URI (i.e. file://, http://, and relative paths). As far as I
can tell, this method is not implemented in Safari causing sarissa to
break whenever the SarissaDocument.load method is used.
Technically, Sarissa goes a step further for browers that implement
document.implementation.createLSParser by overriding the default
document.implementation.createDocument.load method with a user defined
function that makes use of the functionality described here
(specifically document.implementation.createLSParser.parseURI):
http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/load-save.html
I am not sure I understand why this approach is used for some browsers
(document.implementation.hasFeature('LS', '3.0') == true), perhaps it
performs better than the document.implementation.createDocument.load
method. Nevertheless, FireFox will work just fine with either but sadly
Safari won't do either.
Technically, Sarissa could be updated to use XMLHttpRequest in order to
provide SarissaDocument.load functionality to the web developer, but the
more I investigate that approach, the more it resembles a crude
substitute for implementing the load method on
document.implementation.createDocument.
I guess I'm not sure whether or not this is a bug, an oversight, or a
deliberate omission in Safari. I'm also not certain what to ask for
(document.load or LSParser support). Once I determine this, I should be
able to either convince the folks at Sarissa to modify their code, enter
a bug report on Safari (still waiting on my BZ enrollment email...), or
just hack Sarissa myself to implement SarissaDocument.load for Safari
alone using XmlHTTPRequest.
Many thanks!
Andrew
On 03.01.2006, at 01:35, Paul Everitt wrote:
Andrew Eberhard wrote:
Hi Eric,
Well, I'm getting underway with Safari-enabling my AJAX project
[using the latest nightly build ;-) ] and I've run into a problem
that seems to be "as designed" but I wanted to run it by everyone
first. Basically, Document.load is not supported in Safari. I
assume that I can use XMLHttpRequest instead, but
http://bugzilla.opendarwin.org/show_bug.cgi?id=5411 led me to think
that there might be reason to enter a bug on Document.load support.
Since Sarissa currently relies on Document.load for SarissaDoc.load,
I wasn't sure if bug #5411 was intended to include Document.load
support in Safari or if the folks at Sarissa should be asked to
update it to work with Safari's XmlHttpRequest approach.
There is a bit of prior research on this subject at
http://www.xs4all.nl/~zanstra/inTec/safariIdea.htm.
Hi Andrew. The Sarissa folks are taking a look at it. It's actually
possible to work around the bug, I believe.
Here is what triggers the bug:
var oldDoc = document.implementation.createDocument("", "", null);
(Note: This is against the Sarissa CVS HEAD.)
Creating a document with a real node name for the document element,
though, works:
var oldDoc = document.implementation.createDocument("", "foo", null);
Hmm, come to think of it, this works as well:
var oldDoc = document.implementation.createDocument("", null, null);
Anyway, my guess is that your application can be made to work with a
patched Sarissa. I *think* (but I'm not sure) that the qualified name
(2nd arg) should either be a real node name or null. In which case,
WebKit is right and we need to change Sarissa.
--Paul
------------------------------------------------------------------------
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
