Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94353
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.220.181 cause and error)
MIME-Version: 1.0
References: <20160620222835.BC26C1A80609@dd1730.kasserver.com>
 <14352177-1b49-e2ed-56a3-9a770d0ebf95@gmail.com> <CAEDdnaU35=jGotCRVHx8=i7JnTg7yZOffr4dZtTDJ9vhqTNqtw@mail.gmail.com>
 <CAEDdnaUo=QwDejnJ64ziY2i-9KbMBgvN-_T7pzR8FfXBK3QHQA@mail.gmail.com>
 <CAEDdnaWUNpPxnwymdCj5hrOD=P01BmYO+xJD5JHTy98TRHaLuA@mail.gmail.com>
 <CAObuZduaythsvKtLj=vQtwZX9J_ZjQtywPES+K58-6YoK850zw@mail.gmail.com>
 <CAEDdnaX_hpKEv_ei-f7kWewyE3QB3d9Z=4qApqFhdBRSVFUtWw@mail.gmail.com>
 <7fb2d4d0-551e-97a0-72cd-1b6401881f97@fischer.name> <CAEDdnaUBv09R5MfD9X1LRhnmYz2qopdEWyrB3LfQncyrU3HtXw@mail.gmail.com>
 <CADqioP16NUbB91VE_8-_1NXi=1dCKvHDdjH3AkX0X_SaUxLYmg@mail.gmail.com>
In-Reply-To: <CADqioP16NUbB91VE_8-_1NXi=1dCKvHDdjH3AkX0X_SaUxLYmg@mail.gmail.com>
Date: Fri, 01 Jul 2016 11:46:41 +0000
Message-ID: <CANaX5ndp6cLELV7vdG7TKsCW2ar1dFghKHU-CZ=icpUB+Q2T5A@mail.gmail.com>
To: Eugene Leonovich <gen.work@gmail.com>, 
	=?UTF-8?B?0JzQuNGF0LDQuNC7INCS0L7RgdGC0YDQuNC60L7Qsg==?= <michael.vostrikov@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114aabcc2275570536918bf4
Subject: Re: [PHP-DEV] New escaped output operator
From: davey@php.net (Davey Shafik)

--001a114aabcc2275570536918bf4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

All,

Anybody can write an RFC and call a vote whenever they want within the
guidelines set forth for RFCs.

It would be much more productive to get the RFC written and to provide
suggestions on improvements (e.g. syntax choice, default options, ways to
customize), rather battling against it. Or stay quite and vote no. Or do
both.

I am personally against this idea as it stands but maybe there is a middle
ground and maybe some good can come of it. For example, autoloading
functions.

As a suggestion:

Perhaps the ability to register a default stream filter for the default
output buffer paired with file level declarations and/or context tagging
within blocks is a possible solution. So something like:

declare(strict_types=3D1; output_filter_args=3D['label' =3D> [ENT_QUOTES |
ENT_SUBSTITUTE]]);

// must be constant scalar expression?
// Would be passed in directly as is, the choice for an array with context
aware keys/values is up to you

register_output_filter(function($buffer, $label) { }, 'label'); // should
have similar API to spl autoloading, with multiple callback stack

<?label:=3D"string"; ?>

----

Something like this would start to solve some of the problems of context,
default arguments, etc.

I think functions to set the filter options might be better but using
declare makes it easier to limit to current file scope and ensures
consistent placement at top. Also I realize I said to use stream filters
and I've used a closure here. Stream filters are complex due to the whole
bucket brigade/continuous data stream thing, but have the advantage of
being much more performant and resource friendly. Maybe allow both types?
Simple callbacks for ease of use, stream filters for performance and
complex stuffs.

TL;DR: what's your account? Let's give RFC karma and vote it down if you
don't want it.


- Davey



On Fri, Jul 1, 2016 at 02:19 Eugene Leonovich <gen.work@gmail.com> wrote:

> On Fri, Jul 1, 2016 at 10:51 AM, =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB =D0=
=92=D0=BE=D1=81=D1=82=D1=80=D0=B8=D0=BA=D0=BE=D0=B2 <
> michael.vostrikov@gmail.com> wrote:
>
> > > I can easier add a new template to e.g. a Laravel
> > > project (own parser, own extension, living next to existing blade
> > templates)
> >
> > Your project already has a template engine, and framework has common co=
de
> > which works with such engines.
> > But how much time do you need to convert all existing templates to a ne=
w
> > TE?
> >
> > I mean the projects without template engine, which work and are develop=
ed
> > every day.
> > Their number is rather large - various CMSs, projects with custom core,
> Yii
> > and Zend don't have TE by default.
> > In a big project there are a lot of PHP templates with <?=3D
> htmlspecialchars
> > ?> or <?=3D h() ?> or <?=3D (int)$some_id ?> everywhere.
> > If we miss this somewhere, we could got an XSS.
> >
> >
> > 2016-07-01 12:53 GMT+05:00 Markus Fischer <markus@fischer.name>:
> >
> > > On 01.07.16 05:34, =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB =D0=92=D0=BE=
=D1=81=D1=82=D1=80=D0=B8=D0=BA=D0=BE=D0=B2 wrote:
> > > > Because it is almost impossible to add template engine in a big
> project
> > > > with PHP templates. But new version of language usually can easily =
be
> > > used.
> > >
> > > I interpret "But new version of language usually can easily be used" =
as
> > > in a new PHP version being installed on a server touted as being
> > > "easier" than changing/replaced/adding a new template language
> component
> > > with a framework?
> > >
> > > I object to this. I can easier add a new template to e.g. a Laravel
> > > project (own parser, own extension, living next to existing blade
> > > templates) then switching to a new PHP version on production servers.
> > >
> > > - Markus
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
>
> > In a big project there are a lot of PHP templates with <?=3D
> htmlspecialchars
> ?> or <?=3D h() ?> or <?=3D (int)$some_id ?> everywhere.
>
> How will a new output operator help in this case? You still have to searc=
h
> for `<?=3D`, `<? echo`, `<? print` occurrences and replace them with `<?~=
`.
> Saying that one can forget to add `<?=3D h()` can be applied to `<?~` as
> well, you can miss `<? echo` somewhere in a template and get the same
> result at the end.
>
> --
> Thank you and best regards,
> Eugene Leonovich
>

--001a114aabcc2275570536918bf4--