On Thu, Apr 12, 2012 at 9:00 PM, Kris Craig <kris.cr...@gmail.com> wrote:
> > > On Thu, Apr 12, 2012 at 7:51 PM, John LeSueur <john.lesu...@gmail.com>wrote: > >> >> >> On Thu, Apr 12, 2012 at 7:49 PM, Kris Craig <kris.cr...@gmail.com> wrote: >> >>> 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 >>> >> I missed replying to the list here, sorry! > John LeSueur wrote: >> I'm -1 on this, since the main benefit of .phpp is for class/library >> files. This handles models just fine, but controllers who include .php >> files for templating won't be able to take advantage. Also, any templating >> library will have to be written with .php. Smarty, Twig, etc. use class >> files just as much as any model or controller, and have just as much reason >> to use .phpp. >> > Kris Craig Wrote: > As I said, this is simply not true. Controllers that include .php files > for templating would still be able to include .phpp files and thus take > full advantage. Again, I would strongly encourage you to review the > diagram posted on the RFC. > But controllers can't be in a .phpp file, even when they are pure php. Take the following: //a controller, maybe a class, maybe just a set of functions, but in a .phpp file function getLoginPage() { //set up some data //some people like to use plain .php for templates include 'templates/loginPage.php'; //other people like to use a View library $view->render('loginPage.tpl'); } In the case of using a view object, your controller can be a .phpp file. In the case of the include, it cannot. Now consider the case of the implementation of the render() method: function render($template) { $compiledTemplate = $this->compile($template); include $compiledTemplate; } Now your render method cannot be in a .phpp file. > > >> What exactly is the benefit of this kind of segregation? why would a >> .phpp file care that no other files included after it are .php? >> > > Simple: It's a lot easier to hire a designer and a programmer than it is > to hire two people who are each fluent in both design and programming. In > other words, on complex projects with intense graphical and functionality > requirements, being able to separate the development process into design > and scripting components, without merge conflicts between the two, is far > more efficient and economical. That's why familiarity with the MVC > standard is listed as a requirement on many (if not most) developer job > postings nowadays. > > > If you have .phpp files, the designer immediately knows to steer clear. > Likewise, it means that the PHP developer can build the model with > impunity because he knows it won't collide with the work that the designer > is doing on the templating layer. The controller is the point where the > two meet, and that would be a .php file which includes both .php and .phpp > files, thus allowing full cooperation and interaction between the two while > simultaneously segregating their roles. > Yes, the segregation provided by MVC is great. I'm not questioning that. I'm asking about the segregation of include trees of .phpp(code) files from include trees of .php(template) files. They're already going to be separated in the filesystem(in any sane application), so designers won't be looking at .phpp files(and in some cases, may not have access to that portion of the code tree). I just don't agree that the engine also needs to create segregated include trees in order to facilitate MVC. There's a lot of ways to do the V in MVC, and a lot of ways to connect the C to it. It seems like this RFC puts restrictions on those in an unnecessary way. I'm not sure we're going to agree on this point(as you said somewhere else, smart people disagree all the time), but I wanted to make my objections clear. John
