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.
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.
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.
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.
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.
--
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
