Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re^2: Push style templating systems

by arbingersys (Pilgrim)
on Mar 16, 2008 at 23:19 UTC ( #674496=note: print w/replies, xml ) Need Help??


in reply to Re: Push style templating systems
in thread Push style templating systems

I guess if you limit the definition of "pipeline" templating to be just whether a system uses a method call to render the template, then Template::Recall is a pipeline system.

But I still feel that the term "reverse callback" is appropriate, because Template::Recall uses template fragments, just as the callback method uses code fragments. It's this opposite that makes me think the term works. Here's how my mind assembles the behavior of these two models.

Callback

template ... --> code template --> code template ... etc

Template::Recall

code ... --> template code --> template code ... etc

where --> is the callback occurance. The "callback" mechanism is essentially an 'eval' (right?), while the "reverse callback" is basically substitution.

I picture a pipeline system more like

code template ... ... ... ... ... --> ...

where the rendering occurs at one time, e.g. HTML::Template->process() after the the appropriate data structures have been setup.

I'm largely speaking for Template::Recall here, since it takes its name from "reverse callback". I'm not quite sure that I would call all systems that work on template fragments reverse callback. Or "push", for that matter, although both terms work to some degree. "Pipeline" works too, in the narrow definition above, but doesn't provide much of a distinction.

P.S. My Interent is spotty for the next two days, so I'll try and respond, if necessary after that.

A blog among millions.

Replies are listed 'Best First'.
Re^3: Push style templating systems
by perrin (Chancellor) on Mar 17, 2008 at 02:08 UTC
    What I was trying to get at when I chose the terms callback and pipeline was the difference in how web requests are typically processed. Tools like Embperl, Mason, and Apache::ASP all want to hand off control to a template immediately, which puts the templates in the driver's seat (i.e. it's more like a complete program than a template). The others require you to run some other program and just call the template tool when you want to generate output.

    I wasn't trying to use these terms to separate tools which use in-line code from those that don't. For example, I don't call Text::Template a callback system.

    I don't have a trademark on these terms and you're free to use them as you wish, or ignore them completely. I'm just explaining what I had in mind when I wrote that.

      That makes sense.

      Frankly, I like the terms you chose. They're very helpful in describing the abstract behavior of templates (in my view anyway). In fact, it was those very terms (and the article) that started me along the 'fragment' line.

      A blog among millions.
      What I was trying to get at when I chose the terms callback and pipeline was the difference in how web requests are typically processed.
      Yes, what you wrote was a system architect's document. And you also wrote the document in the context of processing web requests. This is definitely fair game for an article on a mod_perl website, but in my eyes, pipeline and callback apply more accurately to web application systems.

      CGI::Application is pure pipeline... and regardless of what templating system you choose (even the ones you label callback), it will be used in the manner that you describe for pipeline systems.

      Now on the other hand, HTML::Embperl and HTML::Mason (the system, not the template language) are pure callback systems.

      Templating could be discussed without bring the web into it and then we could truly see how the execution model of template systems varies... hmm, sounds like a new node to me.

        For example, in this section you say:
        The pipeline style does all the work up front in a standard CGI or mod_perl handler, then decides which template to run and passes some data to it. The template has no control flow logic in it, just presentation logic, e.g. show this graphic if this item is on sale.
        now, by 'control flow logic' you certainly mean application control flow. because tt (a pipeline system) certainly has control flow constructs within it. but you will never see tt controllling application flow.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://674496]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (9)
As of 2017-06-23 18:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How many monitors do you use while coding?















    Results (552 votes). Check out past polls.