--- author: email: ash@firemirror.com keyid: bfc7465ebdca5337 name: Ash Berlin categories: [] date: 2007-07-26T10:21:22Z guid: B532CCCE-3B5E-11DC-951E-B900E57C4965 modified: 2007-07-26T10:21:22Z raw: "-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\n=pod\n\nSo in a bit of down time today between projects, a colleague was working on\nmodifying his blog to syndicate photos from Vox, instead of using flickr as he\ncurrently does.\n\nBelow is the perl code he used to extract the photos and associated meta-data\nfrom the Atom feed the Vox publish. It uses the best (i.e. fully featured and\ncompliant) perl XML parser available - XML::LibXML. Take a look at the\nfollowing:\n\n lang:Perl\n my $parser = XML::LibXML->new();\n\n my $xpc = XML::LibXML::XPathContext->new;\n $xpc->registerNs('atom', 'http://www.w3.org/2005/Atom');\n\n my $library = $parser->parse_file( $library_file )->documentElement();\n my $entries = $xpc->find('/atom:feed/atom:entry',$library);\n\n for my $entry ( $entries->get_nodelist ) {\n my $data = { \n map { \n $_ => $xpc->findvalue('atom:'.$_, $entry)\n } qw( id title content published )\n };\n\n my $link = $xpc->findvalue('atom:link[ @rel = \"alternate\" ]/@href', $entry);\n \n # Do stuff with the photo now...\n }\n\nThe code is a bit... verbose. Or rather it seems like it should be possible to\nmake it cleaner. But its not really - this is just how you have to process\nthat XML to get the required data out. (Just to be clear, this is in no part a\ndig at Vox's atom layout.)\n\nIn glancing over his shoulder and wincing, we both agreed that it is in\nsituations like this that E4X really comes into its own. Don't believe me?\nWell then consider the following JavaScript code which does the same as the\nabove perl fragment.\n\n lang:JavaScript\n default xml namespace = 'http://www.w3.org/2005/Atom';\n var entries = new XML(library_file)..entry;\n \n for each (let entry in entries.*) {\n var data = { };\n for each (let key in ['id', 'title', 'content', 'published'] )\n data[key] = entry[key];\n \n link = entry.link.(@rel=\"alternate\").@href;\n \n // Do stuff with link and data\n }\n\nMuch cleaner and easier to see what's going on isn't it? Not only that but its\nabout half as many lines. If that was all that needed doing, then JavaScript\nwould have been perfect for the job. Sadly, this was not the case - the next\nstep alluded to by the C comment involves\ndownloading the image and creating a thumbnail of it. Not possible with\nserver-side JavaScript. Yet.\n\nAs I mentioned in a post about\nL\ncreating a JavaScript target for SWIG seemed like a good idea. It still does.\nWe looked at L - a Rhino/Java based server-side\nJavaScript platform. It looks good, it really does.\n\nHowever to me, I would be slightly loathe to use it for three reasons:\n\n=over\n\n=item *\n\nIt's Java, and running Tomcat or some other JVM is a bit memory hungry for\nmy co-lo box.\n\n=item *\n\nRhino isn't quite up-to-date with features that I like using from\nJavaScript 1.7, such as the following:\n\n [a,b] = [1,2]\n\nWhile that example is slightly contrived, not having destructive assignment is\na bit annoying.\n\n=item *\n\nIt's a Framework, not just a platform. This means that if you want to do\nsomething that the framework is L, it's either very hard or actually\nimpossible. I've heard that Ruby on Rails also suffers from this problem to\nsome extent. As Tom points out, this is my perlitism coming out again.\n\n=back\n\nBack to the point of SWIG, Helma should be able to use SWIG since you can\ngenerate wrappers for Java already. Saying that, the need to use SWIG with it\nis reduced since you can (I assume) use native Java.\n\nBut B would still like the ability to use SWIG from Spidermonkey, my JS\nEngine of choice. Watch this space - I'll be working on it.\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.7 (Darwin)\n\niD8DBQFGqHQBv8dGXr3KUzcRAp9xAJ92riXdvM4ZOqgiOUkyOaGPVCUM2gCdGXBn\nTrjF8qgdc8gB4FRJMTkceHY=\n=EopZ\n-----END PGP SIGNATURE-----\n" signed: 1 summary: " So in a bit of down time today between …" tags: - helma: 0 - swig: 0 - javascript: 0 text: " So in a bit of down time today between projects, a colleague was\n working on modifying his blog to syndicate photos from Vox, instead\n of using flickr as he currently does.\n\n Below is the perl code he used to extract the photos and associated\n meta-data from the Atom feed the Vox publish. It uses the best (i.e.\n fully featured and compliant) perl XML parser available -\n XML::LibXML. Take a look at the following:\n\n lang:Perl my $parser = XML::LibXML->new();\n\n my $xpc = XML::LibXML::XPathContext->new; $xpc->registerNs('atom',\n 'http://www.w3.org/2005/Atom');\n\n my $library = $parser->parse_file( $library_file )->documentElemen-\n t(); my $entries = $xpc->find('/atom:feed/atom:entry',$library);\n\n for my $entry ( $entries->get_nodelist ) { my $data = { map { $_ =>\n $xpc->findvalue('atom:'.$_, $entry) } qw( id title content pub-\n lished ) };\n\n my $link = $xpc->findvalue('atom:link[ @rel = \"alternate\" ]/@hre-\n f', $entry);\n\n # Do stuff with the photo now...\n }\n\n The code is a bit... verbose. Or rather it seems like it should be\n possible to make it cleaner. But its not really - this is just how\n you have to process that XML to get the required data out. (Just to\n be clear, this is in no part a dig at Vox's atom layout.)\n\n In glancing over his shoulder and wincing, we both agreed that it is\n in situations like this that E4X really comes into its own. Don't\n believe me? Well then consider the following JavaScript code which\n does the same as the above perl fragment.\n\n lang:JavaScript default xml namespace = 'http://www.w3.org/2005/A-\n tom'; var entries = new XML(library_file)..entry;\n\n for each (let entry in entries.*) { var data = { }; for each\n (let key in ['id', 'title', 'content', 'published'] ) data[key]\n = entry[key];\n\n link = entry.link.(@rel=\"alternate\").@href;\n\n // Do stuff with link and data }\n\n Much cleaner and easier to see what's going on isn't it? Not only\n that but its about half as many lines. If that was all that needed\n doing, then JavaScript would have been perfect for the job. Sadly,\n this was not the case - the next step alluded to by the Do stuff\n with link and data comment involves downloading the image and creat-\n ing a thumbnail of\n it. Not possible with server-side JavaScript. Yet.\n\n As I mentioned in a post about mod_js creating a JavaScript target\n for SWIG seemed like a good idea. It still does. We looked at Helma\n - a Rhino/Java based server-side JavaScript platform. It looks good,\n it really does.\n\n However to me, I would be slightly loathe to use it for three rea-\n sons:\n\n * It's Java, and running Tomcat or some other JVM is a bit memory\n hungry for my co-lo box.\n\n * Rhino isn't quite up-to-date with features that I like using\n from JavaScript 1.7, such as the following:\n\n [a,b] = [1,2]\n\n While that example is slightly contrived, not having destructive\n assignment is a bit annoying.\n\n * It's a Framework, not just a platform. This means that if you\n want to do something that the framework is not designed for,\n it's either very hard or actually impossible. I've heard that\n Ruby on Rails also suffers from this problem to some extent. As\n Tom points out, this is my perlitism coming out again.\n\n Back to the point of SWIG, Helma should be able to use SWIG since\n you can generate wrappers for Java already. Saying that, the need\n to use SWIG with it is reduced since you can (I assume) use na-\n tive Java.\n\n But I would still like the ability to use SWIG from Spidermonkey, my\n JS Engine of choice. Watch this space - I'll be working on it.\n" title: Server Side JavaScript type: pod uri: http://perlitist.com/articles/server_side_javascript xhtml: "
\n

So in a bit of down time today between projects, a colleague was working on\nmodifying his blog to syndicate photos from Vox, instead of using flickr as he\ncurrently does.

\n

Below is the perl code he used to extract the photos and associated meta-data\nfrom the Atom feed the Vox publish. It uses the best (i.e. fully featured and\ncompliant) perl XML parser available - XML::LibXML. Take a look at the\nfollowing:

\n
my $parser = XML::LibXML->new();\n\nmy $xpc = XML::LibXML::XPathContext->new;\n$xpc->registerNs('atom', 'http://www.w3.org/2005/Atom');\n\nmy $library = $parser->parse_file( $library_file )->documentElement();\nmy $entries = $xpc->find('/atom:feed/atom:entry',$library);\n\nfor my $entry ( $entries->get_nodelist ) {\n  my $data = { \n    map { \n     $_ => $xpc->findvalue('atom:'.$_, $entry)\n    } qw( id title content published )\n  };\n\n  my $link = $xpc->findvalue('atom:link[ @rel = "alternate" ]/@href', $entry);\n  \n\n  # Do stuff with the photo now...\n}\n
\n

The code is a bit... verbose. Or rather it seems like it should be possible to\nmake it cleaner. But its not really - this is just how you have to process\nthat XML to get the required data out. (Just to be clear, this is in no part a\ndig at Vox's atom layout.)

\n

In glancing over his shoulder and wincing, we both agreed that it is in\nsituations like this that E4X really comes into its own. Don't believe me?\nWell then consider the following JavaScript code which does the same as the\nabove perl fragment.

\n
default xml namespace = 'http://www.w3.org/2005/Atom';\nvar entries = new XML(library_file)..entry;\n \n\nfor each (let entry in entries.*) {\n  var data = { };\n  for each (let key in ['id', 'title', 'content', 'published'] )\n    data[key] = entry[key];\n \n\n  link = entry.link.(@rel="alternate").@href;\n \n\n  // Do stuff with link and data\n}\n
\n

Much cleaner and easier to see what's going on isn't it? Not only that but its\nabout half as many lines. If that was all that needed doing, then JavaScript\nwould have been perfect for the job. Sadly, this was not the case - the next\nstep alluded to by the Do stuff with link and data comment involves\ndownloading the image and creating a thumbnail of it. Not possible with\nserver-side JavaScript. Yet.

\n

As I mentioned in a post about\nmod_js\ncreating a JavaScript target for SWIG seemed like a good idea. It still does.\nWe looked at Helma - a Rhino/Java based server-side\nJavaScript platform. It looks good, it really does.

\n

However to me, I would be slightly loathe to use it for three reasons:

\n
    \n\t\t
  • It's Java, and running Tomcat or some other JVM is a bit memory hungry for\nmy co-lo box.\t
    • \n\t\t
  • Rhino isn't quite up-to-date with features that I like using from\nJavaScript 1.7, such as the following:\n

    [a,b] = [1,2]\n
    \n

    While that example is slightly contrived, not having destructive assignment is\na bit annoying.\t
    • \n\t\t
  • It's a Framework, not just a platform. This means that if you want to do\nsomething that the framework is not designed for, it's either very hard or actually\nimpossible. I've heard that Ruby on Rails also suffers from this problem to\nsome extent. As Tom points out, this is my perlitism coming out again.
    • \n
\n\n

Back to the point of SWIG, Helma should be able to use SWIG since you can\ngenerate wrappers for Java already. Saying that, the need to use SWIG with it\nis reduced since you can (I assume) use native Java.

\n

But I would still like the ability to use SWIG from Spidermonkey, my JS\nEngine of choice. Watch this space - I'll be working on it.\n

\n\n\n
"