I have a class I’m preparing for tomorrow at the 2006 GeoWeb conference on the use of SVG in GIS. I’ll be posting those notes tomorrow, but tonight, as I’m basically doing my damndest NOT to work on the class for tomorrow (serious procrastination issues here) I thought I’d just make a couple of quick notes about PHP5.
I have to admit it, I have more than a little bit of a bias toward the underdog, especially when that underdog isn’t just one big mega-corp going after another big mega-corp. I think that’s part of the reason I’ve always found myself cheering for PHP, even when I could readily admit that there were problems with the language. There were - PHP3 was, while not exactly slow, hardly known for its speed-demon like characteristics. It didn’t really have much in the way of oomph when it came to object-oriented programming, which, while I personally believe OOP to have an upper boundary to the level of complexity it can handle, I still think that most contemporary languages should be able to support OOP as a matter of course.
Yet my biggest pet peeve with PHP, something that kept me from adopting it in any meaningful way, was Sablotron, PHP’s erstwhile XSLT library. With Sablotron you had to install it directly, rather than as part of the normal install for PHP, which meant that for hosted sites, you were out of luck even getting it in many cases. The transformer was slow and buggy and non-standard, and while it has improved over the years, it was always something of an also ran within the XSLT world.
Indeed, my distaste with Sablotron was so great that I ended up invoking Saxon as an external process, one of the more painful operations I can think of doing in PHP, as you are essentially invoking the Java runtime every time you serve a web page. I DID eventually get it to work, but I have to admit that it was neither fast nor pretty.
Along comes PHP5, and I’m beginning to look very closely at it again for a number of projects. It’s surprisingly fast, and it gets faster with usage. The library that it supports is becoming quite impressive, from the panoply of GD graphics to practically every database known to man or woman, It has honest to goodness classes, not fake approximations, yet PHP5 still manages to work with them without compromising the type malleability that’s always been one of the languages better strengths.
Yet it is ultimately the newly revamped XML library that has me salivating. With 5.0, PHP has switched to the libxml2 library, and its companion piece, the libxslt. Now, Daniel Veillard, one of the principle people involved in both libraries, has long been one of my inspirations, largely for the work that he has done for getting XSLT into the hands of people. He spent a great deal of energy and time getting the C++ based libxslt compliant not only with the XSLT 1.0 specification, but with the entire EXSLT.org library, which provides most of the core functions that should have been in XSLT 1.0, and that for the most part is in XSLT 2.0.
With the libXSLT library (and its stand-alone alter-ego xsltproc) you can do such things server-side as convert XML tree fragments into colllections of nodes, you can create an XSLT template as a function callable from an XPath expression, you can save external content, bind PHP functions directly into XSLTs, invoke regular expressions and all kinds of other fairly useful features, largely by taking advantage of EXSLT.
What’s more, libXML2 is one of the fastest XML parsers/processors on the planet, and between that and the speed that PHP5 operates, I’m finding that my applications definitely are racing to get to the server. This set of libraries also supports SimpleXML (a simplified XML API that echoes the development of client-side E4X) and a decent XPath implementation.
Ruby of late has been getting most of the press (and admittedly, for very good reason) but I have a suspicion that PHP5 may be the sleeper of 2006 - a language that will continue making inroads into the enterprise as it picks up new fans for performance and functionality.
Kurt Cagle is a software architect, writer, and developer living in Victoria, British Columbia.
I have a like/ambivalence relationship with PHP. The community, when I was using it seriously, was helpful and friendly, and, while not inherent to the language, is an important factor in deciding whether to use it. However, its origins as a souped-up template language make it harder to work with in some situations. I've just never had the overall experience be as 'slick' as I'd like it to be, but I'm willing to chalk that up to the size of the library and the fact I don't work with it all the time. It is, generally, pretty gratifying to code something up in PHP and see results pretty quickly.
Agreed on all counts about libxml2/libxslt. Generally it's a joy to work with. Ruby's 'native' XML handling leaves a bit to be desired, but with the recent popularity of the language, it looks like the Ruby bindings for both are now available as gems (libxml-ruby and libxslt-ruby respectively).
Although, there are problems with libxslt, such as not being able to sort extended unicode characters. I consider that bug serious enough that I rarely use it.
I've used PHP 3,4 and 5 and each time I was scratching my head withe language. The PHP library is great but hardly coherent and quite randomy documented.
libxml and libxslt are great but my grief against it is its poor way to give you information when an error occurs. Mind you it might have changed since the last time I checked.
Hello Kurt,
would like to add a few comments re sablotron, as I share offices with the main developers and have delved deep into its codebase over the past 2 years;
I think that everyone experienced the 'install nightmare' with sablotron on PHP; though want to point out that the problem wasn't sablotron...the problem was 9 times out 10 to do with expat and how php (or sablotron) linked to it.
in any event this resulted in 'i want to perform XSLT transforms and I cant do it because of sablotron'...which was a little unfair....I think that sabloton's php usage was overlooked by the original developers because they are a group of perl geeks in Prague...and probably would say that the real sleeper of this decade will be Perl6.
As for standards, sablotron does have some noticable gaps, but remember most of its development occurred way back a few years ago, a lot of work has happened with bug fixing over these years.
look out for new versions of sablotron; being written in c/c++ means that it has an extremely small footprint....as well as being fast...who knows perhaps there is a XSLT v2.0 processor in the future; though I think this would only be on the basis of a solid fully compliant XSLT v1.0 release coming out in the coarse of this year.
cheers, Jim Fuller