Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!

2014-05-29 Thread David Muir
I have considered looking at JS MVC setups, but have held off, partly because it's such a big break from what my team and I are used to, but also because I've seen others (notably Twitter) return to a more traditional, server-side html rendering approach after having gone the JS application route

Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!

2014-05-25 Thread Jeremiah Small
Maybe give mustache a try, instead of rolling your own. Jeremiah On May 24, 2014, at 10:31 PM, David Muir davidkm...@gmail.com wrote: Hey Marco, No, the placeholders are not part of user input. They’re hard-coded in, but because they’re inside attributes, they’re now getting escaped,

Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!

2014-05-25 Thread David Muir
Jeremiah, I don’t think mustache would help in this case. If we were using mustache, it would expect the template to look like this: input type=“text” name=“additional[{{rowId}}]” / but the template we get from Zend\Form would look like this: input type=“text”

Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!

2014-05-24 Thread David Muir
Hey Marco, No, the placeholders are not part of user input. They’re hard-coded in, but because they’re inside attributes, they’re now getting escaped, when before they weren’t. Eg. script id=“my-template” type=“text/html” ?php $field = clone $form-get(‘name’); $field-setAttribute(‘name’,

Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!

2014-05-23 Thread Marco Pivetta
Hey David, Template parameter placeholders shouldn't really be part of the user input, should they? I think you had a quite bad security issue upfront there ;-) If you really need unescaped strings, then you could eventually override the `escapeHtmlAttr` helper, but be rally careful

Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!

2014-05-21 Thread David Muir
The security fix broke our javascript templates that contained form elements. :-( All the curly braces in attributes are being converted to html entities, so our string replace calls aren't finding the braces anymore. Is there a way to easily get the old behaviour? Cheers, David On Wed, Apr