Re: [patch] add $smarty->escape_output feature

I'm for a clean implementation, and maybe even  deprecate the 
default_modifier feature. The  only useful purpose for them was for  
html-escapement anyways, and it doesn't work 100%.

Andreas Korthaus wrote:
> Hi Monte!
>
> Monte Ohrt wrote:
>> ? I'm not against the feature at all, as a matter of fact it has been 
>> discussed many times before. I was only making an observation: only 
>> escaped echo'ed content, don't escape content within logical 
>> statements. It looks like it already works that way... I have not 
>> looked at the patch, nor have time in the near future. Maybe boots or 
>> messju can help out with a cvs commit in the meantime.
>
> I think you don't need to look at the patch, but perhaps you can help 
> us a little bit to come to a decisions, so my effort can result in 
> something useful anytime soon ;-)
>
> At the moment messju and boots have different opinions about how to 
> implement such an output-encoding feature, so now we've had 10 days 
> silence again in the thread which started so hopefully:
>
> http://www.phpinsider.com/smarty-forum/viewtopic.php?t=7806
>
> The question is, whether the output-encoding feature should be 
> implemented based on $default_modifiers, or should it be a new 
> feature, cleanly implemented from scratch?
>
> We all think, the current $default_modifiers code is pretty 
> useless/buggy. So if we want to use $default_modifiers, we have to 
> change its implementation, which will break its BC completely. But 
> messju does not want to "bloat" the Smarty.class.php anymore. If we 
> add a new variable for output-encoding, we have to add 2 lines of code 
> to the Smarty class, e.g.:
>
> 1. variable definition:
> var $output_escape_func;
>
> 2. pass variable to compiler:
> $smarty_compiler->output_escape_func = $this->output_escape_func;
>
>
> Ok, here the two options - "from scatch" vs. "change/reuse 
> $default_modifiers"
>
> If we implement the feature from scratch (that's what my patch does), 
> we get the following advantages:
>
> 1. clear, simple API for new, useful feature
> 2. don't break $default_modifiers BC
> 3. faster at runtime (can hardcode php-core functions in compiled tpl.)
>
> If we change and reuse $default_modifiers:
>
> 1. safe 2 lines of code in Smarty class
>
>
> I'm in the same line with boots for cleanly implementing it from 
> scratch, messju prefers to reuse/change $default_modifiers.
>
> What do you think about it? Would be very nice if you could help us to 
> come to a conclusion here, so we can start working on it soon (boots 
> already offered to work on it and get it commited)!
>
> You can find some more information/arguments/examples in the forums 
> thread: http://www.phpinsider.com/smarty-forum/viewtopic.php?t=7806
>
>
> Best regards
> Andreas


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