Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


Wish list ideas #18

jjn1056 opened this Issue · 0 comments

2 participants



I sent this as a note to gfx earlier this week and thought it would be a good idea for me to repost here that way we could involve / provoke community discussion. Thanks!


Xslate has really great features for supporting re usability. It has, (as far as
I can see) 3 different approaches:

1) Inheritance via cascade
2) Role like ability via cascade with
3) traditional include files.

I propose adding a fourth approach, which I will call Decoration, since it was
inspired by the Gang Of Four design pattern "Decorator". Templating systems
such as Site Mesh have been based on this idea.

Other templating systems like Tenjin support a similar concept via thier layout
and capturing systems:

The basic idea here is that instead of the 'child knows best' we get with
inheritance and roles, we have a 'parent knows best' approach. With Decoration
we say that the template is render through its decorator, rather than aggregating
features via roles or inheritance and rendering that. This approach gives you
another tool for creating reuse-able code which enforces more rules
from the top level. I think we could support this in two ways with Xslate. The
first is to add support for the Moose concept of 'augment'

Here's an example of what that might look like. Here's a 'base' page, (I just
copied from

## base templates myapp/base.tx:
: block title -> { # with default
[My Template!] -
: inner
: }

: block body -> {
My Body
: }

Then you'd use like:

: cascade myapp::base
: # use default title
: augment title -> {
Some Subpage
: }
: around body -> {
: super
My Sub Body
: }

The result is like

[My Template!] - Some Subpage
My Body
My Sub Body

So you can see is like using around modifier, except the parent base.tx has
more authority and control to enforce how the child extends it. This means
that the head designer can use this power to enforce more consistency and prevent
people from really messing up a template. In this case the block title enforces
how and when a child's content can appear. In the body block the child can choose
and even ignore content and logic from the parent. Both options are useful and
are the right choice for different circumstances.

The second method to support this idea extends the idea to the entire template
and not just on a method by method basis. We invent a new keyword 'decoration'
for example purposes.

## myapp/decorator1.tx
: block title -> {
Our Website -
: call('title')
: }

: block body -> {
: call('child_body')
: }

## myapp/child.tx

:decoration myapp::decorator1.tx
: block title -> {
You are visiting, <: $page_title :>
: }

: block child_body -> {
This is the body
: }

## renders like

Our Website - You are visiting, some page
This is the body

The value of this approach is that it lets you think of a child template in
terms of a whole page and not just as the fragments of bits that are different
from a parent. That way you can render the same child page via different decorator
pages, with common effects. You could even say the setting for decoration is in the
renderer arguments so you don't even set it in the child template:

print $tx->render({template=>'child.tx', decoration=>'decorator1.tx'}, \%vars);

This is the approach Site Mesh takes, btw, which follows a sort of inversion of
control, saying that instead of a template setting 'cascades with' or decoration
as part of the template definition, you set it when you do render. This may be
valuable as it gives the person in charge of when a template is rendered more
power. Template toolkit supports a similar idea, it lets you set WRAPPER,
PREPROCESS, etc in the renderer as well as in the templates. I think it would
be a valuable feature.

One other thing that would be cool is if we could extend 'cascade with' to support
the ideas express in parameterized roles:

I have found this makes much more useful and reusable roles.

Thanks for your time and for XSlate! Let me know what parts of my proposal are
not clear or need additional proof of value. I'm not so sure what part I do do to help,
I think I could help with docs, advocacy and writting test cases, but I'm not such
a good c coder.

John Napiorkowski

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.