On Fri, Apr 13, 2012 at 7:15 AM, Matthew Weier O'Phinney <
weierophin...@php.net> wrote:
> On 2012-04-13, Kris Craig <kris.cr...@gmail.com> wrote:
> > On Thu, Apr 12, 2012 at 8:24 PM, John LeSueur <john.lesu...@gmail.com>
> wrote:
> > > //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.
> >
> > Again, the controller should NOT be a .phpp file. Likewise, your model
> > should NOT be hooking directly to the view. The controller hooks to the
> > model. The controller then sanitizes that and returns it to the view.
> > Alternatively, if you're not conforming to a pure MVC standard,
>
> Sorry, this is where you lose me. There's no "pure" MVC standard,
> particularly when it comes to MVC implementation on the web. There are
> many, many, many interpretations of how MVC works, and some generally
> accepted understanding around separation of concerns, but if you look at
> the ecosystem of MVC frameworks in PHP alone, you'll see that none of
> the frameworks do things the same way.
>
Yeah I went a bit overboard on the whole "MVC purity" soapbox. I do
believe that this way is the correct approach, but deriding all other
architectures as "broken" was a bit much.
>
> On top of this, there's an argument that you're not addressing: most
> template engines in PHP either directly consume PHP template files...
> or "compile" templates into... PHP template files. As such, sooner or
> later, you'll have a class that includes a PHP template file, and that's
> where things break for me in this proposal.
>
They don't break because nobody in their right mind would ever try to
include a .phpp file in a framework like that. If its stack is so
entangled, the very notion of a pure PHP stack is just incompatible. So
your best bet on a framework like that would be to stick with .php.
>
> I think the "pure PHP" vs "embedded PHP" has to be determined in a
> file-by-file basis, if at all -- NOT based on whether or not a file is
> consuming a file that has embedded PHP. Once you go down that rabbit
> hole, as soon as you have one file with embedded PHP (and most likely,
> you will), you'll have to assume the entire project is. At that point,
> there's zero benefit at all to making a distinction.
>
I believe the exact opposite to be true. If you expect a file you're
including to output *only* pure PHP code, but then it outputs a bunch of
HTML code, it shouldn't matter whether that code came from the file itself
or an included file. The result is the same either way. If that doesn't
treat them both the same, that lack of consistency basically makes the
whole point of including a pure PHP stack useless.
Alternatively, I suppose we could create a third type; one that goes on a
per-file basis instead of per-stack. While I personally don't see any
value to this, a few of you are expressing a desire for that, so I'd be
willing to meet you halfway on this and add that to the RFC.
>
> The proposals to use a flag with include, or to provide a separate
> "script()" function for switching between pure PHP/embedded PHP make
> sense to me. These make it easy for a framework/project to provide
> autoloaders that choose the appropriate flag/function necessary to load
> the class, and to select the appropriate flag/function when including
> embedded artifacts. They also make auditing code easy -- you can grep
> for one or the other.
>
The problem with that is you're basically creating two separate methods for
parsing the same file. Inherently, one of those methods will always work,
and the other method will always break. That makes no sense to me. If a
PHP script doesn't contain a <?php tag but it's all PHP code anyway, the
only keyword under your model that would ever work is script().
Conversely, if it does have a <?php tag and/or ?> content, the only keyword
that would work is include()/require(). So that completely defeats the
whole purpose of having separate keywords, since by definition the
distinction is still handling at the file-level anyway. So rather than
creating meaningless keyword distinctions, differentiating the file
extension is the logical approach.
> File extensions, on the other hand, are a non-starter, as is any
> approach that would insist that any consumer of a script that uses
> embedding be marked as embedded as well.
>
See above. Using separate keywords doesn't change this; it just makes it
more confusing and tedious.
>
> --
> Matthew Weier O'Phinney
> Project Lead | matt...@zend.com
> Zend Framework | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
