Templating

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
neophyte
DevNet Resident
Posts: 1537
Joined: Tue Jan 20, 2004 4:58 pm
Location: Minnesota

Templating

Post by neophyte »

Okay, I know this is not the first time this has been brought up on this forum before but I have to vent.

The over arching idea behind using PHP templating classes is to keep php code separate from html. Thus the designer can have his way with apperance while not touching a single line of PHP code. I don't think 100% separation is possible -- if so why template at all? I just bumped into this on our phpBB board today. I wanted control over the color of our links on our board. So I figure, "open up the right .tpl and insert class="blah" in the "a" tag." Wrong. The "a" tag was built in code. Also the alternating row colors was also tucked away in the code. I'm just wondering? Why bother with all the extra templating? This is not the first time I've run into this issue. Anybody else with me on this? I guess right now I'm leaning away from templating. There are a lot of Open Source projects that don't use templates... Moodle, osCommerce to name a couple....

I've worked with Yapter and the phpBB templating class. I've never built one of my own. Everyone on this forum tends to agree on SMARTY.

Is 100% code/html separation possible?

Did I miss the point?

Do you template all the time, some, or never and why?
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

it is possible to have 100% seperation, but many uses fall short some distance, like you've experienced.

Currently, I try to template 100% of the time. Getting all html code from the template files. I've personally got about 99.99% of my stuff in templates. So an odd bit of XHTML here and there, like a <br />
User avatar
markl999
DevNet Resident
Posts: 1972
Joined: Thu Oct 16, 2003 5:49 pm
Location: Manchester (UK)

Post by markl999 »

is to keep php code separate from html
Not to be picky but that's not strictly true. It's more to separate business logic from presentation logic, there's nothing wrong with having presentation php/logic in the template. Just on the subject of templates ... i've tried pretty much all of them extensively and PRADO is a dream come true for me, it really does seem logical for website templating imho. Worth a go if you're still unsure/undecided.
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

Layering is very important. That's what programming is all about really: chopping things up into discrete responsibilities all the way from application layers right down to method definitions.

Link color probably ought to be controlled via CSS. Still, sometimes you'll want to set styles dynamically.

It is notoriously easy to mix up domain logic and presentation logic. Say you want to display all overdrawn accounts in red. "Overdrawn" is domain logic which you could pass to the presentation as a boolean. The template would use some php code to check the boolean flag and then add the appropriate colour.

Even Fowler (Patterns of Enterprise Application Architecture) is slightly ambiguous though:

"When reviewing this book, Alan Knight commented that he was 'torn between whether just putting that into the UI is the first step on a slippery slope to hell or a perfectly reasonable thing to do that only a dogmatic purist would object to.' The reason we are uneasy is because it's both!"

However, there's a world of difference between making a decision based on a full understanding of the design implications and coding impulsively, blindly. The point of keeping domain logic out of the presentation layer is to allow output in any format (html, xml, pdf, txt, etc) without having to repeat parts of the domain logic in each. (Incidentally, that's another important principle DRY - don't repeat yourself. A fundamental refactoring is that anything which is repeated should be resolved to a single source).
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

This all sounds very ermm.. *swotty*. Nice to read an intelectual discussion in here as opposed to just problem solving lol ;-)
ianlandsman
Forum Newbie
Posts: 24
Joined: Thu Dec 30, 2004 9:50 pm
Location: New York

Post by ianlandsman »

In my experience the best templating engines use PHP as the template language (since it is one technically). This give you alot more flexibility than something like smarty. I've had very good luck with Savant

http://phpsavant.com/yawiki/
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post by John Cartwright »

On clients website I find it makes them alot easier for the client with minimal knowledge of programming to edit some minor changes as opposed to having 1 bulky file. I find it tends to minimize the times I would have to fix the code after a client accidently caused a parse error.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Did I miss the point?
If there was just one point maybe but there are several points you are touching on and the each have different answers.

Probably the main point you are missing is that PHP is two things: a programming language and a templating language. So it depends which way you are using PHP.

If you are building a site that really only needs templates because it does not have very complex data model or controller logic, then using PHP as a template language is great. Mixing HTML and code is a fast, clear and immediate way to build things like web pages. Hence the success of PHP because it excels at just that.

However if you want to treat PHP as a programming language, then the HTML is really just the data output by your program. And separation of program and data was a good idea long before the likes of Fowler were casting pearls before us swine. If you have complex data model or controller logic which oftens happens on large projects then treating PHP as a programming language might make sense.

But ultimately the question of whether to use PHP as a templating language or a programming language has a lot more to do with your style and approach to development. You will find the OO folks go more in the PHP as a programming language direction. The templaters tend to be ok with more procedural because the template itself becomes an object.

The bottom line for me is that good code in either style is equally easily supportable. Poor code or mixed code by a team that could not agree on which direction to go is a pain.
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

I have some work to do on this forum on the bb tags. The code is appalling. Almost no concept whatsoever of design by which I mean parcelling up different responsibilities into discrete chunks. Globals everywhere. It is to my mind near impossible to test or maintain (this must contribute significantly to vulnerabilites like XSS holes and the recent nosanity virus). If you mix everything up together you (or whoever has to pick up the mess you made) will suffer for it.

Anyway, BB code is presentation. Encoded text needs to be formatted with (in this case) html before output. That involves some logic to match tags, deal with badly-formed tags and of course checking for any nasties. I'm not sure the distinction you're making between a "programming language" and a "templating language". Php in templates is fine by me - as long as it's dealing with presentation.

The best system IMO is to use custom tags like Smarty or Wact, then "compile" run-time templates where the tags are replaced with blocks of php code. That way designers can work away in WYSIWYG editors and pages can be served up efficiently.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

I think the distinction between a "programming language" and a "templating language" is that a programming language stores "data" in variables, whereas a scripting embeds code with the "data."

My point was that PHP can be used for both of these, confusingly producing the same output with very different implementations. Or they can be used in conjuction. Subjects like "layering" have different meanings in scripting context than a programming context and vice versa.
User avatar
neophyte
DevNet Resident
Posts: 1537
Joined: Tue Jan 20, 2004 4:58 pm
Location: Minnesota

Post by neophyte »

If you are building a site that really only needs templates because it does not have very complex data model or controller logic, then using PHP as a template language is great.
PHP is great at being able to build dynamic content quickly and efficiently if you don't really need complexity. However, it doesn't take long to become really frustrating with all that html entertwined with your code and logic. So I guess it depends on the complexity of your project/client needs on which you use. Do you think larger projects like osCommerce/Moodle are hurt because they don't use templates? Smarty is huge, and Prado is even larger. There almost like translators for translators, machine for machines. I haven't used smarty yet but I'm thinking I might try it.
printf
Forum Contributor
Posts: 173
Joined: Wed Jan 12, 2005 5:24 pm

Post by printf »

Just my thoughts...

PHP is the best template engine, (period). If you need to use a template engine then your logic is missing from your code! Why I say this, because using a template engine you will limit your coding scope to only include code that your template engine can handle! Now some will say that is not always the case, but then you will probably be like the rest who think eval() is the answer the answer to that problem! Just remember this, the core PHP engine can move in and out of PHP blocks faster then any str_ or preg_ function you have created for your template engine!

I know when I when I was just learning PHP, I asked a lot questions when doing PHP work shops, and I always found the core PHP developers saying the same thing. "If you think templates are the answer, then your asking the wrong question, this goes for eval() too!". Using an array(); to hold your $var(s) during the script process, and then dumping them to include file, that PHP will fill, is better than anything you can do in scripting!


printf
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

the major reason I'm against PHP being used as the template is that it then requires a programmer to create the pages. Since programmers can easily cost a lot to a company, having the ability for a web designer to come in and create the templates is very beneficial.

Having a programmer do the front end and back end programming is wasteful at best.

On a small project, where you, the programmer, are the only person or group maintaining everything, using php to template is fine (if everyone speaks that language). However, if the project is expected (in any amount) to grow beyond programmers then you should seriously consider full seperation so the differing parties can work without screwing up each other's work.
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

Aborint hit it on the head when he said that PHP can be either templating or programming language. PHP itself was conceived as a templating language but has come a far way since then. The powerful OO capabilities of PHP5 show that the direction it has taken is definitely towards a programming language.

The problem with most open source PHP projects is that they are very, very, very badly coded (as McG has stated). There is no clear seperation between logic and content, the programmers have created interacting pages rather than an application as such. That will work for a while, but the most important phase for any project is the beginning. If you don't start it right, you will have to face many problems ensuing from your initial errors.

Using a templating language can help tremendously to help you start thinking about logic an presentation. Once you have done that, another good way of learning about the seperation of different application layers is the Model View Controller Patterns (MVC):

http://www.phppatterns.com/index.php/ar ... leview/11/
http://www.phppatterns.com/index.php/ar ... ew/19/1/1/
and
http://www.phparch.com/sample.php?mid=10 (download the PDF)

Imho: nobody needs another baldy coded open source forum, another badly coded online shop, another badly coded (insert application here). It's pointless as we have seen on many, many instances where OS projects were started with lots of enthusiasm, but little knowledge of application design. At some point they hit a brick wall and pretty much died (like OsCommerce, phpBB, ZenCart will follow suit, etc. etc.).
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

I agree with PatrickG with one addition. He says:
The problem with most open source PHP projects is that they are very, very, very badly coded.
But he misses the filp side that is the power of scripting languages. Most of those open source PHP projects would not exist unless they were very, very, very badly coded.

The key here is that "very, very, very badly coded" is the subjective judgement of some programmers. They will never accept that scripting languages evolved as a reaction to "coding well" for the simple reason that "coding well" is one of the major impediments to, of all things, CODING.

The fact that so many very, very, very bad programmers produce so much very, very, very bad code that is so very, very, very useful is just, just .... infuriating to them. Why? Because they have elevated programming above what it is: a medium to turn ideas into programs.

Christopher
Post Reply