[webkit-dev] Re: AJAX Application (corrections made)

[Andrew Eberhard]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20060103/a7a98d36/attachment.html