> Jay Jacobs wrote:
> >
> > I don't see any glue-sniffing symptoms from choosing
> > embedded html in perl over embedded perl in html.
> >
>
> Unless, of course, you're the graphic artist and you've been tasked
> with changing the look and feel of the application using embedded
> perl (which you, as the graphics person, probably don't know
> anything about), while the perl developer works on the perl portions
> of the code, then you might be sniffing some glue. This the
> motivation for some (if not most) of the templating solutions Perrin
> mentioned.
Hmmm... Mason makes this *possible*, for me:
I tell my guys, make it look ANY way you like. I don't care. I don't WANT
to care. Just leave me ONE <td></td>. Since I have all of my components
called by a single dispatch component, all that td has to have is one line
of markup.
Then I tell them, here's the list of styles I'll be using in my markup. You
have access to the stylesheet, make them look however you want but don't
add/remove/rename any of them.
Using this method, I've been able to extend the SAME CODE on two different
sites w/ radically different themes.
Of course, at this point, some would say XML / XSL! Try AxKiT!
But to be honest, I haven't gone there yet. XML, no matter how pretty the
tools, is still a pain and a bother, IMHO. Dropping a couple of lines of
perl in a (mostly) static HTML table/form/chart is FAR simpler than learning
a new language (for the stylesheets) to implement a new paradigm (XML) that
in spite of its buzzword compliance is still a hit-and-miss crapshoot
against current browsers.
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
