I have an opposite view, I believe it's part of what makes php so powerful and versatile.
Most coders do, it's just my op' that comes from several working concepts. In page creation, we separate presentation from document structure for a reason, to allow the presentation to be controlled externally without modification. See Zen Garden.
In the same way, scripting and programming - the functions and mechanics that drive the dynamic software - should also be allowed to be controlled remotely, and you should be able to not only change it's form and output with external tools (templates,) you shouldn't have to muck about with the code to do so. When you mix programming in with (X)HTML it moves farther and farther from separation of form and function.
Second, it makes it very difficult for a designer to create a template, especially if they are working in WYSIWYG's. On a whim the other day I opened a PHP script in a browser, just to see if I could get a visual on what the HTML parts were doing. It was so spaghetti'ed up with PHP every third line, viewing it in a browser was a waste of time. With applications I code, a template has
markers, like
|HEADING|
|CONTENT|
or more design-friendly,
<!--HEADING-->
and any designer can modify to their heart's content as long as they leave the markers in.
I've had to mod many current WP, vBulletin, PHPBB templates, and while I muddle through it, it takes me three times longer than it should, and I wonder how many non-savvy designers do it.
seeing huge chunks of constructed $var's to echo later down the page
When you store output in a variable, yes, you are taking up space in
memory. But what's more costly, a single request to the PHP parser and storing it's work in memory or multiple calls to it? I'm asking because with PHP, I don't know, but in my experience with Perl, the former gives much more consistent results. There used to be a day when we would consider memory usage over user experience, but the technology has changed, we can trade a little memory for an improved user experience.
Unless you have extremely large pages, storing page output, which may (should!) be 20-50K at best, is a highly efficient approach as opposed to process and print. Have you ever had a page that does this?
-- shows the header
-- pauses, waits for a complicated database query
-- starts to output the query
-- outputs rows slowly, if the query is inefficient
-- sometimes dies in mid page if the mysql server chokes, leaving the bottom half of the page empty
-- finally finishes out the rest of the page.
I'd rather spit the entire output to the browser as a completed chunk than line by line. When you process->print process-> print you have to remember, the
print is the connection from the server to the browser, you're sending data along that connection to the end user. A lot of things can go wrong between process and print that have nothing to do with your script. The more prints you have, the more opportunity for something to break. I'd rather send it once.
All boils down to experimentation and what gives the best experience at the least cost to the server, I guess.
[edited by: rocknbil at 7:16 pm (utc) on Jul 9, 2010]
