5 ms·

I do not feel that it is fair to dismiss php as merely a "template engine". It probably outgrew such a small scope of use around 3x. On a more philosophical lev

I do not feel that it is fair to dismiss php as merely a "template engine". It probably outgrew such a small scope of use around 3x. On a more philosophical level: the reason programmers long to create/control/extend the platform on which they exist is because they are programmers. I think once you reach this point you should go for it but also be prepared to move onto a programmable programming language.

randallsquared 17y ago
I have a different complaint: I think it makes sense to have a template system for PHP because PHP is such a poor template system. :)
- cousin_it 17y ago
  I generally like PHP but am not a very advanced user, so I'm interested: what shortcomings do you see?
  - eru 17y ago
    http://www.google.com/search?q=php+shortcomings http://www.google.com/search?q=php+shortcomings
    - cousin_it 17y ago
      eru, your answer is too generic - I could have googled that myself. I'm interested specifically in the shortcomings of PHP as a templating system.
      - eru 17y ago
        OK. E.g. PHP does not check whether your templates are valid HTML (or even just half-way sane tag soup) at all. And you need to put a $ in front of every variable. Seems like someone did not know how to write a parser..
        cousin_it 17y ago
        Do other template engines, e.g. Smarty, check HTML validity? I tried looking at the docs and it wasn't apparent.
        eru 17y ago
        I would guess the PLT webserver can do so. At least it will statically avoid unclosed tags, since it's based on s-expressions. http://docs.plt-scheme.org/web-server/run_ss.html#%28part._insta%29 http://docs.plt-scheme.org/web-server/run_ss.html#%28part._i...
        cousin_it 17y ago
        Now go to google.com and view source, you'll see it couldn't have been output by the PLT webserver. :-)
        eru 17y ago
        Yes. However they optimize for speed and have the resources to test their pages in every browser.
  - randallsquared 17y ago
    There are two major problems for me: one is that markup filled with "<?=$varname;?>" is harder to parse than markup filled with "{varname}"; for a designer, those extra characters are totally extraneous, and they're not even balanced the way all other kinds of special markup are in HTML or XML. Secondly, there's nothing in PHP that guides one away from packing more and more functionality into the template instead of the template's caller; it's easy to find snippets of PHP that do something "cool" online, and it's hard to explain to your designer why they shouldn't use them. So, too verbose and less maintainable, is what it boils down to.
    - cousin_it 17y ago
      Thanks! I won't start using Smarty because of that, but those sound like valid reasons for bigger projects.
    - jbm 17y ago
      I'm not sure why you believe that it is necessary to do stuff like <?=$varname;?>. Certainly, a competent PHP programmer can use file operations and str_replace to do templating; it's pretty much what I do right now. The template for a dog-related site I'm working on looks like this: <div class="dog" id="dog_{{__id__}}"> <h1 class="name">{{__name__}}</h1> <p class="sex">{{__sex__}}</p> <p class="breed">{{__breed__}}</p> <p class="images">{{__pictures__}}</p> <div class="description">{{__description__}}</div> </div> (The formatting appears to be lost; accept my apologies) That said, I am also working on fixing a restaurant site that a friend programmed, and it is littered with the type of disgusting syntax you mention. It's the difference between a designer who does snippets of PHP and a programmer.
      - randallsquared 17y ago
        You're not arguing against me, but with me. ;) The article suggested that it was obviously a bad idea to write a templating engine in PHP, since PHP is already in the category of "templating engine". As you point out, it's easy to implement a template system in PHP that's better to use than raw PHP would be.
hellotoby 17y ago
I read it as referring to a templating engine such as Smarty (for PHP). I've never really understood the need to abstract things in this way even for novice front-end developers since it's the concept that is important not the syntax. e.g. I don't see any real difference in using a) <?php foreach($key as $val): ?> or b) {foreach from=$myArray item=foo} To me the Smarty abstraction is pointless.
- jquery 17y ago
  As a highly satisfied user of the smarty templating system, I want to refer you to this (from http://www.smarty.net/whyuse.php http://www.smarty.net/whyuse.php): ) Designers can't break application code. They can mess with the templates all they want, but the code stays intact. The code will be tighter, more secure and easier to maintain. ) Errors in the templates are confined to the Smartys error handling routines, making them as simple and intuitive as possible for the designer. ) With presentation on its own layer, designers can modify or completely redesign it from scratch, all without intervention from the programmer. ) Programmers aren't messing with templates. They can go about maintaining the application code, changing the way content is acquired, making new business rules, etc. without disturbing the presentation layer. ) Templates are a close representation of what the final output will be, which is an intuitive approach. Designers don't care how the content got to the template. If you have extraneous data in the template such as an SQL statement, this opens the risk of breaking application code by accidental deletion or alteration by the designer. ) You are not opening your server to the execution of arbitrary PHP code. Smarty has many security features built in so designers won't breach security, whether intentional or accidental. They can only do what they are confined to in the templates.
  - derefr 17y ago
    When you end up with flow-control, and other such complicated constructs, inside your templates, either the designers are already smart enough to "modify or completely redesign it from scratch, all without intervention from the programmer", or the programmer will need to be "messing with templates" anyway, to help the designers fix their logic errors, which no amount of abstraction will help overcome. The problems solved by Smarty could be solved simply with a single try-catch block around the rendering-kickoff logic (that forwards to a nice 500 error page if something happens), and a convention to not do any business-layer stuff within the templates. [Also, source control + a dev/testing server to deploy on so "break[ing] application code" isn't a concern, but this should really, really not need to be mentioned.] This is exactly what I've done on any [non-framework] PHP project I've touched, and no one has ever complained that it was hard to edit the views.
stcredzero 17y ago
I think once you reach this point you should go for it but also be prepared to move onto a programmable programming language. There are large numbers of programmers who have moved on to "programmable" programming languages. (Languages where meta-programming is comfortable and very useful.) It's no longer a fringe thing. Either you use this wording tongue-in-cheek, or you haven't gotten that far yet.

randallsquared 17y ago

I have a different complaint: I think it makes sense to have a template system for PHP because PHP is such a poor template system. :)

cousin_it 17y ago
I generally like PHP but am not a very advanced user, so I'm interested: what shortcomings do you see?
- eru 17y ago
  http://www.google.com/search?q=php+shortcomings http://www.google.com/search?q=php+shortcomings
  - cousin_it 17y ago
    eru, your answer is too generic - I could have googled that myself. I'm interested specifically in the shortcomings of PHP as a templating system.
    - eru 17y ago
      OK. E.g. PHP does not check whether your templates are valid HTML (or even just half-way sane tag soup) at all. And you need to put a $ in front of every variable. Seems like someone did not know how to write a parser..
      - cousin_it 17y ago
        Do other template engines, e.g. Smarty, check HTML validity? I tried looking at the docs and it wasn't apparent.
        eru 17y ago
        I would guess the PLT webserver can do so. At least it will statically avoid unclosed tags, since it's based on s-expressions. http://docs.plt-scheme.org/web-server/run_ss.html#%28part._insta%29 http://docs.plt-scheme.org/web-server/run_ss.html#%28part._i...
        cousin_it 17y ago
        Now go to google.com and view source, you'll see it couldn't have been output by the PLT webserver. :-)
        eru 17y ago
        Yes. However they optimize for speed and have the resources to test their pages in every browser.
- randallsquared 17y ago
  There are two major problems for me: one is that markup filled with "<?=$varname;?>" is harder to parse than markup filled with "{varname}"; for a designer, those extra characters are totally extraneous, and they're not even balanced the way all other kinds of special markup are in HTML or XML. Secondly, there's nothing in PHP that guides one away from packing more and more functionality into the template instead of the template's caller; it's easy to find snippets of PHP that do something "cool" online, and it's hard to explain to your designer why they shouldn't use them. So, too verbose and less maintainable, is what it boils down to.
  - cousin_it 17y ago
    Thanks! I won't start using Smarty because of that, but those sound like valid reasons for bigger projects.
  - jbm 17y ago
    I'm not sure why you believe that it is necessary to do stuff like <?=$varname;?>. Certainly, a competent PHP programmer can use file operations and str_replace to do templating; it's pretty much what I do right now. The template for a dog-related site I'm working on looks like this: <div class="dog" id="dog_{{__id__}}"> <h1 class="name">{{__name__}}</h1> <p class="sex">{{__sex__}}</p> <p class="breed">{{__breed__}}</p> <p class="images">{{__pictures__}}</p> <div class="description">{{__description__}}</div> </div> (The formatting appears to be lost; accept my apologies) That said, I am also working on fixing a restaurant site that a friend programmed, and it is littered with the type of disgusting syntax you mention. It's the difference between a designer who does snippets of PHP and a programmer.
    - randallsquared 17y ago
      You're not arguing against me, but with me. ;) The article suggested that it was obviously a bad idea to write a templating engine in PHP, since PHP is already in the category of "templating engine". As you point out, it's easy to implement a template system in PHP that's better to use than raw PHP would be.

hellotoby 17y ago

I read it as referring to a templating engine such as Smarty (for PHP). I've never really understood the need to abstract things in this way even for novice front-end developers since it's the concept that is important not the syntax. e.g. I don't see any real difference in using a) <?php foreach($key as $val): ?> or b) {foreach from=$myArray item=foo} To me the Smarty abstraction is pointless.

jquery 17y ago
As a highly satisfied user of the smarty templating system, I want to refer you to this (from http://www.smarty.net/whyuse.php http://www.smarty.net/whyuse.php): ) Designers can't break application code. They can mess with the templates all they want, but the code stays intact. The code will be tighter, more secure and easier to maintain. ) Errors in the templates are confined to the Smartys error handling routines, making them as simple and intuitive as possible for the designer. ) With presentation on its own layer, designers can modify or completely redesign it from scratch, all without intervention from the programmer. ) Programmers aren't messing with templates. They can go about maintaining the application code, changing the way content is acquired, making new business rules, etc. without disturbing the presentation layer. ) Templates are a close representation of what the final output will be, which is an intuitive approach. Designers don't care how the content got to the template. If you have extraneous data in the template such as an SQL statement, this opens the risk of breaking application code by accidental deletion or alteration by the designer. ) You are not opening your server to the execution of arbitrary PHP code. Smarty has many security features built in so designers won't breach security, whether intentional or accidental. They can only do what they are confined to in the templates.
- derefr 17y ago
  When you end up with flow-control, and other such complicated constructs, inside your templates, either the designers are already smart enough to "modify or completely redesign it from scratch, all without intervention from the programmer", or the programmer will need to be "messing with templates" anyway, to help the designers fix their logic errors, which no amount of abstraction will help overcome. The problems solved by Smarty could be solved simply with a single try-catch block around the rendering-kickoff logic (that forwards to a nice 500 error page if something happens), and a convention to not do any business-layer stuff within the templates. [Also, source control + a dev/testing server to deploy on so "break[ing] application code" isn't a concern, but this should really, really not need to be mentioned.] This is exactly what I've done on any [non-framework] PHP project I've touched, and no one has ever complained that it was hard to edit the views.

stcredzero 17y ago

I think once you reach this point you should go for it but also be prepared to move onto a programmable programming language. There are large numbers of programmers who have moved on to "programmable" programming languages. (Languages where meta-programming is comfortable and very useful.) It's no longer a fringe thing. Either you use this wording tongue-in-cheek, or you haven't gotten that far yet.