Push templating strategy cannot violate separation

[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]

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.

[Rhandom]

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.

[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.

[Rhandom]

Au contraire. It has guaranteed well-formed HTML.

No - the push model makes no such guarantee. Seamstress being based on well formed parsed HTML may make such a guarantee. The push model cannot. It is just method of interacting with the template. I can conceive of other "push" models such as one that works with PDF templates that look for non-HTML/XML constructs.

I'm not so sure that I couldn't insert an invalid HTML string through Seamstress - unless Seamstress is re-processing every single string that I pass to it. If it does do this re-processing - then Seamstress is too heavy. If it doesn't do this re-processing - then Seamstress can only guarantee the input HTML is well formed and can make no claim about output HTML.

There is nothing about "pull" model that guarantees that your HTML won't be well formed. Checking for well-formed-ness - if that is even a design requirement on your application is a problem domain of a test suite.


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

Sigh. Here we are again. Sorry redhotpenquin for hijacking your thread. The model should never care about whether the data will be in columns, or in a grid, or as a row. The model gives data. In some contexts the model may be queried for additional meta data for displaying the base data in different formats - but that is exceptional. Your (as in Seamstress's) "views" which are implemented as perl modules, must have intimate knowledge of how the HTML is formed in order for the view to insert data.

I normally prepare boring data. I then hand it to the view - which is a TT template. The TT template can display it however it wants without ever calling back to the model. There are times when I let the TT template query the model for display options - but this is an exception. Models are vital. Data is boring. Views are independent. Your models and views interact more than "I" normally like, and your perl and your HTML interact more than "I" normally like. These are my sentiments.

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.

Um. Yes - though I'm not sure who gets to be doing the blessing. What you have described is a template. "Ripping it apart" is also known as reuse, which is another very important design pattern. I'm guilty as charged. And sometimes I don't even use HTML at all.



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

I didn't say the model was. I said the data is. Models generate, contain, translate, summarize, update, create, delete, and otherwise play with data - the data can be objects or plain flat data. But when it comes time to hand off to the view - however that handing off happens - the data should be boring uninteresting data that has no concept of the model from which it came. If the data has any ties back to the model - you have violated pure separation in some way. The part where you want your Model give reformatted data based on the View you are using shows that you do not have pure separation between the two. So what!? You still have a model with some defined boundaries and you have a view with some boundaries. You can get the job done. While in other responses I have said your example was academically sound and textbook quality - that doesn't mean that a TT or some other "pull" model wouldn't also be academically sound and/or textbook quality. As stated previously - MVC is a pattern - not an absolute. Your life will be much easier if you abide by patterns, but will be dull and listless if you do not on occasion break them.

Once again - the methodologies are different. I should've been quiet a long time ago except I fell into the trap of arguing against the "my system is different so its better" nature of this thread. Your system and my system are different. I think mine is better. You think yours is better. We're both right for our own problem domain.

Note that Catalyst also backs me up.

I don't think that introducing a religious debate to resolve a religious debate is a wise idea. On the positive side - Catalyst has views for all of the major templating systems - so using it as an argument for your viewpoint doesn't clear anything up. It also allows for well defined, complex, simple or abstract models with any degree of separation between view and model. On the negative side, Catalyst ... I won't say anything negative - I just don't have much positive to say about using Catalyst as a role model - other than it is one more angle that has made programming fun for a subset of developers.

I can only end by pointing to our sample code for the problem I gave. You may find something exciting in having to write all of the boilerplate necessary for interacting with your template. I do not.