Re: Incorrect newline counters

If you are willing to put forth the effort to be sure all these changes 
are tested and accurate, I don't have a problem with them.

I can see where the leading whitespace removal could be useful, there 
are many instances where I butt the tags against the left margin to 
avoid the white space. But, this is a change in behavior. Question is, 
how will this affect current templates that may expect the leading white 
space?

It may require some folks to tweak their templates, but I think this 
change would be for the better. It seems to be a more intuitive and 
convienient behavior. (eg. keep the tag indenting, yet not introduce 
white space into the rendered template.)



Dmitry Koteroff wrote:

>>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?
>
>
>
>  
>

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