Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59837 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 58218 invoked from network); 13 Apr 2012 01:35:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Apr 2012 01:35:16 -0000 Authentication-Results: pb1.pair.com smtp.mail=davidkmuir@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=davidkmuir@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender) X-PHP-List-Original-Sender: davidkmuir@gmail.com X-Host-Fingerprint: 209.85.214.170 mail-ob0-f170.google.com Received: from [209.85.214.170] ([209.85.214.170:41665] helo=mail-ob0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CA/21-00290-3D2878F4 for ; Thu, 12 Apr 2012 21:35:15 -0400 Received: by obbta17 with SMTP id ta17so2742359obb.29 for ; Thu, 12 Apr 2012 18:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=2Qwn7vJQLn2Wnl1LbvSaORQ/6f7cpfqrvTAzCfy5bZc=; b=icdO8vZBzOsXe73jVuKZHOlYQhohAq2WVJZQEM5MiMDa4FNWrr/+Rc2p5mmko4yOP0 c3OH6Pmndq78aqlModxh183luE/eb+mAiB4i4wnqaE6g1CLrSZ8Eij+RLFMy5qqdFjuB R62kdw2DTHKcLgvYSZw4e7XmXKi7Gbzxy+7Rs8zIP8yfv4b4IXmcfK3l3IKMQ8/LyeEH PMHBYOfe5Dn8JR18jGwriPZYNnhHqrDUOV1a5ItRidIKKJdxGHsLNrRuQU8Mr1xyyv98 QTU+ykaUAvk0ImQEZSj75P4+zvQiL/Els05amdPxDMMIynjxHUF8upzH9uWlYEnSb1Sn /Z/Q== Received: by 10.182.202.69 with SMTP id kg5mr398886obc.35.1334280912717; Thu, 12 Apr 2012 18:35:12 -0700 (PDT) Received: from [192.168.0.5] (dsl-202-173-152-56.vic.westnet.com.au. [202.173.152.56]) by mx.google.com with ESMTPS id d6sm7202709oeh.3.2012.04.12.18.35.10 (version=SSLv3 cipher=OTHER); Thu, 12 Apr 2012 18:35:12 -0700 (PDT) Message-ID: <4F8782CC.8030205@gmail.com> Date: Fri, 13 Apr 2012 11:35:08 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Kris Craig CC: Yasuo Ohgaki , PHP internals list References: <4F876943.8030105@gmail.com> <4F877777.8050806@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040206090700050304060404" Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts From: davidkmuir@gmail.com (David Muir) --------------040206090700050304060404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 13/04/12 11:03, Kris Craig wrote: > > > On Thu, Apr 12, 2012 at 5:46 PM, David Muir > wrote: > > On 13/04/12 10:04, Kris Craig wrote: >> >> >> On Thu, Apr 12, 2012 at 4:46 PM, David Muir > > wrote: >> >> On 13/04/12 09:38, Yasuo Ohgaki wrote: >> > Hi, >> > >> > 2012/4/13 Kris Craig > >: >> >> 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 >> > > 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 --------------040206090700050304060404--