Forum Moderators: coopster
We are probably familiar with the "echo "Hello World" ;" example. However, the "real world" is often far less simplistic and quite different. Here are 4 examples of how a dynamic page could be rendered:
Example 1 - using echo.
echo $normalfont.translate("times every").$closefont ;
echo " <select name=rday>\n\t<option value=0 selected>".translate("Day")."\n";
for ($i = 1;$i<=7;$i++){
echo "\t<option value=$i" ;
echo ">$week[$i]\n";
}
Example 2 - using HEREDOC.
echo <<<EOT
<tr>
<td class="tableh2" colspan="3">
<b>$text</b>
</td>
</tr>
EOT;
Example 3 - using a tablerender function.
$text .= "<tr>
<td style='width:5%' class='forumheader3'> </td>
<td style='width:30%' class='forumheader3'><b>".FMLAN_17."</b></td>
<td class='forumheader3'><b>".FMLAN_18."</b></td>
<td style='width:30%' class='forumheader3'><b>".FMLAN_19."</b></td>
<td class='forumheader3'><b>".FMLAN_20."</b></td>
</tr>";
Example 4 - embedding php into html.
<TR><TD><B CLASS="tooltip" TITLE="<?php etooltip("brief-description-help")?>"><?php etranslate("Brief Description")?>:</B></TD>
<TD><INPUT NAME="name" SIZE=25 VALUE="<?php echo htmlspecialchars ( $name );?>"></TD></TR>
Okay, these are "real world" examples pulled from various working applications. Let's exclude the content. In some instances there's a lot there that leaves much to be desired - especially setting fonts as functions. I think the author in Example 1 has yet to discover CSS.
The question that begs: which, of all of these rendering types, is the more efficient?
My own observations are as follows:
In Example 1 - as I understand it - each time there is an ECHO, a call is made to the server before the line is rendered. In the first example there are 915 lines of code with 296 ECHO calls. Seems like a serious performance hit there.
Example 3 seems, in many ways, similar to the HEREDOC rendering as presented in Example 2. The difference being that page rendering is now run as a function - lending itself to a consistant way to rendering pages across a site. The page starts off with a $text = " ... " ; and the following chucks of html are appended with $text .= " ... " ; as the page is built up.
Example 4 strikes me as the "mature" way of rendering a dynamic page. In this particular examples most of the logic was lodged at the top of the page followed by the html component lower down.
Another question that may arise here is, "Which is the right way of doing all this"? Some how I don't believe this would be altogether appropriate as there doesn't seem to be an absolutely "right way" of doing this. A bit like making a slice of toast. Toast is toast.
Anyway, would be interested in any opinions and comments on this matter.
I most often use the embedding html in php or echoing, depending on how much html I have to spit out.
Being fairly new to all this, I guess I'm looking for common ground somewhere.
In working through the code in Example 1, I fast came to the conclusion that there's go to be a better way. Echo this, that and the other, all those \n's, double quotes and the rest - no thanks.
In Example 4 there are a couple of echo's in there but this in context of the functions being used -not as the primary mechanism of rendering a page as in Example 1.
As mentioned, I see Example 4 as being the "mature" way of rendering a dynamic page. By that I mean, of the range of examples I have come across recently the better web applications seem to be rendered in this fashion.
Put another way, out there there appear to be application developers and content providers. With application developers, HTML seems to come in as an afterthought. With content providers, logic appears to become an integral part of page development and delivery.
In terms of benchmark - I'm still a long way off from knowing whether this matters or not. Put another way, when I go shopping, I like doing it all at once rather an buying one item at a time - as in the perceived difference between ECHO and any of the other methods.
you're not buying.
What is the most important thing with web pages?
speed
where is the speed necessary?
for the user
should my programs be dictated by what's easiest for me?
not a chance, or, to look at it properly
what's best for my user is best for me. Therefore, benchmarking different ways of doing things should have the end result of making the web experience be bigger/better/faster/more for my end user.
So the way I try to look at it is on many levels. Each line of code has to be (not in any order)
1. effective and error free
2. powerful, I don't need to do in 5 lines what can be done in one
3. secure
4. user friendly
5. fast
6. use system resources effectively
and fast ;) you may get away with doing something poorly twice if it's fast but regardless of how good something is, if it is too slow, you won't get to do it once.
which is most important? Everyone may have different views on this but I build pages/scripts/programs for a user. My user is the most important. It may be a person surfing the site, the client I built the tool for, a search engine spider or others.
I make all of my coding choices based on an understanding of my audience so, in this particular case, I would choose which ever is the fastest solution. If it's close then I get to choose and ease of coding for me enters the equation.
He's right, it's not what you want, it's what the user wants. That said, with decent "abstraction", the construction of the program is invisible to the users (and if you are the application developer, *your* users may be the content writer and the end user).
So we come down to his list, but I would add
7. maintainable.
As for SPEED, it does matter (which means size matters too, but we won't go there). I have benchmarked various methods of getting html out to the page and notice that there are surprising small variations - like you get slight speed differences depending on whether you use single or double quotes, concatenation or variables within double quotes. Most of these make no difference, but one makes a big difference - jumping in and out of the PHP processor.
As a general rule, it is much faster to echo out short strings here and there than it is to invoke the PHP processor, quit, invoke and so on. Once the output gets to the size of a large paragraph, though, it becomes worth it, because the overhead of switching modes is less than performance lag caused by sending straight HTML through the PHP processor for, effectively, no reason.
To avoid this, I put off output as long as possible. Once everything is processed, I call a template that has nothing but HTML and variable substitutions. This is the *second* reason I use templates.
The *first* reason is maintainability. Far more important than what looks/feels like "mature" PHP, is what will be easiest to fix and update in 2 years, what will be easiest for someone else to change. Templates are great for this because
1. Document layout and structure are transparent and one need not know PHP to change them. Since I am artistically impaired, this means that someone with actual ability could handle the "look" with minimum need for my expertise. In other words I don't have to explain anything.
2. Since the basic functionality is in functions, classes or perhaps included files, and since the template makes structure clear, a developer who takes over can find where things come from, update the function once and be done with it. When it get plugged into the template, all pages now work correctly.
As you may guess, this involves using ALL FOUR methods you describe, as appropriate. Now, I'm hardly a PHP expert let alone a programmer, but I do think this is a fairly logical approach and makes sense from the perspective of functional abstraction, maintainability and usability. It makes some compromises on speed, but that could always be fixed after the site goes live by somehow optimizing the few pages that get the lion's share of the traffic (caching static versions, optimizing the script for speed and compromising on maintainability and so on).
Tom
My personal preference is using templates to completely abstract the php code from the html. At one time, I use to intermix the two also but found non-programmers were more at ease in modifying site design when they didn't have to deal with code at all. Replacement variables were less threatening and confusing to them. Plus they could work on design at the exact same time coding was being done and didn't inadvertantly break it by deleting quotes, semicolons, or whatever. Many programmers are not good at site design and many who specialize in design are not programmers. Templates work great in this type of situation. Second preference is #3 with delaying output as long as possible.
IMO example #4 is very hard to maintain and is not a sign of maturity but a sign of someone who learned how to build static pages first and now is trying to add dynamic to them. Yes, a lot of examples are displayed this way but IMO it's not the best from a maintainability point of view.
As for the speed difference among the four, my guess is it's not noticable unless the site is getting a high volume of traffic. Even then other factors will come into play.
Speed is important but maintainability is more important.
Definitely! I realize that wasn't clear in my post, but I completely agree unless your time is worth $.02/hour or you have programmers that work that way. Otherwise get more hardware (important site) or deal with slight slowdown (less important site).
Also, when I say I use all four methods, I pretty much use method four only four variable substitution into templates. HEREDOC I've only used once or twice and I can't remember why... I used to echo a lot, but once I started using templates exclusively, I tend to assign strings to vars in functions and then use shorthand to output them.
As for the speed difference among the four, my guess is it's not noticable unless the site is getting a high volume of traffic.
Correct. To get significant results benchmarking, you usually have to run at least 1000 iterations, sometimes 10K. And as you point out, other factors (things like inefficient use of database queries inside loops just to mentino something still within the PHP realm) will likely end up way more significant than how you choose to output things.
Tom
I always design my sites for high volumes of traffic, I always hope that is how it is going to work out.
I use a similar tempating system, though I design it differently for each site. I don't have anyone else doing my html, js or css so I design what is most easily maintainable for me. I also have 6 servers for serving 1 site so I am quite spoiled and laziness could easily creep in.
I don't use heredoc very often either. I am not completely sure why but it just doesn't fit in very often with the way I am used to building things.
From my side, I'm at the "beginning" of this loop. Came into this whole thing from the design side. In order to expedite a project I was given, picked up on one of these PHP-based CMS packages. I'm now in the process of "cleaning" it up - hence this and other related threads.
The examples cited here are "real world" as in extracted from the various components with which I've been working. Together with time and resource constraints don't have too much on my side but to push this thing out.
As mentioned before, took one look at Example 1 and thought, this looks like trouble. The package I'm working with uses table rendering as in Example 3. May be I took the code sample in Example 4 out of context. However, in that example, all the logic was either at the top of the page or contained in includes. The PHP was then dropped in where required. Of the 4, it looked the "better way" - this from a rookie and someone who is more design orientated than programming.
Needless to say, have just come across this:
<{$x.navbar}> <{$x.date}>
<{$x.eventsOf}> : <{$x.eventdate}>
<{$x.prevNext}>
<{section name=k loop=$x.title}> <{$x.title[k]}> ¦ <{$x.category[k]}> : <{$x.categoryName[k]}>
<{$x.description[k]}> <{$x.readmore[k]}>
<{/section}> <{$x.searchform}>
<{$x.backLink}>
<{$x.credits}>
Which I gather is a smarty based template. Yes, would be great to resolve everything down to just this. Guess we needed to make a start somewhere, hence this tread.
ergophobe, I'm surprised you consider yourself "hardly a PHP expert let alone a programmer" -- I've read many of your posts and I think you may be discounting yourself. I am a programmer and I'll concur with the direction provided by you and jatar_k (I'm also a sycophantic admirer, BTW). You have both given some excellent advice here.
FWIW, here was yesterday morning's thoughts:
Just kidding, of course -- I'm just noting that you are asking very good questions, questions that programmers will debate until the end of time. I'm sure this thread will grow quickly and you are going to see many different opinions. And for what it's worth, I'll add mine...
what's best for my user is best for me
If there's one thing to remember, it's that line from jatar_k. If you are doing this for a living, and you don't code to that standard, you won't be doing this for a living very long.
That said, I'll still throw my two-cents worth in regarding another point that is best for the user: cost. And your impact on cost can be associated directly through ease of coding, which often times gets misinterpreted as "my pleasure versus the customer's need", and is a big battleground. I guess instead of ease of coding we should say ease of maintenance and it may become more clear as there is a...
cost to the (user¦buyer¦client¦customer)
Let me explain. If you've ever had to go through somebody else's spaghetti code you know what I'm talking about. Or maybe it was some of your own early-on code before you realized there was a better way. Making what should be simple modifications can often times be a daunting task, simply because the code is difficult to follow and maintain. You'll get good enough at it that you can take one peek and quickly declare it would be easier to start from scratch. Either way, it's going to cost somebody: your client, you, or both. However, it won't have to cost as much if the code is easy to maintain. And less cost = happier parties; your client will be happy, which in turn keeps you in favor with them, keeping you happy. I've found it best to try to set a standard and stick to it, and the standards offered here are impeccable, especially jatar_k's declaration:
what's best for my user is best for me
...
function makeHTML($title, $header,
$content, $footer) {
?>
<html>
<head>
<title><?php echo $title;?></title>
</head>
<body>
<div>
<h1><?php echo $header;?></h1>
<?php echo $content;?>
<h2><?php echo $footer;?></h2>
</div>
</body>
</html>
<?php
}
...
What's the fun of being able to drop in and out of PHP mode if ya don't use it? ;)
Jordan
I tend to build things up in a variable $out, and then send that to my formatting function atthe end of the script: format_page($title,$out,$keywords);
