Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59823 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36293 invoked from network); 13 Apr 2012 00:46:56 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Apr 2012 00:46:56 -0000 Authentication-Results: pb1.pair.com header.from=davidkmuir@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=davidkmuir@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender) X-PHP-List-Original-Sender: davidkmuir@gmail.com X-Host-Fingerprint: 209.85.210.170 mail-iy0-f170.google.com Received: from [209.85.210.170] ([209.85.210.170:62829] helo=mail-iy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2D/4C-00290-E77778F4 for ; Thu, 12 Apr 2012 20:46:55 -0400 Received: by iaeh11 with SMTP id h11so4200826iae.29 for ; Thu, 12 Apr 2012 17:46:52 -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=4SRgnOPbzZNGnbH761U4h7jTmzk3VPxLJga9m5FlY4w=; b=BctTUs/6ZaR9pSoBaUm0dZXIOoRRu+1oSZi1gMCNp+v1i7542qZZ7l5jxO4vDK7lh0 JUaOiwS3ESNqOT/anuw+xMWPdkZNBJzuCCdxd7iTlzVo5DGOVjsB6F0lbGPbfOvw55gN BfbKTeM0opN2dPa2cQq2MvPn6MhAp1y0yRUyWK0689ItLe2fv4D0G5GiX89B4nJglI3G zkhHqtnPZwPn1o+vPotmh7Ep5B1foqVKPUaX9sM6CSOS720w8V7cDz0OqFO96Nme2Gfl E9LaH5ck/FwD01+wA1jRCF9LWUn6lt80q0tAzX1DJO3IjzvB4KRbasKQ0l2FZsANDlMB mBDA== Received: by 10.50.158.234 with SMTP id wx10mr14352igb.71.1334278012516; Thu, 12 Apr 2012 17:46:52 -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 p5sm757312igl.2.2012.04.12.17.46.49 (version=SSLv3 cipher=OTHER); Thu, 12 Apr 2012 17:46:51 -0700 (PDT) Message-ID: <4F877777.8050806@gmail.com> Date: Fri, 13 Apr 2012 10:46:47 +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> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060703040803090600070204" Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts From: davidkmuir@gmail.com (David Muir) --------------060703040803090600070204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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 --------------060703040803090600070204--