On Mon, 4 Sep 2000, Matt Sergeant wrote:
> b) We all meet different people. The people I've worked
> with, even people proficient in Javascript, flip their
> lid when they get forced to look at things like $_ and
> regexps when they know of easier systems out there. And
> I know what SF is like - anyone working in computing
> there is getting paid a hell of a lot more than the
> people working in it here (cost of housing not
> withstanding).
your point being, they are highly paid so they are ok
looking at perl?
here's one problem. everytime somebody thinks 'embedded
perl' they start thinking about $_ and regexps. when in fact
those constructs are hardly ever used (in my experience) in
display code!
i'll continue to use mason as an example, since that's my
favorite embedded perl system. 98% of my usage is something
like:
% for my $thing (sort @list) {
<a href="<% $thing->{url} %>"><b><% $thing->{name} %></b></a>
% }
or
% if ($something) {
blah blah blah
% }
there are no sophisticated or mysterious constructs in those
examples... and they're hardly contrived! this is the
essence of 'separation of application and presentation':
application logic provides its results in simple, clean data
structures, and display logic uses iterators, conditionals,
and occassionaly simple formatting functions (taglibs!).
it's a hell of a lot sillier, imo, to use a sql taglib to
draw data out of a database while you're processing a
template, than to draw the data FIRST, handling errors and
business logic, and THEN process your template, doing a very
simple merge of template and data.
i argue that for applications, a nice mvc architecture using
templates with embedded perl is a fine, fine choice. for
strict content presentation - little logic other than how to
render a blob of text - your xslt approach is very
reasonable.
