Smarty 3.0 syntax

[Monte Ohrt]

I'm thinking hard about this change to Smarty. It's a pretty major one,
but it would simplify not only the Smarty tag syntax, but also the
learning curve, among several other things. Feedback please!

We would introduce a new cleaner Smarty 3 syntax, which is a much closer
syntax to PHP. As a matter of fact, it is identical except for a few
changes in delimiters and things.

Examples:

PHP: <?= $foo ?>
Smarty: {$foo} // same as Smarty 2

PHP: <?= $foo['bar'] ?>
Smarty: {$foo['bar']} // no more {$foo.bar}

PHP: <?= $foo[$bar][$foo['bar']] ?>
Smarty: {$foo[$bar][$foo['bar']] ?> // identical to PHP

PHP: <?php foreach($foo as $bar) { ... } ?>
Smarty: {foreach $foo as $bar} ... {/foreach} // just a delimiter
adjustment

PHP: <?php for($x = 0; $x<$y; $x++) { ... } ?>
Smarty: {for $x=0; $x<$y; $x++} ... {/for} // get rid of {section}

PHP: <?php if($foo == $bar && $blah !== 'ziggy') { ... } ?>
Smarty: {if $foo == $bar && $blah !== 'ziggy'} ... {/if}

Basically, the Smarty 3 variable syntax is identical to PHP, except for
a few semantic changes. We still follow the { } syntax instead of <?php
?>. BUT, you don't have to learn a bunch of new language constructs.
Everything follows straight over from PHP. This also helps the Smarty
compiler, it would basically be a prefilter to change over the Smarty
tags to PHP tags, then the PHP tokenizer does the majority of the work.

This would also make template syntax your choice: If you want to use
{$foo} or <?=$foo?>, that is up to you. You can use 100% PHP syntax in
your templates if you'd like. We could also keep some of the other nicer
Smarty 2 syntax options:

{if $foo eq $bar and $blah ne 'ziggy'} ... {/if}

This is still a thought in process, but I'd like to hear some of your
thoughts about it. I haven't thought through the entire impact yet, but
I think it would be a positive one.

[Pratik]

Hi,

All this sounds very promising and will definitely be very useful for
new smarty developers as the syntaxes would be very similar to that of
PHP.

But what about backward compatibility? For e.g. I have developed a
couple of big portals using smarty and if I would like to implement
Smarty 3, there could be a lot of code changes required which will not
be an attractive proposition for people using smarty. Hence backward
compatibility is something that will have to be taken care of.

Thanks

[Monte Ohrt]

There will likely be a Smarty2 compatibility compiler available.

[Jan Černý]

Hi,

changes are good but i very like "dot" array syntax :(  

{foreach from=$press item=i }

    <div class="item">

        <p title="{$i.title}"> {$i.text} </p>

        <span class="name">{$i.name}</span>

        <span class="date">, {$i.time}</span>

    </div>

{/foreach}

its easy to read and write ... in new syntax it's similar like php and the question is why smarty :) ?

iX

[Monte Ohrt]

This is a good question for discussion. This is really the only syntax
change I'm up in arms with too, because everything else is pretty
minimal. I like the simplicity of the dot syntax myself, and here is a
comparison:

// proposed new syntax, just like PHP
{$foo['bar']['blah']}

// current smarty "dot" syntax for accessing array indexes
{$foo.bar.blah}

As you can see, the new syntax follows PHP conventions, so things like:

{$foo[$bar['blah']]['baz']}

are possible, where as the dot syntax can't handle that. Also, using dot
syntax for variable indexes conflicts with PHP catenation features,
which we want to add to the general template syntax. So then comes the
question, what is more important, the dot syntax for array indexes, or
extending template features that stick close to the PHP way of doing
things? If we DID keep the smarty2 dot syntax, then how would catenation
work?

As in the question "why smarty", you still get all the benefits from the
rest of the template framework (caching, customizable resources,
security, etc.). This "dot" syntax really is the only major change that
makes the tag syntax more flexible, but at the same time less clean.

There are also some things (following PHP syntax) that actually simplify
smarty syntax. Example:

Smarty2:
{foreach from=$foo key="key" item="item"}

Smarty3:
{foreach $foo as $key => $item}

Monte

Jan Černý wrote:
> Hi,
>
> changes are good but i very like "dot" array syntax :(
>
>
> {foreach from=$press item=i }
> <div class="item">
> <p title="{$i.title}"> {$i.text} </p>

> <span class="name">{$i.name <http://i.name>}</span>

[Michael Hurni]

Hi,

about the foreach syntax, I suggest you :

{for $item in $foo}
    ...
{/for}

or with key

{for $key, $item in $foo}

It could be an alternative syntax, not necessary the only one.
This way is more js than php.. but you know that if we use smarty, it's to NOT use php in our tpl :)
so should be smarty so much similar to php?

regards,

Michael Hurni

2008/10/20 Monte Ohrt <mo...@ohrt.com>

[Sebastian Mendel]

Monte Ohrt schrieb:
> [...] Also, using dot

> syntax for variable indexes conflicts with PHP catenation features,
> which we want to add to the general template syntax.

is a catenation char really required?

{$foo} {$bar}

{$foo ' ' $bar}

{assign var='foobar' value=$foo ' ' $bar}

or the comma (like you can use in HP):

{$foo, ' ', $bar}

{assign var='foobar' value=$foo, ' ', $bar}

--
Sebastian Mendel

[Mark Rogers]

Monte Ohrt wrote:
> As you can see, the new syntax follows PHP conventions, so things like:
>
> {$foo[$bar['blah']]['baz']}
>

Current dot syntax may struggle in some places but to me that is an
argument for enhancing dot syntax rather than losing it. For example I
think both of the following are unambiguous:
{$foo[$bar.blah].baz}
{$foo.`$bar.blah`.baz}

> If we DID keep the smarty2 dot syntax, then how would catenation
> work?
>

Possibly {$foo . $bar} (ie whitespace around the dot) but I think that's
asking for trouble.

I did think about moving from dot syntax to a more object-like syntax
{$foo->bar}
{$foo->`$bar->blah`->baz}
{$foo->($bar->blah)->baz} Maybe more intuitive?

I don't see why the template designer should care whether the veriable
is an object or an array, the same syntax could support both.

> As in the question "why smarty", you still get all the benefits from the
> rest of the template framework (caching, customizable resources,
> security, etc.). This "dot" syntax really is the only major change that
> makes the tag syntax more flexible, but at the same time less clean.
>

As a PHP dev I am happy with a more PHP-based syntax, however we also
have to get template designers to do the work who really don't know PHP
and (little knowledge = dangerous thing) really shouldn't.

> Smarty3:
> {foreach $foo as $key => $item}
>

How are other loop variables handled within this construct, eg in Smarty 2:
{foreach name=bar from=$foo key=key item=item}
{$smarty.foreach.bar.iteration}
{if not $smarty.foreach.bar.last},{/if}
{/foreach}
(Minimal example, obviously there are other ways of handling such a
simple example.)

--
Mark Rogers // More Solutions Ltd (Peterborough Office) // 0845 45 89 555
Registered in England (0456 0902) at 13 Clarke Rd, Milton Keynes, MK1 1LG

[Monte Ohrt]

Mark Rogers wrote:
> Monte Ohrt wrote:
>
>> As you can see, the new syntax follows PHP conventions, so things like:
>>
>> {$foo[$bar['blah']]['baz']}
>>
>>
>
> Current dot syntax may struggle in some places but to me that is an
> argument for enhancing dot syntax rather than losing it. For example I
> think both of the following are unambiguous:
> {$foo[$bar.blah].baz}
> {$foo.`$bar.blah`.baz}
>

The first one looks doable. So then the question, keep the dot syntax in
favor of PHP catenation syntax, and come up with another way to catenate?

>
>> If we DID keep the smarty2 dot syntax, then how would catenation
>> work?
>>
>>
>
> Possibly {$foo . $bar} (ie whitespace around the dot) but I think that's
> asking for trouble.
>

yes, trouble.

> I did think about moving from dot syntax to a more object-like syntax
> {$foo->bar}
> {$foo->`$bar->blah`->baz}
> {$foo->($bar->blah)->baz} Maybe more intuitive?
>

This just stirs the pot, no we're using object syntax for indexing. It's
not much better than just {$foo['bar']}

> I don't see why the template designer should care whether the veriable
> is an object or an array, the same syntax could support both.
>
>
>> As in the question "why smarty", you still get all the benefits from the
>> rest of the template framework (caching, customizable resources,
>> security, etc.). This "dot" syntax really is the only major change that
>> makes the tag syntax more flexible, but at the same time less clean.
>>
>>
>
> As a PHP dev I am happy with a more PHP-based syntax, however we also
> have to get template designers to do the work who really don't know PHP
> and (little knowledge = dangerous thing) really shouldn't.
>
>> Smarty3:
>> {foreach $foo as $key => $item}
>>
>>
>
> How are other loop variables handled within this construct, eg in Smarty 2:
> {foreach name=bar from=$foo key=key item=item}
> {$smarty.foreach.bar.iteration}
> {if not $smarty.foreach.bar.last},{/if}
> {/foreach}
> (Minimal example, obviously there are other ways of handling such a
> simple example.)
>
>

This hasn't been determined yet, but it may be just:

{foreach $foo as $key => $item}

{$smarty.foreach.iteration}
{$smarty.foreach.last}
{/foreach}

No naming involved, and only works within the loop.

Or maybe, if you use the php-style syntax, it is up to you to determine your own constructs with php-style declarations:

{foreach $foo as $key => $item}

The index is {$key}.
The iteration is {$key - 1}.
{if count($foo) < $key - 1}
This is the last row.
{/if}
{/foreach}

[Mark Rogers]

Monte Ohrt wrote:

The first one looks doable. So then the question, keep the dot syntax in 
favor of PHP catenation syntax, and come up with another way to catenate?
  

It's unfortunate that the syntax clashes in this way, I agree - I don't have a good solution other than (I thought :-) object syntax.

I did think about moving from dot syntax to a more object-like syntax
    {$foo->bar}
    {$foo->`$bar->blah`->baz}  
    {$foo->($bar->blah)->baz} Maybe more intuitive?
  
    

This just stirs the pot, no we're using object syntax for indexing. It's 
not much better than just {$foo['bar']}
  

Well I'm not sure why the template designer should need to know or care of the difference between $foo->bar (where $foo is an object) and $foo['bar'] (where $foo is an array). In the past I'd have suggested that $foo.bar ought to work fine for both cases, but given the dot-concatenation vs dot-index issue, $foo->bar seems less ambiguous and (personally)

    {$foo->`$bar->blah`->baz}

is much more readable than
    {$foo[$bar['blah']]['baz']}

This hasn't been determined yet, but it may be just:

{foreach $foo as $key => $item}
  {$smarty.foreach.iteration}
  {$smarty.foreach.last}
{/foreach}

No naming involved, and only works within the loop.
  

Breaking nested loops I think would be problematic.

Or maybe, if you use the php-style syntax, it is up to you to determine your own constructs with php-style declarations:

{foreach $foo as $key => $item}
  The index is {$key}.
  The iteration is {$key - 1}.
  {if count($foo) < $key - 1}
     This is the last row.
  {/if}
{/foreach}
  

This wouldn't work for associative arrays, which is the environment I was thinking about.

[Monte Ohrt]

Another idea on {foreach}, comments welcome.

{foreach $foo as $idx => $var}
{$_iteration}
{$_last}
{/foreach}

Now we have a nice short variable, no loop naming, and works only within
the loop. (Now that we have a lexer, the above is possible.)

One issue is clashing with assigned tpl vars. We can either conform to
the idea that $_foo var naming is not allowed by assign(), or we can
make a different syntax, such as {($)last}, or the current smarty2
convention of {%last%}. I like the idea of the rule, no $_foo vars in
the tpl except for internal vars created by smarty. {$_foo} is short and
clean, and easily detected as internal in the tpl.

Then there is of course, the issue of nested loops. I think that the
scope of {$_foo} is the current loop:

{foreach $foo as $idx => $var}
{$_iteration}{* outside loop *}
{$_last}
{foreach $var as $idx2 => $var2}
{$_iteration} {* new iteration for this loop *}
{$_last}
{/foreach}
{$_iteration} {* back to outside loop *}
{/foreach}

We would (internally) push the vars on and off a stack so they don't
collide. Normally you wouldn't need access to internal vars from a
parent loop, but we could allow something like {$_parent.$_iteration},
assuming we keep the dot=array syntax.

[patrick]

I dont‘ think the PHP syntax approach ist he right way. As I know, the
separation of business logic and UI isn’t only limited tot he code.
The teams are divided the same way as well. Guys working at the HTML
code aren’t into PHP, but they cope with their profession nearly
perfect.
If we use the PHP syntax for smarty templates, Front-End Engineers
won’t have it easy. I think the smarty syntax should be as simple as
possible and hence support the Front-End coders.
As mentioned by Mark Rogers, a Front-End coder won’t really have to
care about if the variable is an array or a object.
Since most Front-End coders are familiar with JavaScript, we could use
a similar syntax for smarty. As they already would know most of the
syntax, it’ll be easy for them to cope with the smarty syntax. Oh, and
getting rid of {section} is a fantastic idea.
Concerning the dot syntax I agree with Sebastian Mendel. Okay, a
catenate modifier for arrays would be great, see the first example
(actually it’s something like the spacify modifier with a little
modification).
Some examples of what I’m talking about:
Example 1:
PHP:
…
$tags = array(‘tag1‘,‘tag2‘,‘tag3‘,‘tag4‘);
…
Smarty:
…
{$tags|catenate:“, “} // Results in "tag1, tag2, tag3, tag4"
{$tags|catenate:", ":" and "} // Results in "tag1, tag2, tag3 and
tag4"
…

Example 2:
PHP:
…
$customers = array();
$customers[0] = new Customer(‘Peter‘, ‘33‘);
$customers[1] = new Customer(‘Sally‘, ‘32‘);
…
Smarty:
…
{for $customer in $customers}
<li>$customer.name, $customer.age</li>
{/for}
…
Or this one:
…
{for $x = 0; $x < $customers.length; $x++}
<li>$customers[$x].name, $customer[$x].age</li>
{/for}
…
Example 3:
…
$customers = array();
$customers[‘Peter‘] = 33;
$customers[‘Sally‘] = 32;
…
Smarty:
…
{for $key, $value in $customers}
<li>$key, $value</li>
{/for}
Peter is {$customers.Peter} years old.
…

As far as I can see, there’s only one problem:
If the usage of arrays and objects is the same, what happens if an
object is given to a for loop? Does looping through the properties
make any sense? Or do we get an error?

[Monte Ohrt]

patrick wrote:
> I dont‘ think the PHP syntax approach ist he right way. As I know, the
> separation of business logic and UI isn’t only limited tot he code.
> The teams are divided the same way as well. Guys working at the HTML
> code aren’t into PHP, but they cope with their profession nearly
> perfect.
>

Agreed. Although, I don't think there is going to be a problem letting
both syntaxes work. So:

{$foo.bar.blah}

Is the recommended syntax, however, PHP die-hards can use:

{$foo['bar']['blah']}

And will give the same result.

I think we unanimously agree, we should keep the dot syntax for array
access. That means, we should find a solution for catenation. Modifiers
are a work-around solution, but having catenation in the tpl syntax
would be a big bonus.

Javascript uses "+" for catentation, but that conflicts with template math.

We could make some new syntax:

{$foo(+)$bar}
{$foo(.)$bar}
{$foo..$bar}

Ideas?

Here we are replacing {foreach} with {for} ? Are we proposing ridding
{section} and {foreach}, and going with a new {for} syntax that covers
both bases? I like this syntax btw.

> …

> Or this one:
> …
> {for $x = 0; $x < $customers.length; $x++}
> <li>$customers[$x].name, $customer[$x].age</li>
> {/for}
> …
> Example 3:
> …
> $customers = array();
> $customers[‘Peter‘] = 33;
> $customers[‘Sally‘] = 32;
> …
> Smarty:
> …
> {for $key, $value in $customers}
> <li>$key, $value</li>
> {/for}
>

Good syntax for the {for} loop. Again, can we cover the requirements of
{section} and {foreach} with a new {for} syntax?

> Peter is {$customers.Peter} years old.
> …
>
> As far as I can see, there’s only one problem:
> If the usage of arrays and objects is the same, what happens if an
> object is given to a for loop? Does looping through the properties
> make any sense? Or do we get an error?
>

You would get the same error as PHP, likely. I'm still not solidified on
the idea of mixing the syntax for array and object access. There is
purpose to distinguishing between the two, and this keeps things much
simpler in the compiler.

{$foo.bar.blah}
{$foo->bar->blah}

[Monte Ohrt]

Here is a syntax idea from Uwe Tews:

{for $var in $myarray}
the key for $var is {$var@key}
the iteration is {$var@iteration}
{if $var@last}
last row...
{/if}
{/for}

Basically, the var name being looped is the loop name. Thoughts on that?

[patrick]

That's great. I think this one's better than the @ syntax. Are you
planning to indicate all internal smarty vars this way? So $smarty
would be $_smarty?

[patrick]

On Oct 21, 5:17 pm, Monte Ohrt <mo...@ohrt.com> wrote:
> ...

> Javascript uses "+" for catentation, but that conflicts with template math.
>
> We could make some new syntax:
>
> {$foo(+)$bar}
> {$foo(.)$bar}
> {$foo..$bar}
>
> Ideas?

What about &? I hope you don't mind that I don't know wether this is a
reserved char or not...
{$foo&$bar}
Well, looks a bit strange, but you could put spaces around the & if
you like.
{$foo & $bar}
Is it great or is it great? (Or is & already in use? :) )

[Monte Ohrt]

Again, conflicts with template math. However, {$foo..$bar} would not
conflict with anything, and is similar to the php catenation syntax.

[Monte Ohrt]

It needs to tie into the loop name in a for loop, so it needs the var
name. How about:

{for $var in $myarray}
{$var:iteration}
{/for}

[patrick]

On Oct 21, 6:32 pm, Monte Ohrt <mo...@ohrt.com> wrote:
> It needs to tie into the loop name in a for loop, so it needs the var
> name. How about:
>
> {for $var in $myarray}
>   {$var:iteration}
> {/for}

Sorry, but I don't understand it... why do we need that $var? why
can't we just use $_iteration, $_last, and so on? You've provided a
solution for nested loops as well, I don't see any problems here.

[Monte Ohrt]

It is cleaner (and clearer) to tie the info to the loop. Especially in a
nested loop, it makes accessing external vars straight forward. It is
also much easier on the tokenizer. If we just do {$_index} then there is
nothing visually tying this to the loop, and we have to internally stack
them. Instead of having to name the loop, we can just use the var name
being used as the iterator.

[patrick]

Ah, okay. I get it.
Then I'd prefer $var:iteration.

Is there a way of getting the amount of elements in an array inside
the templates? If not, I got a little idea.
We could access array elements this way : {$array.$element}
to be able to do something like this: {$array.length}, let's say
builtin properties.
Stupid?

[Monte Ohrt]

{$foo.bar}syntax is already used for accessing array keys. I guess the
{$foo:bar} syntax could be though of as variable properties, such as
{$foo:length} could return the length of $foo (string or array). But
there are already ways to get at info like this such as {count($foo)} or
{$foo|count} or {$foo|strlen}

[Monte Ohrt]

I think we have landed on a solution:

{$foo . $bar} is traditional array access, just like Smarty2.

{$foo & $bar} will be for catenation, since the "&" math operator is
hardly useful in a template.

Thoughts?

[Pratik]

Brilliant

[patrick]

I love it. :-)
btw, I already love smarty3 now.

[U.Tews]

Last night the SVN has been updated.

The new Smarty3 syntax for {for...} loops are implemented.

There are two different styles.
To loop over an array:
{for $var in $myarray} .... {/for}
$var:key will deliver the key
$var:iteration will deliver the iteration
$var:total will deliver the total number of array entries

For a counting for loop:
{for $x=0, $y=count($foo); $x<$y; $i++} .... {/for}
Any number of statements can be used separated by comma as the first
inital expression at {for}

The old Smarty2 {foreach} syntax is currently still in for BC.
We still have to decide if we will keep the old {section} syntax for
BC.

Array indicies can be accessed currently in the old style like
$foo.bar.bla or PHP like $foo['bar']['bla'].

For catenation the use of & is implemented. {$foo&$bar}

We will use $_xxx syntax for smarty special vars. You can already
access $_GET, $_POST, $_SESSION etc like this: $_get.foo or
$_get['foo'].

Smarty3 has already some short commings of Smarty2 resolved. You can
nest variables to use array elements of one variable as index for
another: $foo.{$bar.bla}
or have variable variables: $foo_{$bar}.
This will remove the requirements of temporary assignments of Smarty2

[Sebastian Mendel]

On 2008-10-21 21:41, Monte Ohrt wrote:
> I think we have landed on a solution:
>
> {$foo . $bar} is traditional array access, just like Smarty2.
>

> {$foo& $bar} will be for catenation, since the "&" math operator is

> hardly useful in a template.
>
> Thoughts?

so bit operations are not required in templates?

why not using || as concat operator?

it would be the same as in ANSI SQL, at least not something competely new

also see:

http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(strings)

i think there are some much better variants, which do not lead into
ambiguity

--
Sebastian Mendel

[Monte Ohrt]

We already use || as logical OR in the templates, same as PHP.

I have never seen a bit operation used for anything purposeful in a
template. If you REALLY needed bit operations, you could write a plugin
to handle it, or write your own compiler resource to your liking.

[Monte Ohrt]

My other option for catenation was ".."

{$foo .. $bar}

But it kind of looks like a syntax error too :)

We are open to all ideas, bring 'em on!

[Cameron Perry]

I personally like the idea of the single dot for concatenation. It's
nice because it does it the PHP way, and the difference between "."
and ".." can be tough to catch as you're working through code/bugs.

~Cameron

[U.Tews]

Single dot can't be used as long as we are keeping it as array index
separator to be compatible with smarty2 syntax

[Cameron Perry]

True. Is there any reason we can't use + as many other languages do?
It may be less intuitive for non-programmer types, but at least we do
have a {math} function to clarify what is a mathematic function, and
what is not.

~C

[U.Tews]

{math} is no longer existant as expresions can be used directly in the
template anywhere. I think & is a good as it it will be unique in our
syntax and by the way it's also used by other languages like Visual
BASIC. I think we should stick to it.

[markus...@redaxo.de]

maybe one of the following could do the trick

1. {cat($foo, $bar, $baz)}
2. {strcat($foo, $bar, $baz)}
3. {concat($foo, $bar, $baz)}

[markus...@redaxo.de]

maybe also {cat $bar $baz $foo} would be nice

On Oct 22, 7:27 pm, "U.Tews" <uwe.t...@googlemail.com> wrote:

[Monte Ohrt]

yes you can use functions to do the trick, however it would be helpful
to have catenation as part of the template syntax.

In smarty2 you can already to cat($foo,$bar) (providing you have the
function) or $foo|cat:$bar

[markus...@redaxo.de]

using the & operator is not a good idea i think.. most people guess
the functionality of the equal named php operators

On Oct 23, 6:38 pm, Monte Ohrt <mo...@ohrt.com> wrote:
> yes you can use functions to do the trick, however it would be helpful
> to have catenation as part of the template syntax.
>
> In smarty2 you can already to cat($foo,$bar) (providing you have the
> function) or $foo|cat:$bar
>

[Mark Rogers]

maggus...@googlemail.com wrote:
> maybe also {cat $bar $baz $foo} would be nice
>

Is that any different from this?
{$bar}{$baz}{$foo}

The only place I can see concatenation matters is in more complex
situations but I'm still not sure what they might be.

In what situations would
$bar$baz$foo
or
$bar"baz"$foo
be ambiguous?

Silly question: Do we need a concatenation operator?

--
Mark Rogers // More Solutions Ltd (Peterborough Office) // 0845 45 89 555
Registered in England (0456 0902) at 13 Clarke Rd, Milton Keynes, MK1 1LG

[Sebastian Mendel]

maggus...@googlemail.com schrieb:
> using the& operator is not a good idea i think.. most people guess

> the functionality of the equal named php operators

yes, this is my concern too

> On Oct 23, 6:38 pm, Monte Ohrt<mo...@ohrt.com> wrote:
>> yes you can use functions to do the trick, however it would be helpful
>> to have catenation as part of the template syntax.
>>
>> In smarty2 you can already to cat($foo,$bar) (providing you have the
>> function) or $foo|cat:$bar
>>
>> On Oct 23, 2008, at 11:28 AM, maggus.st...@googlemail.com wrote:
>>
>>
>>
>>> maybe one of the following could do the trick
>>> 1. {cat($foo, $bar, $baz)}
>>> 2. {strcat($foo, $bar, $baz)}
>>> 3. {concat($foo, $bar, $baz)}
>>> On Oct 22, 7:27 pm, "U.Tews"<uwe.t...@googlemail.com> wrote:
>>>> {math} is no longer existant as expresions can be used directly in
>>>> the

>>>> template anywhere. I think& is a good as it it will be unique in our

[Sebastian Mendel]

Mark Rogers schrieb:

> maggus...@googlemail.com wrote:
>> maybe also {cat $bar $baz $foo} would be nice
>>
>
> Is that any different from this?
> {$bar}{$baz}{$foo}
>
> The only place I can see concatenation matters is in more complex
> situations but I'm still not sure what they might be.
>
> In what situations would
> $bar$baz$foo
> or
> $bar"baz"$foo
> be ambiguous?

$foo.bar$foobar

could mean:

($foo.bar)$foobar
// $foo['bar'] . $foobar

or

$foo.(bar$foobar)
// $foo['bar' . $foobar]

> Silly question: Do we need a concatenation operator?

i asked the same ...

--
Sebastian Mendel

[Monte Ohrt]

This is no different than the case of "." for catenation. It is not
the same as PHP. So I guess the question is: since "." is taken, do we
supply the template designer with a catenation operator? And if so,
what is the best choice?

If we don't supply one, then so be it. Question answered. If we do
supply one, what do we use? "&" is a choice that doesn't conflict with
other template syntax, and is a lesser-used PHP operator that would
hardly be useful in a template (not nearly as useful as catenation.)

There is usually a way around catenation when the need arises, so
maybe it would be fine to leave it out.

example, if you want:

{assign var="foo" value=$foo&$bar.blah}

instead do:

{assign var="foo" value="$foo {$bar.blah}"}

etc.

[messju]

my suggestion is to use . for array dereference and _ for
concatenation
(in relation to what as andrei suggested once for php:
http://www.gravitonic.com/software/php/ (Concatenation and object
operator change))

the original proposal would use . for object dereference not for array
dereference.
do we plan to have more arrays or more objects inside template in the
future?
the . should be used for the more common case, obviously.

the best solution may be to use . for array *and* for object
dereference. but that would be impossible to determine at compile time
and hard to do efficiently at runtime.

just a thought
messju

[Sebastian Mendel]

On 2008-10-24 00:13, messju wrote:
> my suggestion is to use . for array dereference and _ for
> concatenation

using _ for concatenation is something i would strong disagree

btw. "It was a crazy idea anyway"
and it would require spaces around _ do not interfer with _ in var anmes

introducing requirement for spaces around operators is something i would
disagree too (even i personally prefer to write it with spaces all the time)

i think there are many good choices on the already mentioned wiki page,
better than &

[$var " foo " $foo.bar]
"$var foo $foo.bar"
$var~" foo "~$foo.bar
$var, " foo ", $foo.bar

$var || " foo " || $bar
(smarty could stick to 'or', 'and' instead of || and &&, but this would
break with PHP syntax ...)

btw. removing or at least replacing (using explicit functions) bit
operators in Smarty would be a not so bad idea ... "designers" could mix
up & and && not seeing the difference

> (in relation to what as andrei suggested once for php:
> http://www.gravitonic.com/software/php/ (Concatenation and object
> operator change))
>
> the original proposal would use . for object dereference not for array
> dereference.
> do we plan to have more arrays or more objects inside template in the
> future?
> the . should be used for the more common case, obviously.
>
> the best solution may be to use . for array *and* for object
> dereference. but that would be impossible to determine at compile time
> and hard to do efficiently at runtime.

Smarty could use always objects, whether arrays or not

ArrayObject

one syntax for arrays and objects would make life much easier, as
someone already wrote, designer doesn't need to take care if this var is
an object or array - and i personally often switched from at start
introduced arrays later to objects ...

--
Sebastian Mendel

[Michael Hurni]

Why not use the dot as in php ?

In a simple case (eg. directly inside HTML tags) 

<h1>{$foo}{$bar}</h1>  is natural and sufficient, you don't need to concat with smarty

For every else..

- in a array key :

{$foo[ {$bar}.{$baz} ]}
{$foo[ "bar".{$baz} ]}

- or in a if comparaison    {if {$fname}.{$lname} == "jwill"}


in PHP  it will do

echo $foo[$bar.$baz];
echo $foo["bar".$baz];

if ($fname.$lname == "jwill")


And that run very well...

Michael

2008/10/24 Sebastian Mendel <li...@sebastianmendel.de>

[Sebastian Mendel]

On 2008-10-24 10:26, Michael Hurni wrote:
> Why not use the dot as in php ?

are you familiar with the current Smarty syntax?

dot is used for arrays in Smarty, and if i follow the whole discussion
right, most people are happy with this

$foo.bar -> $foo['bar']

--
Sebastian Mendel

[Michael Hurni]

The dot is outside the {var}.. so no conflict with the array access

{$foo[ {$bar}.{$baz} ]}    // is different from  {$foo[ {$bar.$baz} ]} 
{$foo[ {$baz}."baz" ]}    // is different from  {$foo[ {$baz.baz} ]}

{if {$fname}.{$lname} == "jwill"} //  is different from the {if {$array.key} == "jwill"}

And finnally.. I am familiar yes.. and I am happy to with the smarty array notation

Michael

2008/10/24 Sebastian Mendel <li...@sebastianmendel.de>

[Frank Schummertz]

Michael Hurni schrieb:

> The dot is outside the {var}.. so no conflict with the array access

Outside the var and outside of the scope of Smarty itself, thus inside
the template... this cannot work, how shall Smarty distinguish between
"I will use this dot for catenation" and "I will show a dot between two
vars" :-).

Frank

[Sebastian Mendel]

there is no need for an operator

<p>{$foo} {$bar}</p>

or what do you mean?

--
Sebastian Mendel

[Frank Schummertz]

Sebastian Mendel schrieb:

For a simple output, this is ok. Bet he cannot use this as a single var
like $foobar later on.

I suggest using

{capture assign="foobar"}{$foo}{$bar}{/capture}

if nothing else works.

Frank

[Sebastian Mendel]

On 2008-10-24 11:33, Michael Hurni wrote:
> The dot is outside the {var}.. so no conflict with the array access
>
> {$foo[ {$bar}.{$baz} ]} // is different from {$foo[ {$bar.$baz} ]}
> {$foo[ {$baz}."baz" ]} // is different from {$foo[ {$baz.baz} ]}
>
> {if {$fname}.{$lname} == "jwill"} // is different from the {if
> {$array.key} == "jwill"}

with extra {}, there would be no need for concatanation operator at all

{$var "baz"}
{$foo $bar}

would be the same like [], which do not interfere with {} as smarty tags

and i think [] would be a good choice,

{$foo[$bar "_a"]} -> $foo[$bar . '_a']
^ dot could be optional for arrays

{[$bar "_a"]} -> $bar . '_a'

{assign var="foo" value=[$foo "bar"]}

{assign var="foo" value=[$foo "bar"]}

{assign var="foo" value=$foo["bar"]}

{if [$foo "_a"] EQ 'bar'}

--
Sebastian Mendel

--
Sebastian Mendel

[Michael Hurni]

As I said..

ousite an if  (or a keyname construction) the dot is shown..

<p>{$fname}.{$lname}@{$domain}</p>

inside an if it is the concatenation

{if {$fname}.{$lname} ==..

if you really want to concat with a dot,

{if {$fname}.".".{$lname} == ..   // it's look's a littly uggly but it's the same in php..


finaly if you want a simple concat outside an if, so it as now in smarty2

<p>Hello {$fname} {$lname}</p>



The weakness is in the difference beetween

{if $foo ==

and

{if {$foo}.{$bar}

some time $foo should not be surrounded with {}  somme time it should

BUT.. i think that the concatenation are exceptional case and not use every day..

Michael

2008/10/24 Frank Schummertz <frank.sc...@landseer-stuttgart.de>

[patrick]

On Oct 24, 12:18 pm, Sebastian Mendel <li...@sebastianmendel.de>
wrote:

I think this one is nice...
But I don't understand why we don't use "&"? Because of bit
operations?? Hey, maybe the cat operator is used not very often, but I
think bit operations are very rarely used in templates. So I for one
would suggest to use "&" for cat, and implement a few functions for
bit operations.
If we really want to take care of bit operations inside templates,
then lets use the []-syntax suggested by Sebastian, but as I said: Bit
operations in template syntax is useless.

[Monte Ohrt]

The consensus seems to be: either use "&" for catenation (bit ops are
not useful in templates), or don't supply catenation in the template
syntax at all.

The other suggestions seem to either too close to existing syntaxes, or
just more complicated than it really needs to be. I'd rather not have a
catenation operator than require {} and [] groupings or spaces to make
it work. If we can't agree on a single-character operator, then let's
skip it.

[patrick]

Hm... Well, at first I thought there is no need for catenation al all,
but a few examples here changed my mind. Since there is no good reason
for not using "&" as the catter, we should use it.

[www.douglassdavis.com]

On Oct 21, 11:50 am, Monte Ohrt <mo...@ohrt.com> wrote:
> patrick wrote:
> > On Oct 21, 6:32 pm, Monte Ohrt <mo...@ohrt.com> wrote:
>
> >> It needs to tie into the loop name in a for loop, so it needs the var
> >> name. How about:
>
> >> {for $var in $myarray}
> >>   {$var:iteration}
> >> {/for}
>
> > Sorry, but I don't understand it... why do we need that $var? why
> > can't we just use $_iteration, $_last, and so on? You've provided a
> > solution for nested loops as well, I don't see any problems here.
>
> It is cleaner (and clearer) to tie the info to the loop. Especially in a
> nested loop, it makes accessing external vars straight forward. It is  
> also much easier on the tokenizer. If we just do {$_index} then there is
> nothing visually tying this to the loop, and we have to internally stack
> them. Instead of having to name the loop, we can just use the var name
> being used as the iterator.

I like this but since there was talk of getting rid of section, I
wonder if there will be a syntax to only do a certain number of
iterations, or iterate backwards...

[U.Tews]

For iterating a certain number the syntax is similar as in PHP.
{for $x=0;$x<10;$x++} .... {/for}

For iterating over an array
{for $var in $array} .... {/for}

On Nov 12, 4:46 pm, "www.douglassdavis.com"

[www.douglassdavis.com]

Thanks.

Just want to ask that since there is no "break" in smarty, if you only
want to iterate over only some of an associative array, would there be
a way to do that? Not sure how often that comes up, but just asking.

[ameggiolaro]

What about direct variable assignment? Something like this:

{ $foo="bar" }
{ $arr=[] }
{ $arr=[1, 2, 3] }
{ $arr=[one=1, two=2, tre=3, foo=$bar] }

Anderson

[U.Tews]

This is already implemented in the alpha code base.

{$foo="bar"}
{$arr=(1, 2, 3)}
$arr=(one=>1, two=>2, tre=>3, foo=>$bar)}

Uwe

[ameggiolaro]

Nice! And about the new php6 operator (?:) ?

Anderson.

[azrad]

ermm...

i like Smarty2 syntax for accessing special vars like $_GET, $_POST
using $smarty.get, $smarty.post.
It's a bit lengthy but quite understandable... or am i the only one
who thinks we should not change the way we accessing the special
vars... =)

oh well, atleast i still access the array indices using $foo.bar.bla
method...

On Oct 22, 9:48 pm, "U.Tews" <uwe.t...@googlemail.com> wrote:
> Last night the SVN has been updated.
>
> The new Smarty3 syntax for {for...} loops are implemented.
>
> There are two different styles.
> To loop over an array:
> {for $var in $myarray}   ....  {/for}
> $var:key            will deliver the key
> $var:iteration      will deliver the iteration
> $var:total           will deliver the total number of array entries
>
> For a counting for loop:
> {for $x=0, $y=count($foo); $x<$y; $i++}  ....  {/for}
> Any number of statements can be used separated by comma as the first
> inital expression at {for}
>
> The old Smarty2 {foreach} syntax is currently still in for BC.
> We still have to decide if we will keep the old {section} syntax for
> BC.
>
> Array indicies can be accessed currently in the old style like
> $foo.bar.bla or PHP like $foo['bar']['bla'].
>
> For catenation the use of & is implemented.  {$foo&$bar}
>
> We will use $_xxx syntax for smarty special vars. You can already
> access $_GET, $_POST, $_SESSION etc like this:  $_get.foo or
> $_get['foo'].
>
> Smarty3 has already some short commings of Smarty2 resolved. You can
> nest variables to use array elements of one variable as index for
> another:  $foo.{$bar.bla}
> or have variable variables: $foo_{$bar}.
> This will remove the requirements of temporary assignments of Smarty2

[Monte Ohrt]

I believe that will stay available for BC.