note
arbingersys
<p>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.</p>
<p>
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 <em>opposite</em> that makes me think the term works. Here's how
my mind assembles the behavior of these two models.
</p>
<p>Callback</p>
<p><code>
template
...
--> code
template
--> code
template
...
etc
</code></p>
<p>Template::Recall</p>
<p><code>
code
...
--> template
code
--> template
code
...
etc
</code></p>
<p>
where <code>--></code> is the callback occurance. The "callback" mechanism is essentially an
'eval' (right?), while the "reverse callback" is basically substitution.
</p>
<p>
I picture a pipeline system more like
</p>
<p><code>
code template
... ...
... ...
... --> ...
</code>
</p>
<p>
where the rendering occurs at one time, e.g. HTML::Template->process() after
the the appropriate data structures have been setup.
</p>
<p>
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>
<p><em>P.S. My Interent is spotty for the next two days, so I'll try and
respond, if necessary after that.</em></p>
<!-- Node text goes above. Div tags should contain sig only -->
<div class="pmsig"><div class="pmsig-662105">
<small>A <a href="http://blog.arbingersys.com">blog</a> among millions.</small>
</div></div>
674225
674311