[webkit-dev] JavaScript for XML with XSL
Hi! I would like to display XML with an XSL transformation. I know the easy way is to have an iframe point at the XML. Here the XML needs to refer to the XSL. That's precisely what I want to avoid. I don't want the XML to know about the XSL as I want it to be used with several different XSL transformations. An initial search brought me to this: http://www.w3schools.com/xml/xml_xsl.asp However, it turns out that WebKit does not support JavaScript access to XSL transformations. So this seems like a dead end. I have since found a better implementation: http://johannburkard.de/software/xsltjs/ Still this does not work with WebKit. However the developer gives an interesting tidbit on his blog: I experimented with transforming XML in an iframe. Extending the XML with an xml-stylesheet processing instruction and loading it in a hidden iframe is probably enough to make Safari support programmatic XSLT. What I will try now is to extend xslt.js with the corresponding code. If I understand this right, he found a way to inject the XSL stylesheet reference into the XML using JavaScript. That would be a perfect solution for WebKit use. (For other browsers I would still need the xslt.js) The think is that I don't know how to manipulate the XML that goes into the iframe. Ideas? Best, Pierre --- Pierre Bernard http://www.bernard-web.com/pierre http://www.houdah.com smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScript for XML with XSL
Safari 3.0 and later supports XSLTProcessor. You can use that. The FAQ is wrong: http://developer.apple.com/internet/safari/faq.html#anchor21 Perhaps one of the Apple guys on this list can get it fixed. -eric On Sun, Feb 17, 2008 at 2:48 AM, Pierre Bernard [EMAIL PROTECTED] wrote: Hi! I would like to display XML with an XSL transformation. I know the easy way is to have an iframe point at the XML. Here the XML needs to refer to the XSL. That's precisely what I want to avoid. I don't want the XML to know about the XSL as I want it to be used with several different XSL transformations. An initial search brought me to this: http://www.w3schools.com/xml/xml_xsl.asp However, it turns out that WebKit does not support JavaScript access to XSL transformations. So this seems like a dead end. I have since found a better implementation: http://johannburkard.de/software/xsltjs/ Still this does not work with WebKit. However the developer gives an interesting tidbit on his blog: I experimented with transforming XML in an iframe. Extending the XML with an xml-stylesheet processing instruction and loading it in a hidden iframe is probably enough to make Safari support programmatic XSLT. What I will try now is to extend xslt.js with the corresponding code. If I understand this right, he found a way to inject the XSL stylesheet reference into the XML using JavaScript. That would be a perfect solution for WebKit use. (For other browsers I would still need the xslt.js) The think is that I don't know how to manipulate the XML that goes into the iframe. Ideas? Best, Pierre --- Pierre Bernard http://www.bernard-web.com/pierre http://www.houdah.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScript for XML with XSL
Hi Eric,
Running Safari 3.1, this produces no output, when entered at http://www.w3schools.com/xsl/tryit.asp?filename=cdcatalog
:
html
head
script
function loadXMLDoc(fname)
{
var xmlDoc;
xmlDoc=document.implementation.createDocument(,,null);
xmlDoc.async=false;
xmlDoc.load(fname);
return(xmlDoc);
}
function displayResult()
{
xml=loadXMLDoc(cdcatalog.xml);
xsl=loadXMLDoc(cdcatalog.xsl);
xsltProcessor=new XSLTProcessor();
xsltProcessor.importStylesheet(xsl);
resultDocument = xsltProcessor.transformToFragment(xml,document);
document.getElementById(example).appendChild(resultDocument);
}
/script
/head
body onload=displayResult()
div id=example /
/body
/html
Best,
Pierre.
On 17 Feb 2008, at 15:49, Eric Seidel wrote:
Safari 3.0 and later supports XSLTProcessor.
You can use that. The FAQ is wrong:
http://developer.apple.com/internet/safari/faq.html#anchor21
Perhaps one of the Apple guys on this list can get it fixed.
-eric
On Sun, Feb 17, 2008 at 2:48 AM, Pierre Bernard [EMAIL PROTECTED]
wrote:
Hi!
I would like to display XML with an XSL transformation.
I know the easy way is to have an iframe point at the XML. Here the
XML needs to refer to the XSL.
That's precisely what I want to avoid. I don't want the XML to know
about the XSL as I want it to be used with several different XSL
transformations.
An initial search brought me to this: http://www.w3schools.com/xml/xml_xsl.asp
However, it turns out that WebKit does not support JavaScript access
to XSL transformations. So this seems like a dead end.
I have since found a better implementation:
http://johannburkard.de/software/xsltjs/
Still this does not work with WebKit. However the developer gives an
interesting tidbit on his blog:
I experimented with transforming XML in an iframe. Extending the
XML with an xml-stylesheet processing instruction and loading it in
a hidden iframe is probably enough to make Safari support
programmatic XSLT. What I will try now is to extend xslt.js with the
corresponding code.
If I understand this right, he found a way to inject the XSL
stylesheet reference into the XML using JavaScript. That would be a
perfect solution for WebKit use. (For other browsers I would still
need the xslt.js)
The think is that I don't know how to manipulate the XML that goes
into the iframe. Ideas?
Best,
Pierre
---
Pierre Bernard
http://www.bernard-web.com/pierre
http://www.houdah.com
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
---
Pierre Bernard
http://www.bernard-web.com/pierre
http://www.houdah.com
smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Building WebKit using auto tools
Hi all I have build WebKit using auto tools using the following commands $ ./autogen.sh --prefix=/path/to/install/directory $ make $ ./Programs/GtkLauncher $ make install Running GtkLauncher works fine.=) How different is this from building WebKit using WebKit/WebKitTools/Scripts/build-webkit --gtk because trying to build this gives me Errors.:-(( Any understanding in this regard will be of great Help... Thanking you'll in advance. Regards, Sval -- View this message in context: http://www.nabble.com/Building-WebKit-using-auto-tools-tp15530575p15530575.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit application
Hi all, Can any one suggest me a simple WebKit application..But I want to test this application on a cross compile platform. plz help Thanking you'll in advance Regards Sval -- View this message in context: http://www.nabble.com/WebKit-application-tp15530577p15530577.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScript for XML with XSL
Pierre,
On 18/02/2008, at 02:10, Pierre Bernard wrote:
function loadXMLDoc(fname)
{
var xmlDoc;
xmlDoc=document.implementation.createDocument(,,null);
xmlDoc.async=false;
xmlDoc.load(fname);
return(xmlDoc);
}
The code fails with the following error:
Value undefined (result of expression xmlDoc.load) is not object.
http://www.w3schools.com/xsl/tryit_view.asp?filename=cdcatalog (line 22)
The Document.load method being called here appears to be part of the
June 2003 working draft of DOM Level 3 Load and Save Specification (http://www.w3.org/TR/2003/WD-DOM-Level-3-LS-20030619/
), but has since been removed from that specification. Firefox, Opera
and Internet Explorer appear to implement this method in some form.
WebKit's lack of support for this method is tracked by http://bugs.webkit.org/show_bug.cgi?id=9063
.
If you change your code to load the XML document via a method that
WebKit does support do you have better luck with processing it via XSL?
- Mark
smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Regarding WebKit Support Libraries
Hi Alp and Brent, My vote is to use Wininet. This is because my objective is to eventually support a WinCE version. Wininet is used in both Win32 and WinCE, so it is a convenient choice from this point of view. CURL would be OK if it could be easily ported to WinCE. I haven't looked into that, so I don't know the difficulty. But, I suspect it is non-trivial. Also, it would have the downside of requiring extra code which increases the static application size. (Static application size is an important consideration for mobile use cases). So, I vote for using Wininet. There was Wininet support in the codebase earlier. I believe this could be resurrected without too much trouble. Cheers, Dan On Feb 15, 2008 5:33 AM, Brent Fulgham [EMAIL PROTECTED] wrote: Hi Alp, On Feb 14, 2008, at 2:05 AM, Alp Toker wrote: Brent Fulgham wrote: In the medium term, I will probably end up ripping out the CFNetwork code to replace with native windows calls, though it would be nice to avoid this needless work. The CURL http backend used by the GTK+ and Wx ports works on Windows, though it's not as complete as CFNetwork. It could do the job till the CFNetwork issues are resolved. In light of Apple's recent notification (today) that CFNetwork would no longer be available as open source, I think we've got to shift to the CURL back-end. There are really only three options I see: 1. If license allows, take the existing APSL CFNetwork sources and attempt to use it. Downsides: lots of work to achieve existing features. No real upside. 2. Implement native WinInet versions of features from CFNetwork. Downsides: Single-platform, minimal reuse. Not much assistance to find problems. 3. Use CURL library. Benefits: Assist in CURL development, share code with other project targets (read: I get to bug Alp when I have problems). Downside: Mostly just the manual effort of conditionalizing the CFNetwork code. Of these, the only one that really seems desirable to me is the CURL back-end. CFNetwork is integrated into the Win port (consider how HTTP resource errors are handled and passed up to the UI) so swapping it out for something else may have some unfortunate maintenance overhead (ifdefs, more platform splits, and associated build system changes). Agreed, but I don't see that we have much choice at this point. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Regarding WebKit Support Libraries
I'd like to see a pretty much pure open source solution available for all platforms. By pure I mean down to the core windowing and libc level. As far as porting curl to WinCE. Found this. http://curl.haxx.se/mail/lib-2002-07/0085.html A obvious reason to have this available is it makes it easier to support new standards or get around show stopper bugs in closed libraries. But generally its a philosophical issue. Outside of designing the port to accommodate multiple solutions it should not have a big impact. In general we already have a problem on the Linux port because of the multiple support libraries possible. Right now this means a number of incompatible versions of webkit need to be installed but 99% of the code is shared. We potentially could have QT/wxWidget/gtk-x11/gtk-directfb/openstep versions on one box. and whatever Adobe is doing. On windows and OSX you add one more. Plus later Googles stuff and whatever Sun is doing. Not to mention applications like mail clients etc. The lack of a shared core makes things troublesome even on the desktop. So the code size argument is a subset of a larger shared code problem with the current project. On Feb 17, 2008 9:15 AM, Daniel Zucker [EMAIL PROTECTED] wrote: Hi Alp and Brent, My vote is to use Wininet. This is because my objective is to eventually support a WinCE version. Wininet is used in both Win32 and WinCE, so it is a convenient choice from this point of view. CURL would be OK if it could be easily ported to WinCE. I haven't looked into that, so I don't know the difficulty. But, I suspect it is non-trivial. Also, it would have the downside of requiring extra code which increases the static application size. (Static application size is an important consideration for mobile use cases). So, I vote for using Wininet. There was Wininet support in the codebase earlier. I believe this could be resurrected without too much trouble. Cheers, Dan On Feb 15, 2008 5:33 AM, Brent Fulgham [EMAIL PROTECTED] wrote: Hi Alp, On Feb 14, 2008, at 2:05 AM, Alp Toker wrote: Brent Fulgham wrote: In the medium term, I will probably end up ripping out the CFNetwork code to replace with native windows calls, though it would be nice to avoid this needless work. The CURL http backend used by the GTK+ and Wx ports works on Windows, though it's not as complete as CFNetwork. It could do the job till the CFNetwork issues are resolved. In light of Apple's recent notification (today) that CFNetwork would no longer be available as open source, I think we've got to shift to the CURL back-end. There are really only three options I see: 1. If license allows, take the existing APSL CFNetwork sources and attempt to use it. Downsides: lots of work to achieve existing features. No real upside. 2. Implement native WinInet versions of features from CFNetwork. Downsides: Single-platform, minimal reuse. Not much assistance to find problems. 3. Use CURL library. Benefits: Assist in CURL development, share code with other project targets (read: I get to bug Alp when I have problems). Downside: Mostly just the manual effort of conditionalizing the CFNetwork code. Of these, the only one that really seems desirable to me is the CURL back-end. CFNetwork is integrated into the Win port (consider how HTTP resource errors are handled and passed up to the UI) so swapping it out for something else may have some unfortunate maintenance overhead (ifdefs, more platform splits, and associated build system changes). Agreed, but I don't see that we have much choice at this point. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Regarding WebKit Support Libraries
Daniel Zucker wrote: Hi Alp and Brent, My vote is to use Wininet. Hi Daniel, You can register your vote by writing and offering to maintain a WinINet http backend. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScript for XML with XSL
Hi Mark, Eric and all,
the following works:
html
head
script
function displayResult()
{
var xmlRequest = new XMLHttpRequest();
xmlRequest.open(GET, cdcatalog.xml, false);
xmlRequest.send(null);
xml= xmlRequest.responseXML;
var xslRequest = new XMLHttpRequest();
xslRequest.open(GET,cdcatalog.xsl, false);
xslRequest.send(null);
xsl = xslRequest.responseXML;
xsltProcessor=new XSLTProcessor();
xsltProcessor.importStylesheet(xsl);
resultDocument = xsltProcessor.transformToFragment(xml,document);
document.getElementById(example).appendChild(resultDocument);
}
/script
/head
body onload=displayResult()
div id=example /
/body
/html
Best,
Pierre
On 17 Feb 2008, at 16:29, Mark Rowe wrote:
Pierre,
On 18/02/2008, at 02:10, Pierre Bernard wrote:
function loadXMLDoc(fname)
{
var xmlDoc;
xmlDoc=document.implementation.createDocument(,,null);
xmlDoc.async=false;
xmlDoc.load(fname);
return(xmlDoc);
}
The code fails with the following error:
Value undefined (result of expression xmlDoc.load) is not object.
http://www.w3schools.com/xsl/tryit_view.asp?filename=cdcatalog (line
22)
The Document.load method being called here appears to be part of the
June 2003 working draft of DOM Level 3 Load and Save Specification (http://www.w3.org/TR/2003/WD-DOM-Level-3-LS-20030619/
), but has since been removed from that specification. Firefox,
Opera and Internet Explorer appear to implement this method in some
form. WebKit's lack of support for this method is tracked by http://bugs.webkit.org/show_bug.cgi?id=9063
.
If you change your code to load the XML document via a method that
WebKit does support do you have better luck with processing it via
XSL?
- Mark
---
Pierre Bernard
http://www.bernard-web.com/pierre
http://www.houdah.com
smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Regarding WebKit Support Libraries
Hi there, Another option/alternative to Curl would be POCO - http://pocoproject.org . It has the advantage of being nice C++ cross-platform code, available for all major platforms. Already has nice HTTP(S) and FTP client support. Günter On Feb 17, 2008, at 18:15 , Daniel Zucker wrote: Hi Alp and Brent, My vote is to use Wininet. This is because my objective is to eventually support a WinCE version. Wininet is used in both Win32 and WinCE, so it is a convenient choice from this point of view. CURL would be OK if it could be easily ported to WinCE. I haven't looked into that, so I don't know the difficulty. But, I suspect it is non-trivial. Also, it would have the downside of requiring extra code which increases the static application size. (Static application size is an important consideration for mobile use cases). So, I vote for using Wininet. There was Wininet support in the codebase earlier. I believe this could be resurrected without too much trouble. Cheers, Dan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Authentication dialog
On Feb 17, 2008, at 8:06 AM, Bill Patterson wrote: I've tried didReceiveAuthenticationChallenge delegates, but this hasn't worked in every case, especially on Leopard. The above- mentioned dialogs work for me every time. Safari uses this delegate to put up authentication sheets for HTTP authentication. So I'm not sure why it's not working for you. Maybe you should cite a specific example where that doesn't work. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit application
You can see the GtkLauncher accompanied with webkit source code. On Sun, Feb 17, 2008 at 11:22 PM, sval [EMAIL PROTECTED] wrote: Hi all, Can any one suggest me a simple WebKit application..But I want to test this application on a cross compile platform. plz help Thanking you'll in advance Regards Sval -- View this message in context: http://www.nabble.com/WebKit-application-tp15530577p15530577.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] More Flood: QCookieJar and Cookie Handling
Hello. I don't see much of a way to handle cookies within QtWebkit. I see that there is a QCookieJar created when needed to save cookies for a site session, but discarded after words, and I can't seem to see where/how to access cookies saved from that site. Unless there's already a way for an Application using QtWebkit to access cookies from WebKit, would it be somewhat of a logical idea to provide QWebNetworkRequest with a QCookieJar container, and be able to call from that? Feel free to downside my logic, it's probably wrong, but I'm looking for a way I can patch this up to provide cookie support. Thx. c ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
