Beefy Boxes and Bandwidth Generously Provided by pair Networks vroom
go ahead... be a heretic
 
PerlMonks  

Clarifying the rhandom-perrin attack

by metaperl (Curate)
on Feb 26, 2008 at 19:02 UTC ( #670360=note: print w/ replies, xml ) Need Help??


in reply to Re: Push templating strategy cannot violate separation
in thread RFC - Template::Empty

Update - I think the problem here is when we are using the term "view." For me, the view is very nearly tied directly to the html/xml/text template with the TT or Template::Alloy object swapping in data that was prepared by the model and handed to the view by the controller.
right. A Seamstress view is 2 things. A Perl View module and a lifeless HTML file.
Your implementations of the view seem to include sections of Perl code that know what the template needs - and even more it knows what the template looks like, and then requests data from the model in the formats that the template needs - depending upon the model to get it into shape. This is where the argument comes in.
Right this where the rhandom-perrin attack comes in: "the perl code is tightly tied to the HTML" -- and the flaw in the attack is the term "the perl code" ... the View makes use of the HTML, but the View and "the perl code" are not synonomous. And there is nothing about Seamstress which prevents multiple views of the same HTML file or multiple representations of the model.

Dynamic HTML generation is not the Achilles Heal of object-oriented Perl. It is one more domain in which it thrives.

TT models don't need to have Perl code as part of the "view" layer. Seamstress requires it.
Let's be precise. TT views are converted to Perl before execution. Seamstress views are manually written before execution. In both cases, Perl code is accessing the model. The difference is that one tool automatically generates that Perl and the other makes use of heavily object-oriented Perl to do so.
In the end we are arguing over borders which really is an inconsequential debate.
Perhaps, but it certainly was stimulating.
Both camps will be forever wrong in each others eyes.
I dont think TT is wrong. TT is serving 1 million hits a day at minimum. How can that be wrong? Now it is certainly not my cup of tea and as a result you will never catch me at Ticketmaster, or working at the same job as perrin or yourself, but you guys have results. I have theory, one corporate level success, and a fierce determination to keep the approach alive.... I'm a Haskell lover caught in a Perl job world. I'm not quite good enough will the Haskell approach to take it live. But I'm far too oriented to that way of thinking to use things like mason and TT.
I have beheld the tarball of 22.1 on ftp.gnu.org with my own eyes. How can you say that there is no God in the Church of Emacs? -- David Kastrup
[tag://all is well that ends well]
Enforce strict model-view separation in template engines via HTML::Seamstress The car is in the cdr, not the cdr in the car


Comment on Clarifying the rhandom-perrin attack
Download Code
Re: Clarifying the rhandom-perrin attack
by Rhandom (Curate) on Feb 27, 2008 at 00:04 UTC
    Let's be precise. TT views are converted to Perl before execution. Seamstress views are manually written before execution. In both cases, Perl code is accessing the model.
    TT originally was not this way. It is done now because it helps Template::Tookit execute more quickly based on its current architecture. Template::Alloy, which supports full TT syntax, is different. If you want to compile to Perl for the few cases that it is faster, you can. But Alloy's normal mode of execution is first to generate an optree - which can loosely be compared to a parsed DOM, and then loop through the nodes of the optree, letting nodes pull from the data store as necessary - all without generating any Perl. In essence it is a virtual machine for a simplistic optree language - I am looking forward to making it target Parrot directly someday.

    The difference is that one tool automatically generates that Perl and the other makes use of heavily object-oriented Perl to do so.
    Well - really the difference is that one requires you to write the heavily object-oriented Perl - the other one writes it for you so even the use of Perl is transparent. And if you use Alloy, then nearly no code has to be written (either manually or automatically) at all to interact with the template.

    my @a=qw(random brilliant braindead); print $a[rand(@a)];

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://670360]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (6)
As of 2014-04-23 23:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (557 votes), past polls