> I've derived them from the regex and
> I think they're correct, but they need to be reviewed.
Tests are the only way that we can reliably ensure that these are
correct.
> The change also opens up the possibility of extending/modifying the
> templating behavour. Some more work would be needed to create a proper
> API, but it does allow you to, for example, append new templating
> rules if you so wish.
>
> The included features are:
>
> + A new <% parent %> tag. Seehttp://
open.silverstripe.org/ticket/4751
>
> This allows you to traverse up the template item stack to access
> parent View items. Currently this isn't possible from the template
> system - E.g. while looping through a many-many child object, you
> can't refer to the current parent item.
I agree that this is a very useful feature, but I'm not sure about the
naming. We currently have $Top - I was thinking that $Up might be
better? This would distinguish it from <% control Parent %> more
explicitly too.
Additionally, I don't think it should be a separate <% keyword %>. <
% control Up %> or $Up.Title would be more in keeping with the rest of
the template language.
> + Make Requirements calls conditional. See
http://open.silverstripe.org/ticket/4188
> This was a change submitted by Simon W that fits into the patch
> nicely. This slightly changes the way Requirements are added to the
> template, by evaluating them within the other control structures
> rather than etracting them all and executing them. This means that a
> Requirements block within a <% if %> block will only be evaluated if
> the
Good to have them included. :-)
> Tests for the vast majority of template tags don't exist. I started on
> some basic tests as part of 4751 (and Simon included tests for the
> changes mentioned din 4188), but we really a complete test suite for
> such a basic component. Anyone want to help?
Yeah, the lack of tests is a major reason why the SSViewer system has
stagnated - without tests, it's very dangerous to muck with such a
byzantine piece of code. One word of caution: ensure that we test the
output of the template engine, and not the generated PHP. Otherwise
we won't be able to use the tests for more radical re-workings of the
template engine. In addition, tests on the output will be easier to
write.
We're going to need more a few more tests before we could merge this
patch. Hamish, the comments on your patch give us a nice list of the
things that we need to test. Although there are a big list of items,
it shouldn't be too hard to extend SSViewerTest to include test cases
for these.
Ideally, we should build the test as a separate patch, apply them to
the current template engine and confirm that they work, and then apply
your template engine upgrades.
<%-- Template Comment --%>
<% debug %>
<% debug Foo %>
<% base_tag %>
<% current_page %>
$Iteration
{$Foo(Arg1, Arg2).Bar.Val}
{$Foo(Arg1, Arg2)}.Val}
{$Foo(Arg1, Arg2)}
{$Foo(Arg1).Bar.Val}
{$Foo(Arg1).Bar}
{$Foo(Arg1)}
{$Foo.Bar.Val}
{$Foo.Bar}
{$Foo}
$Foo.Bar(Arg1)
$Foo.Bar(Arg1, Arg2)
$Foo(Arg1, Arg2).Bar.Val
$Foo(Arg1, $Arg2).Bar
$Foo(Arg1, Arg2)
$Foo(Arg1).Bar.Val
$Foo(Arg1).Bar
$Foo(Arg1)
$Foo.Bar.Val
$Foo.Bar
$Foo
<% control Foo %>
<% control Foo.Bar %>
<% control Foo.Bar(Arg1) %>
<% contorl Foo(Arg1) %>
<% control Foo(Arg1, Arg2) %>
<% control Foo(Arg1, Arg2, Arg3) %>
<% end_control %>
<% parent %>
<% end_parent %>
<% if Foo % >
<% else_if Foo %>
< % if Foo.property %>
<% else_if Foo.property %>
<% if Foo.Bar.Val %>
<% else_if Foo.Bar.Val %>
< % if Foo(parameter) %>
< % if Val1 || Val2 %>
<% else_if Val1 || Val2 %>
< % if val1 && val2 %>
<% else_if Val1 && Val2 %>
< % if Val1 == Val2 %>
<% else_if Val1 == Val2 %>
< % if Val1 != Val2 %>
<% else_if Val1 != Val2 %>
<% else %>
<% end_if %>
<% _t(...) %> with entity only (no dots in namespace). current
template filename will be added as a namespace
<% _t(...) %>
<% sprintf(_t(...),$argument) %> with entity only (no dots in
namespace). current template filename will be added as a namespace
<% sprintf(_t(...),$argument) %>