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