Negation in template syntax

[Mark Rickerby]

I've done a bit of work over the past week to add negation to the template engine, but after a discussion with Sam, won't commit any new code to the existing SSViewer. We prefer the approach of developing a separate scanner/parser generated from a grammar specification (see PEAR's PHP_LexerGenerator).

However, this work prompted a bit of discussion surrounding the syntactic form that negation should take in template blocks, and I'd be very interested in hearing more opinions about a good direction to head in...

eg:

<% if !Variable %>

vs stealing 'unless' from Perl:

<% unless Variable %>

The !Var syntax is natural to most programmers used to Algol style languages, but it isn't the most declarative style for a template language - I prefer 'unless' simply because having such a specific construct for negation solves the most common use case of switching a block on or off by checking a single value (rather than the result of an expression, which is a less common use case).

<% Variable != Value %> introduces the use of the ! sigil for negation, but in this case, != is an operator in an infix expression with left and right operands.

!Variable is syntactic sugar for an boolean operand evaluated under 'if' (eq to Variable != true or Variable == false), wheras 'unless' is a statement itself, symmetric to 'if' (though there doesn't seem to be a practical difference).

I prefer to see the template language leading from declarative natural language as closely as possible, hence my +1 vote for 'unless'.

SilverStripe is already doing quite well in this regard, especially in comparison to Smarty et al, and even Django. After doing more with the SS syntax for a couple weeks, I definitely much prefer the way that 'control' scopes work, as opposed to annoying looping constructs in other template languages. In the same way, I feel that 'unless' works really well here, but I appreciate it may not be to everyone's taste.

The reason why I like it is that although it's not as concise as the operand, using the specific keyword statement fits in better with the general declarative look of HTML, a little easier on the eye, and doesn't feel like jumping into programming or mathematical expressions in the template.

There's no reason why we couldn't support both, except for the slippery slope problem of course, in that taking the philosophy of Perl (TIMTOWTDI) is probably NOT the right way to approach designing a template syntax ;)

There's also no reason why we can't move towards a pluggable syntax, once we have swapped out the regex cascade in SSViewer with a more modular lexical analyzer.

This would mean that as long as the right events were emitted from the lexer, it would be possible to have a Smarty or Django style syntax compile to the common Sapphire template infrastructure... I see this as a "nice to have", and absolutely the furtherest thing from being a priority, but I think it would keep a few people happy, and contribute to encouraging more experienced developers to pick up SilverStripe as a framework.

I personally like the idea of keeping the SS syntax concise and to the point. Smarty is a total kitchen sink situation, wheras the control blocks in SS encourage a more declarative and HTML friendly way of thinking, which is the very point of having an HTML embedded template syntax in the first place.

When you reach the point of having a turing complete template language, you know you've failed.

[Sigurd Magnusson]

I think unless is [visually, cognitively] clearer and accordingly fits with our one of key goals: simplicity

[dio5]

Just my 2 cents:

I feel that using <% if ! Variable %> feels much more natural and
standard then <% unless Variable %>
The exclamation is used almost everywhere for negation, so I don't see
the point in not using it here.

If you choose for unless, I'd still allow for ! too, because a lot of
php developers or frontend developers will be
more familiar with that, than with the perl 'unless', although it's
probably just something to get used to.

The other options mentioned here are more useful imho:

the use of != | > | < | <= | => in templates. That would be great.

[in...@lemon8.nl]

I don't know if my opinion is wanted here, but I absolutely agree with
Dio.
One thing I dislike in a lot of CMS's & Frameworks is the way they
introduced new 'scripts' , constructs and/or completely new
languages. Why should an experienced PHP coder have to go through the
hassle of learning a specific (and often counterintuitive) syntax of
the templating-system ? It creates unnecessary frustration in my
opinion.

Great work though !! This will be a great feature !

[Mark Rickerby]

On Feb 7, 12:17 pm, dio5 <reddesertvandri...@gmail.com> wrote:

I feel that using <% if ! Variable %> feels much more natural and

standard then <% unless Variable %>

The exclamation is used almost everywhere for negation, so I don't see

the point in not using it here.

Ok, all you guys have convinced me that there are good grounds for including the ! Var syntax... after thinking about it, I don't see why we can't do both given that it's going to be compiling to the exact same PHP code anyway. I've heard enough positive feedback about both variations to think they're worth including.

On 8/02/2008, at 11:16 AM, fuz...@gmail.com wrote:

One thing I dislike in a lot of CMS's & Frameworks is the way they

introduced new 'scripts' , constructs and/or completely new

languages.  Why should an experienced PHP coder have to go through the

hassle of learning a specific (and often counterintuitive) syntax of

the templating-system ? 

99% of the hassle is in having to work within the constraints of an MVC architecture. The alternative is freeform PHP spaghetti mixed in with the HTML.

In the case of SilverStripe, the custom template language actually saves quite a lot of effort in terms of binding variables/datastructures to templates... 

The equivalent in a 'push' style template engine would involve manually assigning every object to the template...

$template->assign('collection', $collection);

SSViewer makes all the properties of the controller/dataobjects available to the template directly (a 'pull' style template engine).

Saves a lot of fussing around with data, where the trade off is that you have to learn a new syntax for control structures. I think it's a fair tradeoff, given that the SS syntax looks very reasonable in comparison to the equivalent PHP or Smarty:

<% control Collection %>

     $Item.Name

<% end_control %>

<?php foreach($collection as $item) { ?>

   <?php echo $item->name; ?>

<? } ?>

{foreach from=$collection item=item}

    {$item.name}

{/foreach}

{section name=item loop=$collection}

    {$collection[item].name}

{/section}

I do see the irony, that PHP itself was originally a template engine, but all software is just abstractions layered on top of abstractions. It can be annoying at first, but once you learn a new template syntax it can make common tasks simpler.

[Michael Gall]

As a developer, I'm happy to write templates in PHP or a custom syntax, but as far as I'm concerned there are a couple of problems with the template engine. In saying that, I think the template engine is the way to go.

Anyway the 1st problem I have is it's limitations, that is that you can't access stuff out of the current context (on it's way to being solved) and 2 you that can't access variables evaluated variables when calling functions. To explain:

<% control ChildrenOf($Page.IDOfAnotherPage) %>
<% end_control %>

and the second problem is it's debuggability. There is no tool support for the custom syntax like a plugin for eclipse, and this causes you to feel like you are sometimes shooting blindly. Further to that, the way ViewableData interacts with SSViewer, you can be calling a accessing a function/property that doesn't exist and you receive no feedback.

Anyway, if you'd like input on any patches that you are developing, I'd be happy to take a look and/or test and review them I'd be happy to.


Cheers,

Michael
--

http://wakeless.net

[Sam Minnee]

> and the second problem is it's debuggability. There is no tool support for
> the custom syntax like a plugin for eclipse, and this causes you to feel
> like you are sometimes shooting blindly.

I think that it should feasible to build compile error-checking into
the new context-free grammar based parser that Mark has started work
on. This will help immensely here :-)

> Further to that, the way
> ViewableData interacts with SSViewer, you can be calling a accessing a
> function/property that doesn't exist and you receive no feedback.

This is "a feature not a flaw" :-P. Joking aside, one of the use-
cases was to allow for a variable that evaluated to "" if it isn't
defined by that class. For instance, we often put $Form into our
Page.ss template, and then define a Form() method on just the classes
that we want to display a form.

To solve this, we could have some kind of debugger mode that provided
more feedback about this kind of thing.

> Anyway, if you'd like input on any patches that you are developing, I'd be
> happy to take a look and/or test and review them I'd be happy to.

I think we're going to set up a separate svn branch for the
development of the new parser, so it will be available for public read
access.