Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59836
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKOpQSyC6Zs=3-AQ8=L-aufTP03j0yhnRiu3n6pNP7YSpW_KLg@mail.gmail.com>
References: <CAKOpQSwYe+tZ3JfLFWaOHCnBpUyy9yoA61=qLzbnnOKTL0mQdQ@mail.gmail.com>
	<CAGa2bXa554p45tbNFvtHQJiYTXaa0eD6r+qnExDVk+6e8PRvMw@mail.gmail.com>
	<4F876943.8030105@gmail.com>
	<CAKOpQSzAZauE9HYK3x-5UbxAstkdkc-HkfZRa+E+i=DNxQwkBA@mail.gmail.com>
	<4F877777.8050806@gmail.com>
	<CAKOpQSyC6Zs=3-AQ8=L-aufTP03j0yhnRiu3n6pNP7YSpW_KLg@mail.gmail.com>
Date: Fri, 13 Apr 2012 04:26:10 +0300
Message-ID: <CAL0xaBEpPuAeLKJTR9XVOO+3GVm4m4L6ELhQ+Vc-3xtdr+YM5Q@mail.gmail.com>
To: Kris Craig <kris.craig@gmail.com>
Cc: PHP internals list <internals@lists.php.net>, Yasuo Ohgaki <yohgaki@ohgaki.net>, 
	David Muir <davidkmuir@gmail.com>
Content-Type: multipart/alternative; boundary=f46d041702a789196104bd855b01
Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--f46d041702a789196104bd855b01
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.
13.04.2012 3:05 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=
=B5=D0=BB=D1=8C "Kris Craig" <kris.craig@gmail.com> =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB:

> 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 PH=
P
> >> >> 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 loca=
te
> >> > 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 b=
e
> >> 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 templat=
e,
> > 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, th=
en
> > 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 o=
f
> 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
>

--f46d041702a789196104bd855b01--