Zend\Escaper Integration Tasks: Volunteers Will Not Be Shot (Everyone Else - Run)

[Pádraic Brady]

Hi all,

On the run up to the next beta, there are a couple of tasks remaining
to integrate Zend\Escaper into Zend\View and Zend\Form.
I would greatly appreciate if someone could volunteer some time this
afternoon/evening to tackle Zend\Form (find me on IRC) so we can
update its helpers in a separate PR.

For Zend\View, here's a short list of the most likely changes:

1. The current Escape helper will be retired subject to any last
minute intervention as to how it could safely remain.
2. Escaping in templates will now use Helpers providing the
escapeHtml(), escapeHtmlAttr(), escapeJs(), escapeCss() and
escapeUri() functions. The current escape() function is replaced by
escapeHtml(). This is a break with backwards compatibility from prior
betas.
3. The second parameter for the current Escape helper will need to be
readdressed - anyone familiar with it should find me in IRC to
discuss.

When the PR lands for the Zend\View changes later, your review would
be appreciated.

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team

[Pádraic Brady]

Just a quick note that the PR for Zend\Escaper integrated with
Zend\View is now available:
https://github.com/zendframework/zf2/pull/1750

Please review if you have some time (and are not staring at fireworks
and parades :P).

Paddy

On Wed, Jul 4, 2012 at 6:25 PM, Pádraic Brady <[hidden email]> wrote:

> Hi all,
>
> On the run up to the next beta, there are a couple of tasks remaining
> to integrate Zend\Escaper into Zend\View and Zend\Form.
> I would greatly appreciate if someone could volunteer some time this
> afternoon/evening to tackle Zend\Form (find me on IRC) so we can
> update its helpers in a separate PR.
>
> For Zend\View, here's a short list of the most likely changes:
>
> 1. The current Escape helper will be retired subject to any last
> minute intervention as to how it could safely remain.
> 2. Escaping in templates will now use Helpers providing the
> escapeHtml(), escapeHtmlAttr(), escapeJs(), escapeCss() and
> escapeUri() functions. The current escape() function is replaced by
> escapeHtml(). This is a break with backwards compatibility from prior
> betas.
> 3. The second parameter for the current Escape helper will need to be
> readdressed - anyone familiar with it should find me in IRC to
> discuss.
>
> When the PR lands for the Zend\View changes later, your review would
> be appreciated.
>
> Paddy
>
> --
> Pádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> Zend Framework Community Review Team

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team

[David Muir-2]

On 05/07/12 03:25, Pádraic Brady wrote:

> Hi all,
>
> On the run up to the next beta, there are a couple of tasks remaining
> to integrate Zend\Escaper into Zend\View and Zend\Form.
> I would greatly appreciate if someone could volunteer some time this
> afternoon/evening to tackle Zend\Form (find me on IRC) so we can
> update its helpers in a separate PR.
>
> For Zend\View, here's a short list of the most likely changes:
>
> 1. The current Escape helper will be retired subject to any last
> minute intervention as to how it could safely remain.
> 2. Escaping in templates will now use Helpers providing the
> escapeHtml(), escapeHtmlAttr(), escapeJs(), escapeCss() and
> escapeUri() functions. The current escape() function is replaced by
> escapeHtml(). This is a break with backwards compatibility from prior
> betas.
> 3. The second parameter for the current Escape helper will need to be
> readdressed - anyone familiar with it should find me in IRC to
> discuss.
>
> When the PR lands for the Zend\View changes later, your review would
> be appreciated.
>
> Paddy
>

Although I agree in concept (explicit naming), that's an awful amount to
type each time you need to escape something...

David

[EvanDotPro]

Hi David,

On Wed, Jul 4, 2012 at 4:25 PM, David Muir <[hidden email]> wrote:
>
> Although I agree in concept (explicit naming), that's an awful amount to
> type each time you need to escape something...

We have a nifty feature called aliases:

./config/autoload/helper-aliases.global.php

<?php
return array(
    'view_helpers' => array(
        'aliases' => array(
            'eH' => 'escapeHtml',
            'eA' => 'escapeHtmlAttr',
            'eJ' => 'escapeJs',
            'eC' => 'escapeCss',
            'eU' => 'escapeUri',
        ),
    ),
);

Note that I do not condone such terrible helper naming, and would
suggest you stick with the default, explicit names. Future developers
working with your code (yourself included) will curse your name for
not using explicit naming. I speak from experience.

--
Evan Coury

[Adam Lundrigan]

Working on updating the Zend\Form helpers now

--
Adam Lundrigan, B.Sc, ZCE
[hidden email]

On Wed, Jul 4, 2012 at 10:09 PM, Evan Coury <[hidden email]> wrote:

Hi David,

On Wed, Jul 4, 2012 at 4:25 PM, David Muir <[hidden email]> wrote:
>
> Although I agree in concept (explicit naming), that's an awful amount to
> type each time you need to escape something...

We have a nifty feature called aliases:

./config/autoload/helper-aliases.global.php

<?php
return array(
    'view_helpers' => array(
        'aliases' => array(
            'eH' => 'escapeHtml',
            'eA' => 'escapeHtmlAttr',
            'eJ' => 'escapeJs',
            'eC' => 'escapeCss',
            'eU' => 'escapeUri',
        ),
    ),
);

Note that I do not condone such terrible helper naming, and would
suggest you stick with the default, explicit names. Future developers
working with your code (yourself included) will curse your name for
not using explicit naming. I speak from experience.

--
Evan Coury

[David Muir-2]

On 05/07/12 10:39, Evan Coury wrote:

> Hi David,
>
> On Wed, Jul 4, 2012 at 4:25 PM, David Muir <[hidden email]> wrote:
>> Although I agree in concept (explicit naming), that's an awful amount to
>> type each time you need to escape something...
> We have a nifty feature called aliases:
>
> ./config/autoload/helper-aliases.global.php
>
> <?php
> return array(
>      'view_helpers' => array(
>          'aliases' => array(
>              'eH' => 'escapeHtml',
>              'eA' => 'escapeHtmlAttr',
>              'eJ' => 'escapeJs',
>              'eC' => 'escapeCss',
>              'eU' => 'escapeUri',
>          ),
>      ),
> );
>
> Note that I do not condone such terrible helper naming, and would
> suggest you stick with the default, explicit names. Future developers
> working with your code (yourself included) will curse your name for
> not using explicit naming. I speak from experience.
>
> --
> Evan Coury

Oooh, didn't think of aliases via config. Wouldn't have gone quite to
that extreme though. More like esc for escapeHtml and escAttr for
escapeHtmlAttr, and leave the rest as is.

Probably right about sticking to defaults though. I've cursed myself too
for writing my own quick'n'dirty escaping functions where the site
wasn't using Zend_View, and then got all confused why $this->escape()
wasn't working and later why $esc() wasn't working in when I was back in
Zend_View.

Cheers,
David

[jeremiah]

IDEs are handy for this sort of thing, and let you keep the full explicit names for future generations ;-)

A couple of us have an alias of zdb that expands to \Zend\Debug::dump();die; and puts the cursor in between the parens.

Jeremiah

On Jul 4, 2012, at 6:11 PM, David Muir-2 [via Zend Framework Community] wrote:

On 05/07/12 10:39, Evan Coury wrote:

> Hi David,
>
> On Wed, Jul 4, 2012 at 4:25 PM, David Muir <<a href="x-msg://62/user/SendEmail.jtp?type=node&amp;node=4655614&amp;i=0" target="_top" rel="nofollow" link="external">[hidden email]> wrote:
>> Although I agree in concept (explicit naming), that's an awful amount to
>> type each time you need to escape something...
> We have a nifty feature called aliases:
>
> ./config/autoload/helper-aliases.global.php
>
> <?php
> return array(
>      'view_helpers' => array(
>          'aliases' => array(
>              'eH' => 'escapeHtml',
>              'eA' => 'escapeHtmlAttr',
>              'eJ' => 'escapeJs',
>              'eC' => 'escapeCss',
>              'eU' => 'escapeUri',
>          ),
>      ),
> );
>
> Note that I do not condone such terrible helper naming, and would
> suggest you stick with the default, explicit names. Future developers
> working with your code (yourself included) will curse your name for
> not using explicit naming. I speak from experience.
>
> --
> Evan Coury

Oooh, didn't think of aliases via config. Wouldn't have gone quite to
that extreme though. More like esc for escapeHtml and escAttr for
escapeHtmlAttr, and leave the rest as is.

Probably right about sticking to defaults though. I've cursed myself too
for writing my own quick'n'dirty escaping functions where the site
wasn't using Zend_View, and then got all confused why $this->escape()
wasn't working and later why $esc() wasn't working in when I was back in
Zend_View.

Cheers,
David

---

If you reply to this email, your message will be added to the discussion below:

http://zend-framework-community.634137.n4.nabble.com/Zend-Escaper-Integration-Tasks-Volunteers-Will-Not-Be-Shot-Everyone-Else-Run-tp4655605p4655614.html

To start a new topic under ZF Contributor, email [hidden email]
To unsubscribe from ZF Contributor, click here.
NAML

[Pádraic Brady]

I fully accept the criticism for removing escape(), however, after researching frameworks/apps/libs I quickly noticed that many programmers fall into a trap of using a default escape (always implementing HTML escaping by default) without thought for HTML context. Removing the existence of a default escaper forces an explicit choice, highlights the presence of context specific escapers, and hopefully makes folk think more.

So swapping one invisible evil for a more visible one - though opening us up to slightly more complaints.

Hey, at least it's not escapeHyperTextMarkupLanguage()! You have to concede that! :p

Paddy

On 5 Jul 2012, at 02:11, David Muir <[hidden email]> wrote:

> On 05/07/12 10:39, Evan Coury wrote:
>> Hi David,
>>
>> On Wed, Jul 4, 2012 at 4:25 PM, David Muir <[hidden email]> wrote:
>>> Although I agree in concept (explicit naming), that's an awful amount to
>>> type each time you need to escape something...
>> We have a nifty feature called aliases:
>>
>> ./config/autoload/helper-aliases.global.php
>>
>> <?php
>> return array(
>>     'view_helpers' => array(
>>         'aliases' => array(
>>             'eH' => 'escapeHtml',
>>             'eA' => 'escapeHtmlAttr',
>>             'eJ' => 'escapeJs',
>>             'eC' => 'escapeCss',
>>             'eU' => 'escapeUri',
>>         ),
>>     ),
>> );
>>
>> Note that I do not condone such terrible helper naming, and would
>> suggest you stick with the default, explicit names. Future developers
>> working with your code (yourself included) will curse your name for
>> not using explicit naming. I speak from experience.
>>
>> --
>> Evan Coury
>
> Oooh, didn't think of aliases via config. Wouldn't have gone quite to that extreme though. More like esc for escapeHtml and escAttr for escapeHtmlAttr, and leave the rest as is.
>
> Probably right about sticking to defaults though. I've cursed myself too for writing my own quick'n'dirty escaping functions where the site wasn't using Zend_View, and then got all confused why $this->escape() wasn't working and later why $esc() wasn't working in when I was back in Zend_View.
>
> Cheers,
> David

[Artur Bodera]

On Thu, Jul 5, 2012 at 9:45 AM, Pádraic Brady <[hidden email]> wrote:

I fully accept the criticism for removing escape(), however, after researching frameworks/apps/libs I quickly noticed that many programmers fall into a trap of using a default escape (always implementing HTML escaping by default) without thought for HTML context. Removing the existence of a default escaper forces an explicit choice, highlights the presence of context specific escapers, and hopefully makes folk think more.

Just because Padraic loves when I preach the choir:

That's exactly the reason why in zf2 we've dumped:

    $request->getParam() 

... in favor of:

    $request->getPost()  

              ->getQuery()

              ->getEnv()

etc.

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]