[Catalyst] HTML::Widget and output into a html table

[Brandon Black]

On 4/13/06, A. Pagaltzis <pagaltzis at gmx.de> wrote:
> Still, it's something I've thought of doing quite a few times and
> may yet tackle, because it seems worthwhile. The XSLT model is
> very beautiful, even though the syntax is execrable. I think it's
> underappreciated, probably precisely because the syntax sucks so
> bad. (Note I'm not talking about XPath here, which has truly
> Perlish syntax.)

I looked at XSLT once a while back.  What I really wanted out of it
was browser-side transforms, allowing XSL to replace CSS.  My goal was
to have my webapps send a very abbreviated chunks of raw xml content
(not XHTML, but custom app-specific xml formats, things like
<custom><foo>xxx</foo></custom>), and reference a static XSL
stylesheet which transforms it into XHTML + all the usual display
attributes you see in CSS.

That concept would basically make the users' browsers do most of the
work we do with templating systems server-side currently, and just
seems cleaner and more scalable than the traditional approach to me.

The main problem I ran into at the time, however, was that (at least
in Moz/FF, which is pretty important to me) the browser only applied
the XSL to the XML DOM at load-time once, and then quit.  Further
JS/AJAX manipulations of the XML DOM (add new nodes, etc) at the
browser didn't get auto-transformed as I would have expected (after
all, CSS gets applied to applicable new nodes in the HTML DOM).  There
are some hackish ways around this, by basically re-parsing/evaling all
of the xml and/or xsl manually from within JS after you make changes,
or something to that kind of effect, but it looked horribly
inefficient and ugly.

My dreams of sending only compact, relevant, raw-form xml data to the
browser dashed, I moved on and never looked again.

-- Brandon