HTML output in PHP - looking for a really elegant way

Not interested in programming in YAML.

How do you know that your title (or any other content) doesn’t contain special html characters (such as &) which will mess up then generated html and possible do fun things like put the browser into quirks mode? So you need some kind of system to prevent that sort of thing. In Twig it is automatic. How about in yours?

I’m not the designer’s babysitter, and neither is my code. The only time such filters make sense is when dealing with end-user supplied content. Using them elsewhere is unnecessary overhead.

Your example also shows a complete page in your .phtml file. Are you seriously suggesting that you don’t have some kind of master base page that wraps around individual content pages?

What part of rudimentary did you not understand?

I use a templating system. That means I do use templates. Hell, in my example the class was called “Template” and that should have been a clue that, no, I’m not against using templates. What I’m against is coming up with a new syntax or language specifically for the templates and then parsing that language in PHP. I’d rather use PHP itself to parse the templates.

If you are not interesting in doing something like this then how about wrapping up a few of your actual deployed to production pages and I’ll convert them to Twig. I really think it would be a good experiment. But again, let’s make sure it is real.

Don’t even get me started thinking about the living HELL I’ve had to put up with in production for the last two years. The code is approaching 9 years old, executive meddling has prevented any meaningful revision in that entire time, blocks of the turd are written in PHP 3, there are 5 data modelling systems in place, 3 distinct incomplete frameworks and that’s just the surface of 3 pages of critical problems with the thing… just, no. What I deal with day to day is a sterling example of how not to code.

The system I’ve cited is from a new framework I’m working on, but its not complete and I can’t find the time and energy to complete it.

I think I can sympathize. My primary job is maintaining a 3D CAD application first deployed in 1985. Based on C with several propriety object systems on top. So much fun but it pays the bills.

Very thankful that I can actually design, build and deploy more or less modern PHP web sites as a hobby. You should try it. Here is one being used to organize a big soccer tournament in Knoxville in July: www.zayso.org/natgames

Heh heh… I write plays and do non programming things for a hobby.

Single quotes are white-space preserving, so why are you using multiple string additions?


$output='
		<tr class="'.$funky_zebra.'" title="See details for this Event">
			<td class="ev-date">'.$event_start.$event_end.'</td>
			<td class="ev-name"><a href="'.$event_permalink.'">'.$event_title.'</a></td>
			<td class="ev-location">'.$event_location.'</td>
			<td class="ev-status ev-status-'.$event_status_color.'">'.$event_status.'</td>
		</tr>';

NOT that as a rule I like building strings of markup, since string addition is slower than delimited output. A comma delimited echo is faster to execute and more reliable/predictable.


echo '
		<tr class="',$funky_zebra,'" title="See details for this Event">
			<td class="ev-date">',$event_start,$event_end,'</td>
			<td class="ev-name"><a href="',$event_permalink,'">',$event_title,'</a></td>
			<td class="ev-location">',$event_location,'</td>
			<td class="ev-status ev-status-',$event_status_color,'">',$event_status,'</td>
		</tr>';

Kind of laughing at the responses so far, many of which advocate throwing MORE code at something so simple… from templating library bloat to the idiotic “let’s open and close php on every line” nonsense…

I’m just wondering why you thought you needed to use double quotes and /t /n just to add carriage returns and tabs…

Off Topic:

…and why you’d put TITLE on a TR, or if those classes are even necessary since you could leverage colgroups for everything but FF and nth-child/sibling selectors for geckotards…

You guys are funny, if not a little preoccupied with your own opinions sometimes.

Hey! I resemble that remark.

Well personally I would advocate that a programmers code should protect against the actions of anyone other than the developer. Of course this depends on the environment in where the application will be used and who will ultimately be working with the application.

I’ve delivered solutions to plenty of clients where there is a marketing department, where some marketing or design person who is versed in HTML will be altering the UI from time to time, outside of a CMS capacity. Should my system allow this individual to do what they need to do, as per the companies requirements, in a safe manner. Or should I tell them that they need to replace their marketing guy with a designer who is versed technically from a programming perspective?

For example, I had a client a couple of years back who had an internal design and marketing department, one of the staff members was a designer who was “trained as a web designer” and would be adding custom skins to the site at certain seasons (Christmas, Easter, Summer and Autumn if I recall correctly). Their task; as in what they wanted to do each “season” would require them to do some amount of HTML editing on the site.

The template engine I delivered to them allowed this designer to create separate seasonal skins which were activated and deactivated (preserving the default skin), allowed the designer to create their skin updates without having to concern themselves with PHP code at all; as the PHP code shouldn’t affect them, and the system prevented them from inputting any PHP code, accessing any data they shouldn’t access or modifying any variables. So if the designer decided they wanted to be smart (ill judgement) or made any silly mistakes it wouldn’t affect the operations of their application.

Of course this all depends on how the system will be used and who will have access to it, your comment above is only really relevant if you know for certain your system is only going to be handled by skilled and experienced developers and designers, which isn’t always going to be the case.

Then quite frankly I’m not sure what this argument is about?

I for one never advocated using Smarty (I can’t stand Smarty and agree it bloats the application) and don’t advocate creating a template language that needs to be parsed unless the solution explicitly calls for such a thing to exist.

The rudimentary template system you demonstrated in your post is achieving exactly what I’m advocating, how templates are structured and the features of the “engine” are of course purely down to developer preferences and project requirements. If a system demands only a simplistic template engine then that’s great, if it demands something more feature-some then you can introduce that.

I don’t believe that HTML should be embedded into your applications code, that approach is just messy and can lead to problems down the line, so some kind of template engine, even a rudimentary one like the one you demonstrated, is required in most circumstances.

I still don’t think its a good idea to allow PHP code to be entered directly into templates. In doing so and I feel in your responses, you are making a lot of dangerous assumptions about who will be coming into contact with the application in the future.

It is interesting you say this, the two biggest issues I encounter as a developer, when working with existing systems are:

  1. Poor code structure and code bases that have been hacked about by developers in a bad manner; leading to systems that are difficult to maintain and often have issues that have been introduced at some point down the line.

  2. Code bases that don’t use template engines, where a “designer who knows some PHP” has attempted to make UI changes or front end redesigns and caused damage to the system in some way because they as a non developer didn’t really understand the systems code base or appreciate the nuances of development that is second nature to developers.

Introducing some kind of template engine, preferably that prevents PHP insertion into templates can help the second problem and in some cases help the first; as oftentimes I have found its UI type changes that are leading to the hacking around of code by a designer who has been hired to do some design work but has also taken on a few bits that involve a bit of coding.

Hi there,

I wasn’t here for a couple of days.
Thanks for keeping up answering.

deathshadow60:
I will try your recommendation as it seems to be sensible.

I’m just wondering why you thought you needed to use double quotes and /t /n just to add carriage returns and tabs…

I am just getting into the potential of PHP and with my example code I tried to create a clean ouput of HTML code.
I know now that there are better ways to do it and that was my main intention in coming here and ask my question.

Thank you guys!

Personally, I like both raw PHP and Twig. For the Symfony fans here, remember that raw PHP is the template system in Symfony 1.

But I also don’t think we should ignore the advantages that can come from an extra layer of templating logic. It can allow our output to be automatically HTML escaped, which I think is the biggest advantage. It keeps our applications secure by default. We’d have to go out of our way to screw up. The second-best advantage is that it prevents UI coders from mucking around. Of course, you could just tell everyone to only write templates in the proper way, but eventually someone – maybe a new hire – will be less than perfect. I think it’s a good thing when the language helps you enforce good practices. And finally, a new syntax designed for templates, and templates only, can be slightly shorter and easier to type. This last one is clearly the least significant advantage, but it’s an advantage nonetheless.

If it’s performance you’re worried about, then there’s two things to keep in mind. The first is that, if you profiled a real-life application with database fetches and inserts and other logic, I’d wager that a templating engine would be a small factor of the overall performance. And the second thing to keep in mind is that Twig, at least, actually compiles the templates to raw PHP. So it parses the template just once, and every request thereafter is served as raw PHP.