Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^2: RFC - Template::Empty

by fergal (Chaplain)
on Feb 25, 2008 at 18:15 UTC ( #670075=note: print w/ replies, xml ) Need Help??


in reply to Re: RFC - Template::Empty
in thread RFC - Template::Empty

The problem introduced by Tal, Seamstress, this new "Empty", and sometimes even HTML::Template with its "LOOP" construct - is that the Perl code has to know too much about the template.

In TAL, Perl builds the data and TAL renders it. Quite like TT but just with less generality built into the template language (generality that often just gets you into trouble). If you need to transform data for display (eg reorient a table, turning rows into columns and vice versa), the template can actually call out to perl helpers. This continues the separation of coding and presentation while giving almost as much flexibility as having a fully programmable template language.

However the Tal and Seamstress models go a little further... now we've made the code layer manipulate the presentation layer.

This is just simply not true at all, the perl layer cannot manipulate the presentation layer, TAL is nothing like Seamstress or Empty in this respect.

The second comment makes me wonder if you actually know TAL at all. Perhaps you have been misled by the comments above into thinking that it is similar to Seamstress and Empty.


Comment on Re^2: RFC - Template::Empty
Re^3: RFC - Template::Empty
by Rhandom (Curate) on Feb 25, 2008 at 19:20 UTC
    This is just simply not true at all
    You are very right and I am very wrong. To a point.

    I was very wrong about the model of TAL which seems to be implemented more along the lines of TT or HTML::Template - just with an XML based mini language.

    However, the process of calling back in to the perl layer in order to reorganize your data frames TAL in the light that I was mentioning before and is why I also indicated that HTML::Template also falls into that level. If you want the data in a different form - you HAVE to call into perl on TAL and HTML::Template. Seamstress doesn't give you the option - so you have to manipulate your data before hand.

    In TT and Template::Alloy - you can call into perl to manipulate your data - but the language has enough flexibility that you don't have to.

    my @a=qw(random brilliant braindead); print $a[rand(@a)];
      In TT and Template::Alloy - you can call into perl to manipulate your data - but the language has enough flexibility that you don't have to.

      Really it's a matter of whether you want this flexibility. I find that I don't want it and I also claim that having it just tempts you into doing things in your templates that you should really be doing in your code. Those with a stronger will may differ :)

      Paul, I'm enjoying this discussion. i think it is useful for both of us as well as the perl community at large... so dont think I'm making any personal attacks. The more we compare and contrast, the stronger our respective camps can become.
      In TT and Template::Alloy - you can call into perl to manipulate your data - but the language has enough flexibility that you don't have to.
      In terms of separation of concerns where do you think data manipulation should be done:
      1. model
      2. view
      3. controller

      In Seamstress, the answer is clear and my code backs it up. Data manipulation, in any way shape or form belongs in the MODEL

      your comments about sticking template code in the database almost gave me a heart attack.. What you call "flexibility" I call "confusion of concerns

      Taking a presentation tool and involving it in data manipulation... it is bound to fall short. At one point, TT was released and didnt even have numeric comparison... essential for data manipulation.

      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://software-engineering,html,templating]
      Enforce strict model-view separation in template engines via HTML::Seamstress The car is in the cdr, not the cdr in the car
        In terms of separation of concerns where do you think data manipulation should be done
        As reiterated in other posts - I think we may be arguing because of semantics here. We keep using the word "manipulate" (my fault). Models are obviously responsible for getting and changing their data. A view should not ever change the underlying data (again there are rare cases when it doesn't hurt - MVC is a design pattern - not an absolute). Controllers are responsible for helping the view and model interact. Beyond this (and possibly even including this) - the handling of the viewing of the data is all a little more fuzzy. Is the model responsible for sorting data? Maybe. Is the view responsible for escaping html? Maybe. Is the view allowed to do different things with the data? Maybe. The big question is "does it matter?" I think the answer is "probably not."

        The different templating systems encourage work flow patterns. Is one better or worse? Well that is entirely subjective to one's work patterns.

        your comments about sticking template code in the database almost gave me a heart attack.. What you call "flexibility" I call "confusion of concerns
        I haven't had a specific case where I have needed to - though I have heard several people even in the last few months on the TT list asking how to do this. I can envision use patterns for it. What is a filesystem afterall if not a database table of files? Confusion may be the right term, but I can't claim to know all of the possible cases that a developer might find useful.
        Taking a presentation tool and involving it in data manipulation... it is bound to fall short
        You are right - it is bound to. And TT does sometimes - which is why it provides hooks for people who really want to abuse the separation of model and view. But letting them abuse the boundary is a good thing for them. I may not want to develop on their systems - but at least they could get their particular job done.

        Forcing the model to be responsible for knowing the myriad ways that its data might be used is certainly a viable option. But it is wrong to enforce it in all situations. In my experience - it has potential to lead to heavier models. Data is just data.

        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://670075]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (13)
As of 2014-09-16 20:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (47 votes), past polls