Re: Petal is pull-style... like TT/mason - Seamstress is push-style

[Rhandom]

in reply to Petal is pull-style... like TT/mason - Seamstress is push-style
in thread RFC - Template::Empty

++

Thanks for the link to the paper. I found it interesting. I also found it somewhat biased and amusing.

I found it amusing because section 7.1 is labeled "Pull Strategy Violates Separation" - but he never treats the topic of whether "Push Strategy Violates separation."

There are also statements such as "Strictly speaking the URL structure of the site belongs to the controller." This is nice in theory and is true in ideal situations. After 10 years of work in non-ideal situations I've found that it "strictly" isn't true. Sometimes templates contain links that take you in and out of the controller loop.

The true bias is revealed when the last section of the paper is used to present his "new" templating system which does clear up some fuzzy boundaries - but doesn't provide anything truly remarkable over existing systems.

Formal papers are nice in an academic sense, but that doesn't mean his experience has any direct bearing on the experience of others. He is welcome to argue his point, but in the end - all of the various models have managed to get the job done for people who have used them. Existing solutions are certainly good enough for all practical purposes.

[metaperl]

Thanks for the link to the paper. I found it interesting. I also found it somewhat biased and amusing.

I am grateful for the part just before Section 7.1 where he lists the 5 things that determine whether a template system is push-style or pull-style. I think you would agree that only Seamstress is push-style. Everything else on CPAN (including Petal) and HTML_Tree (not on CPAN) is pull-style.

I found it amusing because section 7.1 is labeled "Pull Strategy Violates Separation" - but he never treats the topic of whether "Push Strategy Violates separation."

I dont think it can. Can you provide an example of where it does? You only have meld3, Seamstress and XMLC and StringTemplate to pick on, because those the only push-style templating systems out there.

[Rhandom]

I still don't think your getting it. All "push" style has done is moved the "pull" into your perl layer. Seamstress requires too much knowledge about the template. TT is closest to give true separation because you can give it unblessed, raw, unformatted data. Anything that is not passed as unblessed, raw unformatted data has violated the separation - but that doesn't make it bad - it just makes it not academic.

I don't think at this point that you will ever concede. I am somewhat saddened (but not that much) that you fail to see that Seamstress (and most likely all "push" systems) violate the separation of model and presentation in the exact opposite direction of "pull" systems.

Well - I really must get back to work and my non-academic template implementations.

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. 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. TT models don't need to have Perl code as part of the "view" layer. Seamstress requires it. In the end we are arguing over borders which really is an inconsequential debate. Both models work equally well in the eyes of the end user (who never sees the code that generated the page). Both camps will be forever wrong in each others eyes. True separation is a decoy issue at best.

[metaperl]

All "push" style has done is moved the "pull" into your perl layer.

Au contraire. It has guaranteed well-formed HTML. As well as the other benefits mentioned in the Seamstress docs.

Seamstress requires too much knowledge about the template.

You created the proving grounds. I met the challenge. Please point to the part of the code with "too much knowledge about the template".

TT is closest to give true separation because you can give it unblessed, raw, unformatted data.

Yes, but you give TT "blessed, cooked, formatted" HTML? You go into the HTML and put various things there. You rip apart the HTML into files.

Anything that is not passed as unblessed, raw unformatted data has violated the separation - but that doesn't make it bad - it just makes it not academic.

If the definition of the model were raw, unformatted data, yes. But it is not:

Model: The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating if today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items).

In other words, the raw data is adopted into the model on domain-specific terms. This adoption in my case involved blessing the object into a class which would handle all operations for this domain-specific interpretation of raw data.

Note that Catalyst also backs me up. It has very high-level Model and View classes that dispatch to your Model and View classes which then manipulate the raw and unprocessed data.

[metaperl]

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.