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

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.

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://model,view,controller]

[download]
Enforce strict model-view separation in template engines via HTML::Seamstress The car is in the cdr, not the cdr in the car

Replies are listed 'Best First'.
Re: Model-View-Controller is natural with HTML::Seamstress
by Rhandom (Curate) on Feb 26, 2008 at 23:40 UTC
    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.

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

In Section Meditations