Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59842
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F8782CC.8030205@gmail.com>
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>
	<4F8782CC.8030205@gmail.com>
Date: Thu, 12 Apr 2012 18:49:08 -0700
Message-ID: <CAKOpQSzKo9ZX1voYppTRihkfkpfCywMLLv_DF8XWGxcOV1Su8Q@mail.gmail.com>
To: David Muir <davidkmuir@gmail.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04447f47a703db04bd85ad5f
Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
From: kris.craig@gmail.com (Kris Craig)

--f46d04447f47a703db04bd85ad5f
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Apr 12, 2012 at 6:35 PM, David Muir <davidkmuir@gmail.com> wrote:

>  On 13/04/12 11:03, Kris Craig wrote:
>
>
>
> On Thu, Apr 12, 2012 at 5:46 PM, David Muir <davidkmuir@gmail.com> wrote:
>
>>   On 13/04/12 10:04, Kris Craig wrote:
>>
>>
>>
>> On Thu, Apr 12, 2012 at 4:46 PM, David Muir <davidkmuir@gmail.com> wrote:
>>
>>>  On 13/04/12 09:38, Yasuo Ohgaki wrote:
>>> > Hi,
>>> >
>>> > 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.
>>> >>
>>> >> https://wiki.php.net/rfc/phpp
>>> > This may work for LFI issue for new codes.
>>> > Few questions.
>>> >
>>> > CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or
>>> else)
>>> > It's like DOS, though.
>>> >
>>> > 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?
>>> >
>>> >> 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 be
>>> 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.
>>> >
>>> > Regards,
>>> >
>>> > --
>>> > Yasuo Ohgaki
>>> > yohgaki@ohgaki.net
>>> >
>>>
>>>  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.
>>>
>>
>> That's actually not true.  Please refer to the diagram embedded in the
>> RFC.
>>
>> 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.
>>
>>
>>
>>  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.
>>
>> Zend_View, Twig or Smarty would have to remain as .php and not .phpp,
>> otherwise they wouldn't be able to render the templates.
>>
>> 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.
>>
>> 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.
>>
>> Cheers,
>> David
>>
>
> 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.
>
> 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 of
> it, then use that same controller class to interface with the .phpp stack.
> Problem solved.  It's really not as complicated or confusing as you're
> making it out to be.
>
> --Kris
>
>
> Both Smarty and Twig compile your template files down to php templates.
> Zend_View, Aura.View, and Symfony's php view include php files directly
> without a compilation phase.
>
> I don't get how I would write a "simple controller class layer to operate
> on top of it".
>
> Does the inclusion limitation apply to just the script in question, or the
> entire call stack?
>
> A simplified example:
> index.php -> FrontController.phpp -> Controller.phpp -> View.phpp -> can't
> include template.phtml
>
> index.php -> FrontController.phpp -> Controller.phpp -> View.php -> can
> include template.phtml ?
> But I can't do require_once('View.php') in the controller.
>
> If there's an autoloader involved, it would have to be set up in
> index.php, and would also have to be .php so that it can include both file
> types.
>
> index.php -> FrontController.phpp -> Controller.phpp -> Autoloader.php ->
> can include View.php ?
>
> But will that work since there are .phpp files above it in the call stack?
>
> Cheers,
> David
>

I'm sorry, I was vague on this point in my previous response.  The
controller script would be standard .php, not .phpp.  And rather than a
one-dimensional linear progression, there would be parallel stacks, one
.php and the other .phpp, both coming together in the controller (which is
.php).

If I get some time this weekend I'll try to throw together a working
example.  Perhaps that'll help clarify my thinking on this.  =)

--Kris

--f46d04447f47a703db04bd85ad5f--