Article Discussion: JV’s Power Tips for PHP (Volume 1)

If you have any questions or comments about this article please post them here.

This forum post relates to this article

I find it odd.. You say that people should not break out of php tags for printing HTML. You give an argument why people do this, speed, but you do not give an argument anywhere on why you shouldn't break out of PHP tags.

It makes no sense to echo HTML using echo() or print() when you can break out of PHP tags. I won't mention the speed issue, but this is one reason. The other reason is that PHP was designedi] like this! PHP is after all a HTML-embedded scripting language. It means you can mix HTML code with <?php ?> tags, but what do you do? you stuff all your HTML inside echo ""; statements.


In fact, Smarty causes you hours of extra coding! You have to write code to control Smarty templates, when you can be off much easier by using PHP templates with simple <?=$variable?> tags in them. This is if you use PHP templates the right way, i.e. not mixing in all kinds of database access code and other code that has no business being in template files.

I don't want to have to explain this again, but if you want to argue on this, I suggest you read this thread over at the SitePoint forums.

...

Well I see it as a fabulous way to maintain the "separation of church and state". I guess if you are small time you could fail to see the importance of coding like Justin's example. You should try to embrace the concept though if your budget demands. You can hire all fresh college grads (that think they know everything) to code your basic hack work html stuff at minimum wage. You don't confuse them with other stuff. As well security may require these minimum wage people don't get to see the keys to the candy store.

While the article was a bit to apologetic (the author kept saying "But this is just my opinion, you don't have to agree..."), and contradicts itself several times, it does try to present some good points.

Also, for those against Smarty for various reasons, read this: http://smarty.php.net/whyuse.php

Oh, and as far as the rant on SitePoint is concerned, the one written by user voostind, while he makes a few points, most of his arguments fall flat in the face of elitism and his opinions. Frankly, I picked enough wholes in his argument that it just sank.

His posts may be based on elitism, his points are valid. When you think logically, which I hope is something we are all still able to do in this age of computers doing so much, they make sense.

If you can really find so many wholes in his arguments as you say, I'm sure you would not mind posting them here so all of us can read them

Okay, here are the holes that I have found.

First



He is partly right. PHP's initial design was essentially a templating engine. However, this isn't true anymore.

It's like saying JavaScript is just for the web, or Java is just for the embedded market. Just because a language was initially designed for something doesn't mean that's all it will ever be. In the end however, his argument here is trivial. Call it what you will, PHP is PHP.



That's completely untrue. There are still many places where PHP simply CAN'T be used as a template engine.

Let's say I want to create a service on my site, where other sites can use my service. These other sites want this service, when they use it, to use their site's style. So either I can either let them just use plain HTML with a small template system, or HTMl with PHP (because afterall, the argument is PHP is a template engine in itself). Now, anyone could see the potential for security risks for allowing them to use PHP, but we still need to offer the flexibility.

People want a template engine because they want something they want somethign that's sole purpose is to allow for the seperation of business logic and display.

Their is also great potential for failure for allowing design/html people access to PHP as their templating language. Seriously, a person can crash a site if they don't know what they are doing. Infinite loops are dangerous, especially when the person doesn't know what they are doing, and something a templating engine will prevent.



Obviously, I have to question whether he has every had to use an abstraction layer and had to switch from, let's say, MS SQL to Oracle, or MySQL to PostgreSQL, or even MySQL to Oracle. If it was that easy, we would all be using abstractions. However, anyone who knows anything about databases knows that SQL isn't all the standard. Sure, you can abstract everything, at the major cost of performance (and in this case, it's not a small performance loss). Really, if you switch from MySQL to Oracle, you should be changing a lot of SQL, as the design will possibly change to reflect the additional features Oracle has. Otherwise, it makes no sense to change.

His next argument about the CSS is an argument I agree with:



This is very much true. In fact, Wired.com has almost proven CSS is now here. Now, truth be told, I still believe we have about 2 more years because Wired.com type sites become more and more abundant, but it's a good point.

However, his argument about the web designer is a bit far fetched. 90% of the web designers I know (and I know quite a few), still use the table design. Why? Because it works! It works in Dreamweaver, and makes working from Photoshop easier.

A business can't sit back and fire everyone because they don't create CSS perfect XHTML compliant websites (XHTML is another story) every time, or else they would never find web designers (and knowing how to use CSS/XHTML doesn't make a person a web designer).

What I hope for is in the long run, designers work less with the code, and programmers, or coders, start working with the CSS/HTML more. Designers will continue designing in Photoshop and DW, and coders will take those designs, and turn them into CSS sites.

Back on topic.

He then goes on to talk about the PHP programming community in general, and in some aspects he is right. However, he makes a blanket statement that the PHP community knows nothing about software architecture.

But who is the judge here? How do you define good software architecture? Software that looks nice on the inside with ti's design?

In the real world, where many of us work, good software isn't decided by it's internal design, but by the finished product.

It's like the argument over monolithic kernels and microkernels. (On a site note, this is where I am not a professional, just an observer, so please feel free to correct me here). Monolithic kernels are said to be old and out dated. I am sure many of us have heard of the Linux v.s. Minix arguments earlier in the days. The issue isn't which is better.

The issue is that right now, even though all the elite minds of the software community said microkernels were the way to go design wise, monolithic kernels are still dominant.

Many programmers get so caught up in the development process that they forget the main reason for programming: to solve problems. If you solve the problem, the program works. Nuff said.

(Note: Despite having said all of that, I still take pride in writing good software. I do know who Knuth is - as soon as I get my new job, I am picking up his books at the local book store - and I do know my sorting algo's, etc.)

He then goes on to point out 4 questions and his answers to them. Here are my replies:

Question 1: Not really important. It's not anything about template engines, and more about software design in general.

Question 2: Actually, no, the lines of code are the same. Again, this is a moot point on both sides.

Question 3: Ugly syntax is opinion based. I know designers (not necessarily web based) who are absolutely afraid of HTML. I can only imagine what PHP will do. Also, by allowing the designers to use PHP, you give in to greater security risks.

He also argues that the designers can start experimenting with PHP much faster. Not only is this dangerous (again, imagine infinite loops on the live server), but it's completely contradicts his previous arguments with this being what's wrong with the PHP community. He want's designers to use PHP, however, that's what is wrong with the community? Maybe I am just reading too much into it.

In the end, the security risk is too great.

Question 4: He is partly right here. However, if you design your own PHP based template system as he suggests, you still have a template engine you need to maintain at some level. I doubt he has any personal experience with managine a template engine. We used a rather simple one at work (just replaced vars, etc), and didnt' have to maintain a thing. We couldn't use PHP either. Again, the security risk was there.

As you can see, most of his arguments in this rant against template engines either had holes, or weren't an argument against template engines.

Don't mistake my argument as saying that template engines are always important. It depends on what you need. Frankly, I don't use a template system on PHPComplete. I just use CSS to handle the display. But at the same time, there are many places I do use some form of a template engine.

The biggest error any person makes when arguing against template engines is to say they are not good because of these reasons, and all those reasons are based on HTML/Website only reasons.

I use a template engine for email. This allows people to use placeholders in emails, something like:

Dear {username},

Using PHP here would create a security risk, and also un-needed cruft.

voostind doesn't sound like a stupid person. In fact, him and I would probably agree on many things. This just isn't one of them.

template engines aren't bad, they just aren't always needed, they aren't the holy grail some people preach them to be.

Also, one more note.

Template engines are used everywhere in real world products, like word processors (MS Word, Open Office, KWord, Abiword), web design software (Macromedia Dreamweaver), presentation software (MS PowerPoint, etc). They all have a template engine. Sure, a person could hand code the template themselves, might even make for more efficient templates. Doesn't mean they have to.

jasonlotito,

You deserve a medal Well said!



As with many time saving implimentations, in the real world it takes effort to set up, but once it is set up it makes it easyer and faster to change your site when your site is a very big site with more than one person working on it.

PHP is no longer an HTML embedded scripting language as can be proved by the many people who are using it as a shell script tool and programming tools for writing deamons etc.

PHP has become a very serious programming language with some fantastic features and as such needs to be viewed that way.

There are many ways to skin an egg but it is my experience and opinion that sticking within php tags is best as a general rule.

This is the type of issue that only really makes sense after years of programming experience - especially when you get asked to re-work a site that you made 5 years ago - and you realise how much easier it would be if you had used the abstracted arcitecture you were using today!

The fact is the more you break stuff down the easier it is to understand and the more re-usable it is.

ie. Use small functions
Abstract static html from code

Cheers,
Justin.

jv22, you are completely missing the point:


This does not mean that PHP's use is limited to templating. I never said that and I never will. The point is that php can be used for templating. You don't need a template engine like Smarty for that. So, argument debunked.


I completely agree with you. This is a valid reason for using a template engine on top of PHP, for added security. It is in fact the reason I use one myself. But...:


Firstly, separating "business logic from presentation" is mis used here, but I understand what you are saying. It means that you should not have code that has nothing to do with presentation in your templates. As long as you keep the 'business logic', which in your definition is probably code to access databases, in a separate file from your HTML template, you can achive this separation just as well as by using Smarty. In the file with the code to access the database, simply assign variables you load from the database to something like $newsItems. In the template file, simply use a <?php foreach .. ?> loop to loop through those news items. There is no difference in using <?php foreach .. ?> or {loop from=".."}, except for the syntax.

What I think is causing a lot of heated discussions, is that some people think that people who debunk template engines are in favour of 'spaghetti PHP code', all kinds of non-presentational PHP code mixed with HTML. This is how we all started, it became a mess to maintain, so we resorted to template engines because we thought that was the right thing (tm). At this stage, there is no advantage in using a template engine over putting your HTML in a separate file with simple, and I'd like to stress the simple, PHP to display <?=$variables?>.

All that you say about CSS is in my opinion not relevant to the discussion of using PHP as templating engine instead of a third party one such as Smarty. So let's please stick to the topic.

If you read through my article you will see that that is EXACTLY what the article is saying.

So, even though you were the main protagonist and first poster to debunk the article... it seems that you have no argument with the article at all.

In fact you agree with it. Furthermore you are using the same concept that the article explains as your main argument - to argue against the article itself!

Justin.

What article are you referring to? your post above here? If I read that correctly, you are on the 'use a 3rd party template engine' side, but maybe I misinterpreted that.


Maybe I wrote it down a bit awkwardly, so let me rephrase it: Using a 3rd party template engine has no advantages over using PHP as your template engine when it comes to separating presentation from other logic.

This is really what the guts of my article entitled 'JV's Power Tips For Php (V1)' (JVPTFP) is about. If you read through the article you can see that I am not advocating 3rd party template systems.

I am suggesting that you write a function that parses an HTML file and injects php variables into it.

If you look at the method I use it is the eval statment to 'evaluate the html' file using 'PHP' and swap $vars for the dynamic value stored in the main PHP script.

Therefore you agree with the main article JVPTFP .

Yet you were the first person to make a post that debunked JVPTFP...

and now you are using arguments that JVPTFP makes...

to argue against others on this thread...

that you started when you originally debunked JVPTFP....

I was just pointing out that I found a certain irony in that!

Justin.

I'm sorry, I didn't realize you were the author of the article you were referring to.

Correct me if I am wrong, but this is what 3rd party template engines do!

The whole point of that discussion over at the sitepoint forums was to let PHP do the job of parsing a HTML file and injecting php variables into it. If you use a function to do this, even if all it does is simple str_replace()'s, you have in fact a template engine. At first simple str_replace()'s may be enough, but sooner or later you will need functionality to do blocks / loops. Eventually, this will turn out to be just another Smarty.

I read your article thoroughly, and at first I was relieved to read that you weren't supporting 3rd party template engines, but then I saw your own solution was not much different.