Page 3 of 3

Re: Thoughts on Templates

Posted: Wed Jun 11, 2008 6:02 pm
by Christopher
First I wanted to address Mordreds three points:
Mordred wrote:Some problems are:
1. One must "manually" loop the loops and enumerate the vars to be replaced
2. Runtime string replacement is ... slow.
3. The template snippets are separated (assuming you'll read them from file or something), which, if one wants to change something, make it hard to identify in which piece a particular string resides.
#1 can be dealt with if the template library has a call that will loop for you.
#2 is not necessarily true. Reading a template and doing str_replace() is not that slow compared to include().
#3 can be dealt with by having blocks in the template.
Everah wrote:Why would you want to add the extra processing logic of assigning/replacing variables/values? I thought, for a while, that a template engine was THE thing to do to separate business logic and presentation logic. I was totally wrong.
My argument with this statement, which I agree with, is the idea the the template engine is the View. I think the template engine is sometimes the whole View, but the View can also simply use a template engine for part of its work.

The main place I do not use PHP templates is when an untrusted user can edit the content.

In general I don't think that there is one best solution for templating. Not for a whole site -- not even for a single page. I think you should be able to mix template engines within a single page as appropriate.

Re: Thoughts on Templates

Posted: Thu Jun 12, 2008 4:00 am
by dbevfat
matthijs wrote:Person A want to "completely remove php from his templates" because his situation dictates that (he doesn't trust his template guys with php maybe).
I think this is a poor argument in favor of templates. It's the most often given one, but it lacks credibility. Not trusting the team you work with is something that should be dealt with on a different level. Where is the reason the hypothetical guy doesn't trust the templaters? Lack of their skill? Perhaps they need to be educated more. They have to know their limits and boundaries, just as programmers must. You, as a coder, know perfectly well that you shouldn't put exec('rm -Rf /') in your code, but nobody is physically preventing you to do it.

Now, if you have some mean designers that just wait to code something harmful, it's a different story. In this case, the designers have to be replaced as soon as possible, because they will find a way to do harm, one way or another.
matthijs wrote:Person B just wants to separate the layers so that maintainability is maximized (he wants to be able to easily change a template without diving too deep in the back-end code).
etc
This should also be Person A's goal, ideally.

All in all, templating engines always start out lightweight, but have to extended to fulfill certain needs. Echoing and loops are soon not sufficient, so you get functions, then parametrized functions, object support and whatnot. Not rarely the templates also support PHP directly, which is just silly and undermines their own existence. The templating language capabilities approach that of PHP, only with a different syntax, which is often ugly. In Smarty, for example, the syntax for parametrized functions is just awful. At some point, the template engine will be a bloated retarded little brother of PHP, and designers will have to learn it. But, if they can learn that, surely they could learn PHP?

To protect the template engines from becoming a language of its own, developer often refuse to expand the templating language. Echos and loops, that's all you get. But all you've done now is move the data preparation logic to php, which results in a major drawback: the programers have to deal with content output (ie. they have to call uppercases, uc_words, number formattings, ...), which bloats their code, that should be more or less business-oriented. So the view part splits into two separate parts: the PHP view and HTML (template) view. And suddenly the designers can't do sh*t without the programmers!

I've been using templates for years, and I'm really really glad I've listened to some people and went back to PHP. :)

Best regards

Re: Thoughts on Templates

Posted: Thu Jun 12, 2008 5:27 am
by Mordred
matthijs wrote:If you need
Mordred wrote:Does the job. Short. Easy to read. Easy to maintain. Steals from the rich and gives to the poor.
you can indeed look at some of the available template languages. But you can also use PHP, but then just use a limited amount or a specific set of variables/logic.
Ah, you misread me. I need that, so that's why I developed it. The examples posted before are not mockups, but real samples.
matthijs wrote: Take a look at some of the blogging tools/cmses, for example wordpress. It's pure PHP in the templates, but it's not too difficult. Even noobs who build their first site can get it done with the help of the manual.

The argument that the template builders (designers?) are not able to deal with those few lines of PHP in the templates is an argument I don't accept. If you're smart enough to write accessible HTML, deal with all those IE bugs and get your site working cross-browser, you are smart enough to understand those few snippets of code between <? and ?> tags :)
Eew, wordpress themes. My hairs stand on the back of my neck every time I see one (and let's not start about the security implications, it's just staggering). I don't think it's a successful example of doing things right, even if there are hundreds of people who happily hack at it. They do so because the platform is popular, not because it's easy. Also check this recent posting here: viewtopic.php?f=6&t=83997. Biggest market share != themes are easy to mod.
arborint wrote:First I wanted to address Mordreds three points:
Mordred wrote:Some problems are:
1. One must "manually" loop the loops and enumerate the vars to be replaced
2. Runtime string replacement is ... slow.
3. The template snippets are separated (assuming you'll read them from file or something), which, if one wants to change something, make it hard to identify in which piece a particular string resides.
#1 can be dealt with if the template library has a call that will loop for you.
#2 is not necessarily true. Reading a template and doing str_replace() is not that slow compared to include().
#3 can be dealt with by having blocks in the template.
This was a reply specifically to mpetrovich's post, I enumerated some problems in his implementation, not template engines in general.
arborint wrote:My argument with this statement, which I agree with, is the idea the the template engine is the View. I think the template engine is sometimes the whole View, but the View can also simply use a template engine for part of its work.
I lean towards the latter, but only since I use a PHP+template combo. Everah demonstrated an OOP PHP-only template that just works standalone.
arborint wrote:The main place I do not use PHP templates is when an untrusted user can edit the content.
+1024 on that!

@dbevfat
I understand your sentiments, but there are other cases where the developer needs you think are wrong are in fact right.
1. Not trusting the template writer is a natural thing when he is not a part of the team that builds a monolithic site, but is a 3rd party modder who customizes - say - blog themes. See my above comments on wordpress.
debfat wrote:All in all, templating engines always start out lightweight, but have to extended to fulfill certain needs. Echoing and loops are soon not sufficient, so you get functions, then parametrized functions, object support and whatnot. Not rarely the templates also support PHP directly, which is just silly and undermines their own existence. The templating language capabilities approach that of PHP, only with a different syntax, which is often ugly. In Smarty, for example, the syntax for parametrized functions is just awful. At some point, the template engine will be a bloated retarded little brother of PHP, and designers will have to learn it. But, if they can learn that, surely they could learn PHP?
I totally agree, and so I did what you argue against in your next paragraph:
debfat wrote:To protect the template engines from becoming a language of its own, developer often refuse to expand the templating language. Echos and loops, that's all you get. But all you've done now is move the data preparation logic to php, which results in a major drawback: the programers have to deal with content output (ie. they have to call uppercases, uc_words, number formattings, ...), which bloats their code, that should be more or less business-oriented.
... which I disagree with.
The point of limiting my template language (can't talk for the others) is that this is the point where usability and simplicity meet. It also covers more than 90% cases (actually in my usage, I could only think of only one instance when I had to format the output on the PHP side). What's more, my API on the PHP side also allows short and meaningful expressions, so the overall result is even shorter. You are invited to write out the example in the previous pages in your style, so we can compare.
I also disagree that the designer/template writer should have controll over things like uppercase and number formatting. This is view/business logic, in the sense that it is tightly coupled with the domain of the business object. As such it belongs on the "code" side of the view.

Re: Thoughts on Templates

Posted: Thu Jun 12, 2008 6:22 am
by matthijs
You have a large post, too much to respond to, but I'd like to know
mordred wrote:Eew, wordpress themes. My hairs stand on the back of my neck every time I see one (and let's not start about the security implications, it's just staggering). I don't think it's a successful example of doing things right, even if there are hundreds of people who happily hack at it. They do so because the platform is popular, not because it's easy.
if you could point out shortly what it is that's you think is so bad?

I can say what I do like about the way wordpress handles templates:
- use of simple functions to output stuff: the_title(), the_author(), etc. I think that style is pretty easy to use and comprehend.
- the fact that if I have to, I can use plain php somewhere. Say I want to display the date in the footer copyright notice, but don't want to hardcode it as a number. Now if there's no function for that in the system, I can just echo out the date('Y') or something.

I do agree that overall, it's a bit messy in the wordpress templates, that's also because things have changed around a lot with updated versions. Functions have been deprecated etc. But I think the details are not important in this discussion.

Again, as I said in my earlier post, this kind of template system works well for my situation, for some of my projects. Maybe it doesn't work at all for someone else, in another situation.

Re: Thoughts on Templates

Posted: Thu Jun 12, 2008 6:26 am
by Eran
Wordpress code is terrible... it is entirely procedural (they make use of classes... not in an OO way though) and if you try to follow the functions hierarchy you always end up at magical _filter methods that are very hard to understand or modify. Use of globals is rampant in the system, variables get lost of modified without warning... it's a mess. Not to mention it's mostly PHP4 code conventions (and throws strict warnings in PHP5)

Re: Thoughts on Templates

Posted: Thu Jun 12, 2008 6:53 am
by dbevfat
Mordred wrote:1. Not trusting the template writer is a natural thing when he is not a part of the team that builds a monolithic site, but is a 3rd party modder who customizes - say - blog themes. See my above comments on wordpress.
I don't think there even is a "trust issue". Only because you develop an open platform that is extendable to some degree, doesn't mean you're responsible for the extensions, unless you willingly take the responsibility (ie. via your license). Usually with open source, the end users are responsible for the extensions they install on top of your application, just as they are responsible for installing your application in the first place. If they lose data using your open-source application, you don't take responsibility, do you? Then why should you do so for extensions that you never even knew about?

Things can change if you release the project under a license where the responsibility is yours (and where you, of course, get paid for the product). Now you take some responsibility for your application. And if you still allow external developers to extend it, and you provide official support for these mods, and also state that you take responsibility for those, then you have a point about limiting the template engine. But unless you do so, it's just not your responsibility. But even if you limit the template engine, you'll have to review the templates before you take responsibility for them, because limiting the template engine most likely isn't a secure enough measure by itself. People that will go that far to do harm, will find a way. So you might as well leave PHP in it, it will also give you less work for template review.

IMO, securing the template (in terms of limiting the capabilities of the templaters) is a non-issue, however you turn it.

Best regards

Re: Thoughts on Templates

Posted: Thu Jun 12, 2008 7:23 am
by mpetrovich
OK, so you are getting practical.

For Websites templates, I acutally do use static templates with markup, and replace into the templates. Within the content, I just use standard PHP and embed, or in some cases the entire content section could be PHP. That does not bother me. If I have a login button, I'll just replace it with log-out code where necessary.

Generally, I start with a site mock-up, and then the next step is to develop a template. Now that could come from a designer. What I want to be able to do is get the template working, preview my template and make sure I am fully W3C compliant (not just a good idea, but also lets me know if I have any errors). Once I have that, I start building the content files. I do not use any templating there. So, I do not worry about loops and conditionals -- PHP does a fine job.

I have done this, this way, for the past couple years, and it seems to work well. I like the fact I can change two files: the template file, and the CSS file, and the site will look entirely different. I also create a print template, that removes all the graphics and menus. It is a clean system.

The other place where I have used markup templates is in email templates for newsletters, where the templates are stored in a database, and can be selected for a particular email. Now, I used to use an unmentioned open-source mailing list system, and they used header code, footer code and some mark-up within the content. I can tell you that is a lot more confusing and more difficult to manage.

At the element level, the one place I use a mini-mark-up template is in my form-handling routines. I have code that generates forms from an array of items. Well, the format for each element in the form is generated from a small one-line template. I could within my code, change the template and go from a "divs" form, to a table-based form, if I really wanted to. It's just a flexible way to do this.

What prompted me to start this thread, was some recent work with some open source applications, and tweaking some theme stuff. That is where I wanted to minimize the spaghetti templating -- HTML scattered throughout several files. Maybe I am just spoiled normally being able to look a single page, and tweaking the style and layout.

We as programmers generally want a system that is easy to code, easy to trouble shoot, easy to modify, minimizes the burden on the system, and is secure. If we can improve any of those categories, we're there. How and where to use templates effectively will probably change over time.

Today, everyone is talking about MVC, although I find in practice it usually is not that clean of a separation. Now you are hearing talk about unobtusive Javascipt, where you strip the Javascript out of the HTML documents. Where will it go next? Maybe future PHP versions will have template functions built in? I do think it is important to keep in mind how the HTML and styles are being managed, and how to do this cleanly. With CSS we can separate the style, how much can we separate the structure, and how much should we?

Re: Thoughts on Templates

Posted: Thu Jun 12, 2008 7:32 am
by superdezign
mpetrovich wrote:Maybe future PHP versions will have template functions built in?
No more so than it already does. PHP isn't a framework, it's a language.
mpetrovich wrote:I do think it is important to keep in mind how the HTML and styles are being managed, and how to do this cleanly. With CSS we can separate the style, how much can we separate the structure, and how much should we?
That's always been an issue since CSS was developed, and it definitely applies here, with templates. Regardless of how much we try to separate form from function, the form is based off of the function and vice versa. The data has to be displayed a certain way in a certain order. But the display has to be aware of exactly what data will be displayed, how that data will be passed on to the display, and the structure of the data. Similar to how HTML elements still have to be arranged in certain ways for CSS to display it the way that we want it to, template data must be passed a certain way.

Re: Thoughts on Templates

Posted: Thu Jun 12, 2008 7:37 am
by matthijs
@pytrin: I know that wordpress code is horrible. But that's not the discussion here I think. My main question is about it's template system (in general). I do like many aspects of that system. As a front-end developer I can take my pure HTML templates, put them in a theme folder and replace the dynamic data bits with easy-enough to use functions. If I have multiple templates (say the home page and an article page) which use the same header and footer sections, I can just extract those, put them in template files called "header.php" and "footer.php", include them from the templates using them (home.php and article.php) and that's it. It's all there, in one folder. Every bit of HTML is controlled by me as the front-end guy.

I've seen many other template systems in cmses but often they are more complicated or very restrictive.

Re: Thoughts on Templates

Posted: Thu Jun 12, 2008 7:55 am
by Eran
Yes, I agree - from a templating point of view wordpress does pretty well. Unless of course you want to retrieve data that isn't obvious, but that is not related to the actual templating.

Also regarding what mpetrovich said - in order to reuse components of the design, you have to break down an html page into several files, no way around it. Unless you want to copy-paste your repeating elements into every page and then you have a maintenance nightmare.

Re: Thoughts on Templates

Posted: Thu Jun 12, 2008 8:22 am
by matthijs
Indeed. I think there are a few things:
- how the templates are organized in general. In other words, is everything in one place, logically placed in the files, etc? The worst systems are when some parts are plain html files, other parts are in php files, again other parts are hidden somewhere else, and finally some other stuff is hidden deep down in the system. Or systems in which you first have to go deep into the system through several loops of creating blocks, modules, forms, components, pages, styles, assign everything to everything else, and then somehow magically hope everything fits together at the front end viewing your site :roll:
- how the data is pulled into the templates. That should be as simple and "flat" as possible. What brackets you use exactly depends on the situation and what you like.