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

Andreas Korthaus <[email protected]> Wed, 17 May 2006 21:21:58 +0200
Newsgroups gmane.comp.php.smarty.devel
Message-ID <[email protected]>
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