Russell Beattie secretly lusts for Ruby on Rails
As a Ruby developer, the tune of all these trumpets heralding the coming of SimpleXML in PHP5 sounds a bit out of key. Gutmans and Suraki from Zend gets really carried away in the introduction to PHP 5:
PHP 5 also introduces new revolutionary ways of dealing with XML that make it the ideal platform for XML processing—no other solution comes even close!
I can forgive their overreaching enthusiasm, though, they're just really proud of their creation. It's somewhat harder to forgive "Java heads" like Russell Beattie getting all giddy about PHP 5 because of the introduction of SimpleXML and XPath.
Beattie brings about this example to show the "simplicity" of that combination:
$sxe = simplexml_load_file("articles.xml");
foreach($sxe->xpath('/articles/item/title') as $item) {
print $item . "\n";
}
I'm sorry, but that can't really impress me when the standard library for XML in Ruby has been able to do exactly the same in less and more readable code since the beginning of 2002:
doc = REXML::Document.new(File.new("articles.xml"))
doc.elements.each('articles/item/title') { |title|
puts title.text
}
"Oh", I hear you cry, "but I don't need to call any methods on my item in PHP!". If that's the key to your fancy, then consider this:
class REXML::Element def to_s() text end end
Yes, that would indeed be a run-time extension of the standard library. Just one of the reasons languages like Ruby and Smalltalk are such a joy to work with. You're not bound by neither limitations nor design choices made by the original developers. With that extension in place, you can discard the call to text and just write puts text.
Beattie continues his tale of envy for the scripting world with a keen observation on logic and views. If I didn't know better, I'd think had a peak at Rails and was building its case for world domination:
I'm not interested in artificially limiting the power of the script on the pages. There's always tricky logic to be had on the view side of things. Always. No matter what you do, no matter what project I've worked on, there's always a requirement in the view layer that ends up needing a lot of logic
This is exactly why Rails doesn't attempt to build Yet Another Templating Language, but relies on Ruby itself (through ERb) to power the templates. Ruby is incredibly well-suited for templating purposes with constructs like:
<select>
<%= [ "Denmark", "Spain", "USA" ].collect { |country|
"<option>#{country}</option>" }.join %>
</select>
Of course you don't want to litter your views with a ton of hard-coded constructs for something as common as this, so how about using that wonderful run-time extension feature again:
class Array
def html_options
collect { |element|
"<option>#{element}</option>"
}.join
end
end
That's right. I'm extending the core library in Ruby. The C constructs Matz spent all those years perfecting. This leads to a more tolerable and reusable code, like (the %w-style is Ruby shorthand for the same array we used before):
<select> <%= %w(Denmark Spain USA).html_options %> </select>
Beattie goes even further by almost suggesting the un-suggestible: Why use Java at all?
What I'd like to see is a PHP-like solution, but with Groovy as the language being used not Java. And I want to put the controller logic in Groovy as well - since, hey, it ends up as bytecode, why not? Rapid App Development plus MVC goodness. I'm down with that... (my emphasis)
This is exactly what Rails is all about. The flexibility of PHP with the beauty and elegance of a well-factored MVC solution. Thanks for making that point so clearly, Beattie.
