Re[3]: Incorrect newline counters

>
> Mark Rogers <[email protected]>  (More Solutions Ltd)
>
> Can we be more specific in these examples to avoid confusion? Eg, what
> should the following produce:
> xxx
>  {if $foo}
>    bar
>  {/if}
> yyy
> Note the leading whitespace on the {if} block.

So, example:

-------------
xxx
  {if $foo}
    bar
  {/if}
yyy
-------------

Original Smarty writes:

-------------
xxx
      bar
  yyy
-------------

My patch writes:

-------------
xxx
  
    bar
  
yyy
-------------

Suppose both are logically wrong, aren't?


> I'm not to be honest sure what Smarty currently does or which I
> think  it  should  do,  but  we  should  be able to create some
> documented  test  cases  from  which  to work, and define their
> required  behaviour, if these don't already exist? That way any
> proposed  patch  which breaks documented behavior can be easily
> picked up on.
Of  course.  But  first,  maybe,  we  need  to standartize Smarty
behavour? So, in the example -

-------------
xxx
  {if $foo}
    bar
  {/if}
yyy
-------------

output, apparently, must be:

-------------
xxx
    bar
yyy
-------------

So,  we  need  NOT ONLY to eat trailing newline, but also leading
spaces  (today's  Smarty  does  not  trim  leading spaces at all,
before all kind of tags).

So, the algorythm is the following.

First,  there are 2 kind of tags - "trimming" and "nontrimming".
Nontrimming  tags  are replaced by its output one-by-one (keeping
newlines). Trimming tags are more clever - they
a) ALWAYS remove trailing spaces (including newline);
b) remove LEADING  spaces,  but  IF and only if these tags are
   placed   in   the  line  ALONE.  For  example,  this  IF tag
   is left-trimming ("_" is "space":

___000
___{if ...}__
_____aaa
___{/if}
___111

   Result:

___000
_____aaa
___111

   And that IF - is not left-trimmed:

___000___{if ...}__
_____aaa
___{/if}
___111

   Result:

___000___
_____aaa
___111
   
I  am ready to carefully realize this functionality (keeping line
number  synchronization,  of  course),  but  first  I  need  your
sanction.

> [The  simplest  definition  of  what they should do would be to
> require  the  same behaviour as the current release, of-course,
> unless  there's  a  good  reason  to consider current behaviour
> "wrong".]



MO>> I'd say in theory, any function on a line **by itself** that does not
MO>> produce output directly should not create a line in the output. So, #2
MO>> would probably be the expected output. Similar example:
MO>> {if $foo}
MO>> bar
MO>> {/if}
MO>> should output:
MO>> bar\n
MO>> and not:
MO>> \nbar\n\n
DK> Stop. It is identical to PHP's behaviour:

DK> <?if (...) {?>
DK> bar
DK> <?}?>

DK> Result is "bar\n".

DK> But  you  had said before that newlines MUST not be ignored after
DK> {...} constructions!

DK> Can you explain this? Maybe newlines must be always deleted after
DK> block-tags, but not after function-tag?

DK> Can you explain the FULL behavour of different tags?



-- 
Best regards,
  Dmitry Koteroff.

-- 
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php