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.