Twig: [feature request] Add a {% print … %} tag

Created on 1 Oct 2016  Â·  13Comments  Â·  Source: twigphp/Twig

I think Twig should have a {% print … %} tag, that works identically to {{ … }}.

I do realize this is completely pointless from a technical point of view.

But from an educational point of view, it would be easier to explain how Twig templating works to noobs if this existed. I've found that most noobs think {{ variable }} tags are just how you access a variable, even within other {% … %} tags (example) – and for whatever reason this is a hard assumption to break.

If a {% print … %} tag existed, when teaching someone Twig you could start by only introducing normal {% ... %} tags (including print). Once they have a basic understanding of normal tags, you could introduce {{ ... }} tags, as a _shortcut_ for {% print … %}, which I think would help it “click” better.

Most helpful comment

The designers I work with actually had no problems understanding twig at all. I think the difference that Fabien gave between 'say' and 'do' is exactly the way it should stay. I can't really envision either what it should look like. I think twig should stay as clean as possible. The fact that we have e.g. {{ include() }} and {% include %} is already annoying and confusing enough.

If it's just for educational purposes, maybe a tutorial on how to write your own tag or a custom repository for educational purposes could suffice.

All 13 comments

(I’d be happy to add the tag myself, but would like to get @fabpot’s blessing before getting to work.)

Thanks for your suggestion. But that won't be added to Twig as it would be very wrong from a semantic point of view.

{{ }} The “say something” syntax
{% %} The “do something” syntax

What we can do, as I realize that's not already the case, is to start the "Twig for Template Designers" chapter with this information.

"do something" can be said to also encompass "print something" though, right? Semantically it makes sense in my opinion, much like you start with <?php echo $var ?> in PHP and then later learn about <?= $var ?>.

@svenluijten was thinking the exact same thing (including the PHP tag example:)

ok, let's take the time to discuss this a bit more

...it would be very wrong from a semantic point of view.
{{ }} The “say something” syntax
{% %} The “do something” syntax

These semantics actually seem to support the feature request the way I'm reading it.

In getting one of my team members up to speed on Twig I actually used this echo/print comparison which helped a lot. I just wanted to throw some support behind the FR.

The designers I work with actually had no problems understanding twig at all. I think the difference that Fabien gave between 'say' and 'do' is exactly the way it should stay. I can't really envision either what it should look like. I think twig should stay as clean as possible. The fact that we have e.g. {{ include() }} and {% include %} is already annoying and confusing enough.

If it's just for educational purposes, maybe a tutorial on how to write your own tag or a custom repository for educational purposes could suffice.

@iltar Not to derail this convo, but the include() function is great for times when you need to include a template as a variable – much cleaner than {% set … %}{% include … %}{% endset %}. Maybe the docs should clarify use cases when include() makes sense.

I’d say it’s similar to how the range() function has a #..# shortcut, and how the |slice filter has a [#:#] shortcut. If the {% print … %} tag existed, we could start thinking of the {{ … }} syntax as just another shortcut.

Yes, it’s a change in the way we think about {{ … }} tags, but that’s not a bad thing if it’s a more natural way of thinking about them for newcomers.

Semantically, Brandon's proposal makes sense. As an educator, it would make it simpler for my students if I teach the "long way" first and the "shortcut" second. A lot of the people I teach do not write code outside of templates. To them, {{ something }} is a variable (like $something), not an output tag. I've also used the example echo $something; like Erik. But this translation doesn't always click because a lot of people are not familiar enough with PHP (yes, I realize this is a page 1 example of every PHP book or tutorial). They're using Twig as part of CMS that allows to them to work without needing to know PHP.

The only time I'd ever use Brandon's proposed {% print ... %} is in education on Twig but it would go a long way to be clear about how Twig variables work.

As an example: adding the functionality would also allow us to back up this explanation with a code example:

There are two kinds of delimiters: {% ... %} and {{ ... }}. The first one is used to execute statements such as for-loops, the latter prints the result of an expression to the template.

This distills it down perfectly but showing it would be an added benefit to people learning Twig.

I'm happy to contribute to the documentation for this change.

(Updated to fix typo and clarify my last section with the documentation quote.)

@ryanirelan if they thing that {{ something }} is the variable, they will have troubles as soon as they start using functions or filters and need to pass them a variable as argument. So to me, this looks like an issue in the way Twig is explained, not in the way Twig works.

The issue probably stems from the fact that some simpler find-and-replace-based templating systems do just look for {variable} strings and replace them with the values. ExpressionEngine is one example. If you’re coming from something like that, then it’s reasonable to assume {{variable}} is Twig’s slightly more verbose version of the same thing. Even if you read the Twig docs, if you’re pretty sure you already understand what {{variable}} does, you’re not going to pay close enough attention to it.

I believe that skipping {{ … }} tags entirely in the initial introduction, and introducing them as a shortcut for {% print … %} should avoid that trap. (And I’m not saying Twig’s official docs should necessarily take that approach; but it would make sense for 3rd party introductions aimed at less technical designers.)

I'm going to close this one as I'm still not convinced we need to change anything here.

Was this page helpful?
0 / 5 - 0 ratings