in reply to
RFC - Template::Empty
It seems that there is always a knee-jerk reaction to not having control flow in your HTML - and sometimes rightfully so. I very often see posters decrying systems such as Template::Toolkit because it has its own language - which it does - which may or may not be a problem. But that is a separate issue from that introduced by the Tal, Seamstress, and now the "Empty" concept.
The problem introduced by Tal, Seamstress, this new "Empty", and sometimes even HTML::Template with its "LOOP" construct - is that the Perl code has to know too much about the template.
Obviously the Perl code has to know which variables the template is going to need. However the Tal and Seamstress models go a little further - the Perl code for these has to know a little (sometimes a lot) about how the template is going to present the data. We've made sure the logic is out of the presentation layer - but now we've made the code layer manipulate the presentation layer. I think this is worse than having control flow in the template.
The nice thing about template systems with at least a minimal amount of language capability (such as Template::Toolkit) is that my Perl layer can generate data and pass it to the presentation layer. The presentation layer is then free to manipulate the data into a form suitable for presentation.
In the end, it really is developer preference. But for myself I've found that Template::Toolkit syntax and particularly Template::Alloy (which I authored) if used properly are the perfect separation between model and view. And it is the perfect separation from both directions.
my @a=qw(random brilliant braindead); print $a[rand(@a)];