From: Francis Hwang <sera@...>
Date: 2004-10-20T16:05:18+09:00
Subject: Re: XSLT


On Oct 20, 2004, at 2:27 AM, James Britt wrote:
>

> I find XSLT quite worthy in its own way.  It is a functional language, 
> so you have to think in a different way to do looping and such.  But 
> for most simple things it seems to be too much work, though.  If, for 
> example, I want to take all foo elements and convert them to bar 
> elements, REXML shines.  As might Regexp.
>
> If I want to do conditional transformations based on element names and 
> attributes, REXML is simple.  XSLT may be better for defining complex 
> templates and patterns, as I have a hard time setting up state 
> tracking past a certain level.  But maybe that's just me.
>
> An advantage to XSLT is that it is (presumably) portable.  But I 
> suspect that once people have settled on a platform and programming 
> language, they are unlikely to switch down the line.  (As an aside, 
> how many people have worked on projects where Java was selected 
> because it was "cross-platform", yet there was never any foreseeable 
> need to jump platforms, and indeed the development company had 
> complete say over the development and production platforms?)
>
> I would like to see an XML transformation lib in Ruby that helped 
> solve most general cases, so that people would not have to rewrite 
> essentially the same code.  REXSLT or something.  But so far, in my 
> work converting between OOo XML and HTML, the Ruby code seems simple 
> enough.  But I've not covered all transformation cases, and there have 
> been times I thought XSLT might have been easier.
>

I think of XSLT as another templating language, like Erb or ColdFusion 
or what-have-you. Seems that the main benefit of a templating language 
is that, if you've got lots of static markup with a teensy bit of 
dynamic content, the template lets you see the static stuff clearly. 
For example,

<tr>
   <td>Name</td>
   <td><%= user.name %></td>
</tr>

is probably a lot easier to read than

tr_elt = doc.add_element( 'tr' )
td_elt1 = tr_elt.add_element( 'td' )
td_elt1.text = 'Name'
td_elt2 = tr_elt.add_element( 'td' )
td_elt2.text = user.name

Of course, templating code doesn't scale, because the static markup 
becomes the dominant mode of organizing the intent, and not the dynamic 
code. If you want to extract a method out of your Ruby code you can 
find a good place for it, but if I'm extracting a method out of Erb 
then it just makes me feel sorta dirty.

( And yes, I know that you're supposed to take that sort of stuff and 
put it in Ruby-only classes, which I often do. But I just as often have 
super-dynamic web pages to generate, and I'm not crazy about pulling 
certain chunks of HTML out of templating code and plopping them into 
straight Ruby. )

Anyway, I suppose I'm rambling a little. I just think there are some 
very profound, fundamental reasons why most templating systems still 
blow, and yet using straight Ruby to generate markup also sort of 
blows, and maybe others would have good ideas as to why that is. Could 
it be because of the broad organizational issues? Dunno.

Francis