|
Re^2: Push style templating systems
by chromatic (Archbishop) on Mar 14, 2008 at 23:19 UTC
|
I'd refer to it as something like "substitution-only" templating.
One difference is that Template::Recall works on fragments, and the logic for assembling those fragments into a larger document is in the code, not the template. It's not a big thing, but it's different from other template-as-a-whole-document approaches.
| [reply] |
|
|
| [reply] |
|
|
Of course. What I like about Template::Recall is that it enforces its style. It's most natural to use it in a clean way. Not everyone likes that approach, and that's fine. I'm a big fan of interfaces that are difficult to abuse (and I've seen my share of code-in-the-template abuses, as well as mini-language-turned-maxi abuses).
| [reply] |
Re^2: Push style templating systems
by arbingersys (Pilgrim) on Mar 16, 2008 at 23:19 UTC
|
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.
| [reply]
[d/l]
[select] |
|
|
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.
| [reply] |
|
|
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.
| [reply] |
|
|
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.
| [reply] |
|
|
Re^2: Push style templating systems
by metaperl (Curate) on Mar 17, 2008 at 14:27 UTC
|
"Push" seems like a poor name for this.
Well, what name do you think is best?
I also wouldn't lump HTML::Seamstress and XMLC in with Template::Recall and StringTemplate. As you know, the former use an approach based on the HTML/XML document structure, while Template::Recall and CGI::FastTemplate do a much simpler regex-like substitutions.
If you focus on _how_ they do their job, they are different. If you focus on the fact that they achieve what Terence Parr defined throughout his article, then Template::Recall and HTML::Seamstress are very similar.
And again, with both Recall and Seamstress, you must adhere to a certain discipline while with TT and others you can adhere if you please, but dont have to.
| [reply] |
|
|
For me, if somebody really wants to make the artificial distinction between push and pipeline that is fine. The template world is so small and I have spent too much time quibbling about this topic in the past. I think the following two concepts frame the debate in more of the light of what it actually is about:
Mini-language vs Variable-swapping-only - This is probably what the debate is about. Where really does the display formatting logic belong? Does it belong in the template with the rest of the display information, or does display formatting logic belong outside of the template. Without a mini-language you have to "push" the display formatting from the perl code. With a mini-language the template can "pull" data it needs.
My chosen template system is better than that "other" template system - It is so easy to be religious about things that are trivial and insignificant, so we let ourselves be. We focus so much on an arbitrary core set of ideas, and we go so far as to treat them as absolutes, that we fail to see the merits of just about anything else. Perhaps we need a name for this system - something such as developer religio-mytopia.
I apologize that this appears here in your node. I just find my self participating in a many lists (perl and non-perl) lately where developers argue a point as if the entire world's outcome was based upon it (only slight hyperbole here). The world of Perl Templating or even General Templating is so small but we treat it like it is the end-all-be-all. Please use what is best for you. Evangelize it even. But artificial distinctions and false absolutes don't help clear things up.
This thread didn't start with the explicit intent of pushing Push over Pipeline, but it seems to have the implied intent, and subsequent replies have only strengthened this argument.
Still ++ for listing the systems that fall into this particular genre.
my @a=qw(random brilliant braindead); print $a[rand(@a)];
| [reply] |
|
|
Well, I for one have never felt that one system necessarily beats out another. I realize, too, that the tone of the "Reverse Callback Templating" article may come off as indicating this, but that wasn't really my intent. I adopted that sort of "selling" -- yikes, shopping network -- tone, specifically because I do want to advocate the module, and point out those features that may appeal to developers.
However, I think it's important to point out the differences of template system behavior, simply because it helps you make a better choice.
| [reply] |
Re^2: Push style templating systems
by metaperl (Curate) on Mar 19, 2008 at 18:28 UTC
|
Template::Recall and CGI::FastTemplate do a much simpler regex-like substitutions.
I think you mean StringTemplate, not CGI::FastTemplate... anyway, StringTemplate requires the Antlr parser generator to work, so I dont think it does simple regex substitutions.
| [reply] |
|
|
CGI::FastTemplate is a module with a similar approach to Template::Recall. It uses regexes.
| [reply] |
|
|
Wow, CGI::FastTemplate is definitely push-style.. I've updated the main node. Never heard of it til now. Question is, why is it in the CGI namespace? It could be used on plain text and standalone with no web sense whatsoever.
Thing is, breaking a table into 3 files as shown in the full example eliminates one major push-style benefit, the ability to statically validate and clean HTML... and another push-style benefit: the ability to edit with an HTML page-oriented tool.
Interesting module nonetheless.
Finally, your statement about Seamstress and div/class tags is a bit of a simplification. The more recent API calls in Seamstress can use anything that the look_down() method in TreeBuilder can.
| [reply]
[d/l] |
|
|
Re^2: Push style templating systems
by metaperl (Curate) on Aug 03, 2009 at 12:47 UTC
|
"Push" seems like a poor name for this. It doesn't imply anything other than calling the template from perl code, i.e. the same thing I referred to as "pipeline."
The trick is to look at it from the capabilities of the template not how the template is called. the definitions of push and pull-style rely on what the template can do, not how the template is called.
I also wouldn't lump HTML::Seamstress and XMLC in with Template::Recall and StringTemplate.
From the standpoint of template capabilities given in the definition, you can see why they would be lumped together. However,
| [reply] |
Push style and pull style come from XML?
by metaperl (Curate) on Mar 17, 2008 at 17:50 UTC
|
I did a bit of googling for push-style and it seems that this is XML terminology based on this article.
| [reply] |
|
|
| [reply] |
