This is vapour ware, in that there is of course no guarantee anything remotely like it will ever show up in the Kingdom itself (I'm only saying this because some might assume I've got some kind of Actual Influence, on what happens in the KoL development team -- which I don't; I hang around, for these occasional "Shiny! -- but wouldn't this be more neat still?" moments. End of disclaimer! :-).
That said, there were a few other "Oo, shiny!"ies in the thread, so I wouldn't be very surprised to see something like this some time. I personally wonder a bit if it's not a bit too client-side for Jick's tastes. Somehow I've got the feeling he is very reluctant to put any code that could be solved server-side on the browser's side. Good thing these things can't. :)
Webby thoughts, most about around interesting applications of ecmascript in relation to other open web standards. I live in Mountain View, California, and spend some of my spare time co-maintaining Greasemonkey together with Anthony Lieuallen.
2005-08-19
2005-08-17
Generating an M3U playlist live from a scriptlet
While browsing around remix.kwed.org for something nice to play while working today, I realized I was missing a scriptlet to make an M3U play list of all mp3 files linked from any web page (and web plain web server directory listings in particular).
So I wrote one. I had estimated five minutes, but it probably took closer to ten, my usual with(document){open('content-type'); write(page); close()} proving less than useful in a scriptlet context, since the document replacing also tosses away all javascript state, including the generated playlist page to be written.
Enter the very convenient RFC 2397 data: URL protocol -- replacing that bit with a location='content-type,'+escape(page), and we're set. (The Mozilla data: testsuite is a handy resource to get a quick idea of what you can do with this toy and how, if you are new to the concept. It's still not widely supported in browsers, but good browsers do.)
Enjoy! - the Generate M3U playlist scriptlet, in all its glory.
So I wrote one. I had estimated five minutes, but it probably took closer to ten, my usual with(document){open('content-type'); write(page); close()} proving less than useful in a scriptlet context, since the document replacing also tosses away all javascript state, including the generated playlist page to be written.
Enter the very convenient RFC 2397 data: URL protocol -- replacing that bit with a location='content-type,'+escape(page), and we're set. (The Mozilla data: testsuite is a handy resource to get a quick idea of what you can do with this toy and how, if you are new to the concept. It's still not widely supported in browsers, but good browsers do.)
Enjoy! - the Generate M3U playlist scriptlet, in all its glory.
Categories:
2005-04-11
Javascript: Using XPath as an XML query tool
Long story short: Mozilla: sure. IE / MSXML2 (3.0): well, given a strong stomach, perhaps.
I've been toying with a set top box user interface at work for some time now, all HTML, images, CSS and Javascript. Very non-web, non-computer feely, remote control rules all sort of thing. The target environment is very slightly spiced-up OEM, run of the mill wintel machines, IE the browser to run it on. I'm not overly happy about that last bit.
My development environment is rather Mozilla bound, mostly because there are tools useful when debugging and because IE6 gets error messages wrong, lacks the toSource method and lots of other very useful things that add up to make it a really unfriendly, sluggish environment providing no leverage.
On adding an EPG system to this beast, I decided on using the XMLTV format for the data, and threw together some sketchy parsing using the XPathEvaluator APIs kindly provided by the Mozilla people. It worked beautifully -- here's a comfy sample:
with which I count nodes matching some given criterion or criteria, for instance - or any other xpath functions. I did this happily enough and left the IE bit for later. Bad move. Do you think I'd be given that freedom with MSXML? I did. I am not there yet, after several hours of reading MSDN and net resources; as it turns out, to do anything but node set operations you must add some XSLT indirection to the brew, I gathered from an MSXML based tool page not kindly enclosing the only interesting bits: source code. Most annoying of them to mark it up well to get google hits from poor sods trying to get MSXML to cooperate, in my grumpy opinion.
This might be on the right track though, should I choose to still rely on doing any XPath based queries on the raw XMLTV data (untested):
Not pretty. Doesn't comply with the API of processing a node set only, but rather needs the entire document, and it reeks of needless computron waste.
End of rant. I feel a little better already.
I've been toying with a set top box user interface at work for some time now, all HTML, images, CSS and Javascript. Very non-web, non-computer feely, remote control rules all sort of thing. The target environment is very slightly spiced-up OEM, run of the mill wintel machines, IE the browser to run it on. I'm not overly happy about that last bit.
My development environment is rather Mozilla bound, mostly because there are tools useful when debugging and because IE6 gets error messages wrong, lacks the toSource method and lots of other very useful things that add up to make it a really unfriendly, sluggish environment providing no leverage.
On adding an EPG system to this beast, I decided on using the XMLTV format for the data, and threw together some sketchy parsing using the XPathEvaluator APIs kindly provided by the Mozilla people. It worked beautifully -- here's a comfy sample:
function query_xpath( node, xpath )
{
var document = node.ownerDocument || node;
var evaluator = new XPathEvaluator(), ANY = XPathResult.ANY_TYPE;
var resolver = evaluator.createNSResolver( document.documentElement );
return document.evaluate( path, node, resolver, ANY, null );
}
with which I count nodes matching some given criterion or criteria, for instance - or any other xpath functions. I did this happily enough and left the IE bit for later. Bad move. Do you think I'd be given that freedom with MSXML? I did. I am not there yet, after several hours of reading MSDN and net resources; as it turns out, to do anything but node set operations you must add some XSLT indirection to the brew, I gathered from an MSXML based tool page not kindly enclosing the only interesting bits: source code. Most annoying of them to mark it up well to get google hits from poor sods trying to get MSXML to cooperate, in my grumpy opinion.
This might be on the right track though, should I choose to still rely on doing any XPath based queries on the raw XMLTV data (untested):
function query_xpath( node, xpath )
{
var xsl = new ActiveXObject( 'Msxml2.FreeThreadedDOMDocument.3.0' );
xsl.loadXML('<xsl:stylesheet><xsl:template match="/"><xsl:value-of '+
'select="'+ path +'"/></xsl:template></xsl:stylesheet>');
var xslt = new ActiveXObject( 'Msxml2.XSLTemplate.3.0' );
xslt.stylesheet = xsl;
var xml = node.ownerDocument || node;
var proc = xslt.createProcessor();
proc.input = xml;
proc.transform();
return proc.output;
}
Not pretty. Doesn't comply with the API of processing a node set only, but rather needs the entire document, and it reeks of needless computron waste.
End of rant. I feel a little better already.
Categories:
Subscribe to:
Comments (Atom)