It seems to be a theme with MVC frameworks that they’ll include template engine, as I shudder, a good thing. I don’t believe they realize that there have already been a mass development of template engines and the conclusion that came out of it, was that PHP is already a great template engine. Why create a new language when you can already use the language that you were going to create?
It seems counter-productive. All that time spent writing a new template engine that has gone to waste, because of the strict compliance to the MVC paradigm. I don’t believe people realize that any template engine they create is logic and thus including logic into their views. If you were to follow MVC strictly to the “word” then you spend all of your time adhering to the “word” and not completing the project itself.
What is more important, to spend time building a shitty template engine that is either so simple as to not be worth anything, or so complicated that it creates an entirely new language for which both the designers and programmers have to learn. You can’t prevent or save designers from programming, if they wish to do anything more complicated then HTML and CSS. You can give them better API controls for which to make the coding simpler and faster for them to understand.
That is what I think is sad. Too much time was spent trying to so called simplify the development, that developers failed to realize that development is inherently difficult. You can remove some of the pain and suffering that comes from the complexity, but not all of it. By creating a template engine, you not only hinder the designer who doesn’t give a shit about the template engine and arcane syntax, but also the programmer who has to learn yet another template engine and learn the syntax and how to apply their code to the template engine.
To be honest, I’ve already spent too much time already with the mess known as templating engines and I don’t wish to relive those experiences. I’ve already written my own (crappy) template engine and thought that I was clever using XML with XSLT. I’ve already had to work around another template engine and had to finally just strip most of the templating out of the HTML. The templating engine was worthless, because it restricted the codebase far too well.
Furthermore, I care not about how you write your template engine, you are wasting your time and mine if you wish for me to learn yours. The languages that require such separation are not PHP, which can mix it. It is also true that the paradigm is more about separating business logic and presentation even more, but not too much that the forest for the trees are lost completely.
It is alright to mix PHP and HTML, as long as you don’t mix too much logic or too much code into the views. That is what I think the developers had in mind, but no templating engine will be as well written and featured while working with other libraries and other views and code than PHP itself (as long as the codebases and views are also written in PHP).
I fear that novices and beginners who have entered the PHP development in the past few years have not learned this, but they will or should in the failures of their system in the future. Anyone and most everyone has built a template engine in the past, why continue that tradition when it was a mistake in the first place.
Possibly Related Posts:
- Game Engine Development and Open Source
- Plans for Base CMS
- Project Plans
- Calibre Improvements Part 2
- Usability Testing Software Development
Well, then throw away PHP and write your websites in assembler? My God, why so many programmers force me to learn yet another scripting language and telling me that “I need it to write my websites”? I know C and assembler, I don’t want to waste my time to learn such a crap. I don’t even know, why the world is so amazed with Java, if there is C++…
Calm down, PHP does not offer anything special when it comes to templates – it is just a “yet another scripting language”. You are angry, because you got used to use it, but many other people are angry, because its imperative nature forces the programmer to produce lots of code just to solve a simple presentation problem (i.e. form rendering) or reinvent a wheel every time you want to add a certain feature. This is the same process that led to create PHP and many other programming languages.
I agree that it is very hard to create a template language that is not just a subset of PHP (i.e. Smarty and most of the clones) but really helps the template designer. Thankfully, there are people who attempted to write such tools and there are people who prefer to use it. Is it a problem for you that someone has a different point of view? The argument about “learning a new language” is not an argument, because the presentation framework that makes PHP actually useful for templates must also be learnt and it could be even more complex than a programming language with familiar control structures.
I’m saying that using a simplified set of PHP logic and loops is far easier and faster than templating engines. Templating engines do not make it “easier” than PHP for designers, no more than learning a subset of PHP would. It doesn’t solve that problem and adds additional complexity to programmers having to spend time to learn the templating engine and also learn how to extend it. PHP programmers already know how to build APIs in PHP and use them within views.
The goal is to spend up development, not slow it down. The reason you don’t write web sites in Assembler is that it would take forever to do so. Furthermore there are only two or three Assembler codes if you are programming for current processors, not including other specialized systems. Supporting them is easier, if you use C and only use Assembler to speed up certain operations. However, there are hundreds, if not thousands of templating engines. Everyone plus their neighbor creates them, because they are relatively simple to do. Not so much to do well.
My contention is that instead of doing:
Parsing and converting to PHP.
Why not just do
, it is similar (not all are), except the difference is that the first is parsed by PHP and then converted to PHP, while the second is compile with everything else in PHP allowing for tools built for PHP to take advantage of not lack of an intermediate step, unlike the first one.
Is there really any difference? Not really, all you are doing is adding an unneeded intermediary step, for the sake of whatever. Call it “easier”, “better”, etc, but what I call it is additional complexity to both the library, additional work for me, additional time for me, additional cursing of your name for me, and using another solution that doesn’t use such bull shit.
My argument for “learning a new language” is to point out that it is what people are doing when they create an templating engine. There is no way to get around logic, loops, and additional “complexities,” and instead of solving the real problem with creating an API that includes helpers and abstraction that simplifications the usage, they decide the problem isn’t that but PHP itself. This is incorrect, PHP is far better than many of the poorly designed and implemented templating engines out there.
The goal is to allow even novices to extend and use your views and systems. When you create a templating engine, you create an exclusive club that requires the PHP developer be this tall (or skilled) to join. Not so with PHP. I wish more people would look at WordPress at how a simple API should be created that doesn’t use a templating engine. I believe the reason people shy away from doing so is all of the other imperfections in WordPress. Certain parts in WordPress are better than others, good lessons can be learned, and one of them is that you don’t need templating engines.
I couldn’t agree more. I started out as purely a designer and found the likes of WordPress and SMF to be infinitely easier to use AND it taught me some basic PHP in the process. I don’t see any point whatsoever in complicating things by adding an extra layer of crap between me and the end result.
Having said that, there are distinct benefits in using a templating engine when it comes to allowing users to upload themes to their sites. You can see this between Blogger and WordPress.com where Blogger users are able to totally redesign their site designs whereas WordPress.com users are limited to only being able to modify their CSS.
There are several ways to go about this that don’t include template engines. One is the bbcode way, the other is the shortcode way in WordPress. Both use the same concepts. What you are doing is abstracting the code for which the user only has control over where it is located as well as a few options. HTML Purifier and other HTML sanitization libraries allow your user to have HTML within their templates without harming your site too much.
It is true that CSS alone doesn’t handle all of the different structures and designers that users will want with their site. However, several themes have existed that include options that allowed a greater control of where elements are placed. Alas with widgets and their controls, it is even easier to set up a template and design a site that allows users to control how the template appears without compromising the security of the site too much.
That said, the scope of this post is between the hard coded, the theme designers and application and theme developers. Complexity should never be put on the users hands just to simplify your life. Programming is difficult, it is meant to be, that is why we are paid to do it and do it well.
I’ll give you another gem. Very few programmers, designers, or anyone wants to work extremely hard to do something. When you use template engines, you are adding complexity that has very little reward. It would be worth it if everyone used the same template engine, but well that already exists and it is called PHP, people just don’t realize that it is good enough to function as their template engine and their API at the same time.
I think that this is one of those lessons that people have to learn for themselves.
Many years ago I started writing my own templating engine. It started off simple enough, just replacing special markers with dynamic values. But then I decided that I wanted to be able to loop inside my template. The syntax was ugly and was really just a subset of the language I implemented it in anyway.
I still don’t put any non-trivial logic in the presentation layer, but I agree that mixing some function calls in with your HTML is a better solution than a templating language.
Cheers,
Stuart.