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

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 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. > > Good point. > > 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. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > >> >> 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. >> >> 13.04.2012 3:05 пользователь "Kris Craig" >> <kris.craig@gmail.com> написал: >> >>> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >