Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59841
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAL0xaBEpPuAeLKJTR9XVOO+3GVm4m4L6ELhQ+Vc-3xtdr+YM5Q@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>
	<CAL0xaBEpPuAeLKJTR9XVOO+3GVm4m4L6ELhQ+Vc-3xtdr+YM5Q@mail.gmail.com>
Date: Thu, 12 Apr 2012 18:46:28 -0700
Message-ID: <CAKOpQSy4E_t1TfLNEkL4c3h8aWoWSfpR3sPTqjCQPuYgx7TxRg@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@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=f46d043bd7e81937c404bd85a489
Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
From: kris.craig@gmail.com (Kris Craig)

--f46d043bd7e81937c404bd85a489
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 12, 2012 at 6:26 PM, Arvids Godjuks <arvids.godjuks@gmail.com>w=
rote:

> 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 p=
hp
> 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.
>
The autoloading standard is still more or less in its infancy IMHO; the MVC
standard, on the other hand, has been around for awhile and is widely
accepted.  I haven't done any detailed work with the autoloading standard,
but I'll look into it.  I can't imagine though that it would be so
inflexible as to make it completely incompatible with existing MVC
standards.  If that was the case, then I can't imagine ever wanting to use
that, anyway.


> 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.
>
You are aware that Apache runs on both Windows and Linux, right?  It's the
"A" in "LAMP", after all.  ;P


> 13.04.2012 3:05 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 "Kris Craig" <kris.c=
raig@gmail.com> =CE=C1=D0=C9=D3=C1=CC:
>
> 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 P=
HP
>> >> >> 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 .php=
p,
>> >> 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 fro=
m
>> 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 stac=
k.
>> Problem solved.  It's really not as complicated or confusing as you're
>> making it out to be.
>>
>> --Kris
>>
>

--f46d043bd7e81937c404bd85a489--