On Tue, Apr 10, 2012 at 8:35 PM, Tom Boutell <t...@punkave.com> wrote:
> On Tue, Apr 10, 2012 at 10:10 PM, Kris Craig <kris.cr...@gmail.com> wrote:
> > This shouldn't be used to load libraries that dump raw HTML output! That
> > literally defeats the entire purpose. You're also assuming that all PHP
> > developers do 100% of their coding through pre-existing frameworks.
>
> Consider a .phpp file that includes a .php template file when it sees
> fit, in a render() method. How is this different from an echo()
> statement? It's not. It's just a convenient form in some situations.
> By punting these out to .php files we achieve better separation of
> concerns while still respecting PHP's history as a template language
> (and possible future if it improves in that area, which it may).
>
Again, this can easily be made to work using a simple MVC architecture.
I.e. the "view" layer calls controller::render(), which then includes
model.phpp and funnels the call to model::render(). Again, this is just
basic segregation of model (i.e. "pure") code from view (i.e. template)
code. This is already widely considered best practices, so having this
conform to that is not a bad thing. On the other hand, your approach makes
it impossible to determine absolutely that the model code will remain pure,
thus rendering this whole RFC completely and utterly useless IMHO.
> All I want is to stop typing <?php and dealing with whitespace
> screwups above <?php. I want to do that in a way that's practical and
> interoperable and which people might be able to vote for if they have
> a nontrivial amount of legacy code in their life, like everybody I
> work with (:
>
I know. But unfortunately, for reasons already discussed ad nauseum, the
only way to truly accomplish that without weighing other factors would be
to massively break all PHP scripts that currently exist. You may want to
just have a simple removal of <?php, but it's not that simple so you should
probably adjust your expectations accordingly.
>
> As many have pointed out, plain php template files work for some
> projects. A viable RFC that people might actually vote for should
> respect that. It neither picks my pocket nor breaks my leg if someone
> wants to include .php template files from a .phpp file. I don't have
> to do it.
>
Again, if you're concerned about that, then you have no business including
them within a .phpp file to begin with. It's basically like turning on the
shower but then covering the nozzle with a stopper so that no water will
come out, allowing you to "take a shower" while still remaining dirty. If
you want to stay covered in dirt, then don't take a shower! If you do take
a shower, then you have no business doing so if your goal isn't to get
clean. That would just make no sense.
> When you consider that I would be completely unable to use an existing
> .php library of nontrival code like Amazon's S3 SDK under your
> proposal without a convoluted workaround it is pretty much a certainty
> that I would have to vote no if the RFC read that way.
>
That's a logical fallacy because it's based on a faulty premise. I.e.
"....I would be completely unable to use.... without a convoluted
workaround...."
That statement is inaccurate because there is no "workaround," convoluted
or otherwise. It's just standard MVC architecture, which is neither
convoluted nor uncommon. If somebody wanted to be able to write a script
containing class instantiation but keep the code 100% procedural, most
people would tell that person to rethink that idea. He could say that
having to define a class is a "convoluted workaround," but it's not.
Instead of having your .phpp script call a script containing HTML, and thus
essentially having your .phpp file contain HTML and thus be no different on
a practical level than a regular .php file, just have a regular .php script
that calls both the .phpp file and the .php library. That's not
complicated. In fact, it's insultingly simple. If you want it to be pure
PHP, then it needs to be pure PHP throughout its stack (i.e. includes).
Either way, it needs to be consistent. Your approach would add far too
much complexity/confusion without any practical gain, whatsoever (aside
from not having to type that 5-character <?php tag).
>
> > (Main Script)
> > |
> > |
> > [Included .php/HTML Script]
> > | |
> > | |
> > {Included .phpp Script} [Included .php/HTML Script from
> > Framework/Library]
>
> This is convoluted and forces me to write a .php frontend. Surely that
> is not your goal.
>
I think the problem is you're trying to have it both ways. No, you are not
forced to write a .php frontend. You can send whatever HTML/template
output you need through echo/print/etc, without ever having to use the ?>
tag.
Furthermore, if you're including a library with HTML bits, then I'd say the
ship has already sailed with regard to having a .php frontend. If you
don't wany any .php frontend in your code, then simply don't use a library
that relies on it. Simple as that. If you so want to include the library,
then simply make sure that there are no .php/HTML frontend files below it
in the stack, which is what you should be doing anyway.
Also, the model above is just one example, and it's not complicated. In
fact, it contains all the same stuff as the bad example model above it; the
only difference is that the .php and .phpp scripts are on the same level
instead of .phpp calling a .php file that contains raw HTML code.
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
