On Thu, Apr 12, 2012 at 6:35 PM, David Muir <davidkm...@gmail.com> wrote:

>  On 13/04/12 11:03, Kris Craig wrote:
>
>
>
> On Thu, Apr 12, 2012 at 5:46 PM, David Muir <davidkm...@gmail.com> wrote:
>
>>   On 13/04/12 10:04, Kris Craig wrote:
>>
>>
>>
>> On Thu, Apr 12, 2012 at 4:46 PM, David Muir <davidkm...@gmail.com> wrote:
>>
>>>  On 13/04/12 09:38, Yasuo Ohgaki wrote:
>>> > Hi,
>>> >
>>> > 2012/4/13 Kris Craig <kris.cr...@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
>>> > yohg...@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

Reply via email to