Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59847
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.216.49 as permitted sender)
References: <CAKOpQSwYe+tZ3JfLFWaOHCnBpUyy9yoA61=qLzbnnOKTL0mQdQ@mail.gmail.com> <CAGa2bXa554p45tbNFvtHQJiYTXaa0eD6r+qnExDVk+6e8PRvMw@mail.gmail.com> <4F876943.8030105@gmail.com> <CAKOpQSzAZauE9HYK3x-5UbxAstkdkc-HkfZRa+E+i=DNxQwkBA@mail.gmail.com> <4F877777.8050806@gmail.com> <CAKOpQSyC6Zs=3-AQ8=L-aufTP03j0yhnRiu3n6pNP7YSpW_KLg@mail.gmail.com> <CAL0xaBEpPuAeLKJTR9XVOO+3GVm4m4L6ELhQ+Vc-3xtdr+YM5Q@mail.gmail.com> <CAGa2bXYC1+b_sX-b05-8MHvQ1DCk4aQgNcx4UAdYisCbGsCBag@mail.gmail.com>
In-Reply-To: <CAGa2bXYC1+b_sX-b05-8MHvQ1DCk4aQgNcx4UAdYisCbGsCBag@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8
Message-ID: <728BB582-9C33-4343-BF8A-A929FF716CD5@punkave.com>
Cc: Arvids Godjuks <arvids.godjuks@gmail.com>,
 Kris Craig <kris.craig@gmail.com>,
 PHP internals list <internals@lists.php.net>,
 David Muir <davidkmuir@gmail.com>
Date: Thu, 12 Apr 2012 22:38:27 -0400
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
From: tom@punkave.com (Tom Boutell)

The meaning is unclear, and it doesn't let you specify error reporting.

Sent from my iPhone

On Apr 12, 2012, at 9:37 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> 2012/4/13 Arvids Godjuks <arvids.godjuks@gmail.com>:
>> Well, i can say that any template engine that is not a pure php extension=

>> does template inclusion via an include of a file with html and embedded p=
hp
>> code. Because to make things fast you have to convert your templates from=

>> tags and pseudo code to that state and cache the result so not to make
>> parsing on every request.
>>=20
>> And right now there is a standard for autoloading the libraries and
>> frameworks that most big players agreed on, that will make loading of 3rd=

>> party stuff easy. Untill one converts to pphp and other does not.
>> Autoloadijg will just break because of mixed approaches.
>=20
> Good point.
>=20
> Although there may be name conflicts, script/script_once would
> be better and has more compatibility. Let just make types of
> include decided how it behave.
>=20
> Regards,
>=20
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>=20
>>=20
>> Hm, you wrote that you have configured php only with IIS and Apache (any
>> *nix expirience?). Try nginx, see for yourself how different it is.
>>=20
>> 13.04.2012 3:05 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=
=B5=D0=BB=D1=8C "Kris Craig" <kris.craig@gmail.com> =D0=BD=D0=B0=D0=BF=D0=B8=
=D1=81=D0=B0=D0=BB:
>>=20
>>> On Thu, Apr 12, 2012 at 5:46 PM, David Muir <davidkmuir@gmail.com> wrote=
:
>>>=20
>>>>  On 13/04/12 10:04, Kris Craig wrote:
>>>>=20
>>>>=20
>>>>=20
>>>> On Thu, Apr 12, 2012 at 4:46 PM, David Muir <davidkmuir@gmail.com>
>>>> wrote:
>>>>=20
>>>>>  On 13/04/12 09:38, Yasuo Ohgaki wrote:
>>>>>> Hi,
>>>>>>=20
>>>>>> 2012/4/13 Kris Craig <kris.craig@gmail.com>:
>>>>>>> Per recent discussions, I have drafted an RFC for this.  This
>>>>>>> proposal
>>>>>>> offers what I believe to be a more sane and realistic approach to
>>>>>>> addressing the question of incorporating a new breed of tag-less PHP=

>>>>>>> scripts.
>>>>>>>=20
>>>>>>> https://wiki.php.net/rfc/phpp
>>>>>> This may work for LFI issue for new codes.
>>>>>> Few questions.
>>>>>>=20
>>>>>> CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or
>>>>>> else)
>>>>>> It's like DOS, though.
>>>>>>=20
>>>>>> How do you enforce .phpp as script only for Web?
>>>>>> Is it a rule for configuration? or .phpp just never supposed to
>>>>>> locate
>>>>>> under docroot?
>>>>>> It relates previous question. How about bootstrap script for
>>>>>> frameworks?
>>>>>>=20
>>>>>>> A regular .php script cannot be included from a .phpp script. An
>>>>> E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will b=
e
>>>>> thrown for require; in both instances, the included file will be
>>>>> ignored.
>>>>>> Some people may try to make .phpp handled by web.
>>>>>> I cannot tell if this setting is going to be popular, but if it
>>>>>> does, isn't it the end of embedded PHP?
>>>>>> It might be good if PHP is more tolerant for this usage.
>>>>>>=20
>>>>>> Regards,
>>>>>>=20
>>>>>> --
>>>>>> Yasuo Ohgaki
>>>>>> yohgaki@ohgaki.net
>>>>>>=20
>>>>>=20
>>>>>  That's a huge WTF that a templating library can't be written as .phpp=
,
>>>>> because it then won't be able to load a template.
>>>>>=20
>>>>=20
>>>> That's actually not true.  Please refer to the diagram embedded in the
>>>> RFC.
>>>>=20
>>>> Basically, you can load a template just fine-- you just can't do it
>>>> directly from a .phpp file, which you shouldn't be doing, anyway.  The
>>>> .phpp file is, at least for the most part, intended to be included from=

>>>> a
>>>> regular .php file, which also would include whatever you're using for
>>>> your
>>>> templates.  In other words, they can interact just fine; you just can't=

>>>> put
>>>> the template upstream from a .phpp file in the include stack-- which,
>>>> again, you really shouldn't be doing, anyway, as it's just bad
>>>> architecture.
>>>>=20
>>>>=20
>>>>=20
>>>> How is this bad architecture? Every framework I've seen that has some
>>>> kind
>>>> of templating layer that handles the scope and inclusion of the
>>>> template,
>>>> and it happens further down the chain from the controlling code.
>>>>=20
>>>> Zend_View, Twig or Smarty would have to remain as .php and not .phpp,
>>>> otherwise they wouldn't be able to render the templates.
>>>>=20
>>>> In the case of Zend Framwork, which I'm most familiar with, the
>>>> application, front controller, dispatcher, and action controllers, and
>>>> some
>>>> services would have to remain as .php so that templates could be
>>>> executed.
>>>>=20
>>>> Oh, and the autoloader can't be .phpp either. But then if it's .php,
>>>> then
>>>> the autoloader can't be called from .phpp files to include .php files.
>>>>=20
>>>> Cheers,
>>>> David
>>>>=20
>>>=20
>>> It's been awhile since I've used Smarty, but unless my memory is failing=

>>> me, I'm pretty sure it's not restricted to being several points removed
>>> upstream as you described.  I'm not familiar with Zend_View or Twig so I=

>>> can't comment on those.
>>>=20
>>> Thing is, there's no reason why you can't hook any framework into this.
>>> Worst-case scenario, if the library you're hooking into has a rigid
>>> structure, just write a simple controller class layer to operate on top o=
f
>>> it, then use that same controller class to interface with the .phpp stac=
k.
>>> Problem solved.  It's really not as complicated or confusing as you're
>>> making it out to be.
>>>=20
>>> --Kris
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20