[RFC] New .phpp File Type for Pure-Code PHP Scripts

> 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 php > 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. > > 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.

> 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 php > 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. > > 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. >

> 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. >

> 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 >