4 ms·

PHP "can be" used as a templating engine, but its not the right way to do it nor do you have to use it in that manner. The correct way is to use Twig for your

by throwaway1974 10y ago

PHP "can be" used as a templating engine, but its not the right way to do it nor do you have to use it in that manner. The correct way is to use Twig for your templates PHP is alot more than a "templating engine" if thats all you think of it then that is your choice

TeMPOraL 10y ago
Template engines are one of the more ridiculous inventions on the web, if you think of it. Doubly so if you have them in PHP, which is a perfectly good template engine - sure the syntax could be better, but the popular templating engines are even worse at any but most trivial tasks. They all start as an attempt to remove the possibility of writing meaningful code in them[0], and then grow cruft until they become Turing-complete due to the needs. The more stupid thing about them, which transcends PHP and touches all other programming languages, is the very idea of assembling HTML piecemal from unstructured text. HTML is a textual representation of a tree, and should always be constructed as such - and not by gluing strings together. It's kind of the same problem as with SQL injections, which would not be possible in the first place if people weren't gluing them together from strings. I'll probably get flamed for saying that, but really - many of the popular tools on the web are broken on a fundamental, conceptual level. [0] - because of a misunderstanding of the "don't write logic in your views" principle; sure, don't write business logic in your views, but that doesn't mean you don't need, or shouldn't use, a real programming language in your views.
- stephenr 10y ago
  Couldn't agree more. I've had decent success using an xml-object based approach, so certain structured parts of the template (navigation, form controls, etc) are built programmatically using dom methods and then serialised into the template.
- codedokode 10y ago
  PHP actually is a bad templating engine for HTML because it doesn't have a feature to convert special characters to HTML entities by default. It is easy to forget a call to htmlspecialchars() (especially for beginners) so the code gets vulnerable to XSS. That is why you should prefer Twig or other templating engine with autoescaping. > They all start as an attempt to remove the possibility of writing meaningful code I don't think so. Twig developers have a large list of reasons on their frontpage: http://twig.sensiolabs.org/ http://twig.sensiolabs.org/
  - megous 10y ago
    Not much difference: <?= escape($var) ?> {{ var | escape }} Nevertheless, I used DOM/libxml on the server side in PHP/C, since 10 years ago, and was happy about it. It avoids all the other the template issues (balancing open/close tags, etc.) very well. A few helper functions and you're good to go, with simplicity, flexibility and speed you will not get from any templating library in PHP. Though, some coding customers don't know what to make of it. Some people have trouble with not being able to see HTML in the code, because "where do I paste my Google Analytics code?".
    - codedokode 10y ago
      Twig does not require you to write escape so you can have to write just {{ var }} That is a big difference because beginners always forget about escaping. > Nevertheless, I used DOM/libxml on the server side in PHP/C, There used to be XSLT templates but they don't seem to be popular now. Constructing DOM trees in the code without using templates is probably inconvinient and produces bloated code.
      - megous 10y ago
        Not that much bloated. And it can be quite readable if done well. You also don't need to learn peculiarities of for loops or macro language in a given templating system. The host language is it's own macro language with all the features you already know, and not limited to whatever template language authors decided to implement. Beginners also forget about balancing HTML tags, which is quite unpleasant experience when creating and changing more complicated templates with loops, conditions, etc. You can also do post-processing on the constructed DOM, even during construction. Bloated code only happens if the programmer fails to structure the code into nicely re-usable functions. Anyway, it seems to be quite popular right now with all the react hype - React.createElement is such a helper function to help construct DOM tree. It's pretty much the same concept on the server side. Except you don't need to care about DOM diffing, because server has no persistent DOM.

TeMPOraL 10y ago

Template engines are one of the more ridiculous inventions on the web, if you think of it. Doubly so if you have them in PHP, which is a perfectly good template engine - sure the syntax could be better, but the popular templating engines are even worse at any but most trivial tasks. They all start as an attempt to remove the possibility of writing meaningful code in them[0], and then grow cruft until they become Turing-complete due to the needs. The more stupid thing about them, which transcends PHP and touches all other programming languages, is the very idea of assembling HTML piecemal from unstructured text. HTML is a textual representation of a tree, and should always be constructed as such - and not by gluing strings together. It's kind of the same problem as with SQL injections, which would not be possible in the first place if people weren't gluing them together from strings. I'll probably get flamed for saying that, but really - many of the popular tools on the web are broken on a fundamental, conceptual level. [0] - because of a misunderstanding of the "don't write logic in your views" principle; sure, don't write business logic in your views, but that doesn't mean you don't need, or shouldn't use, a real programming language in your views.

stephenr 10y ago
Couldn't agree more. I've had decent success using an xml-object based approach, so certain structured parts of the template (navigation, form controls, etc) are built programmatically using dom methods and then serialised into the template.
codedokode 10y ago
PHP actually is a bad templating engine for HTML because it doesn't have a feature to convert special characters to HTML entities by default. It is easy to forget a call to htmlspecialchars() (especially for beginners) so the code gets vulnerable to XSS. That is why you should prefer Twig or other templating engine with autoescaping. > They all start as an attempt to remove the possibility of writing meaningful code I don't think so. Twig developers have a large list of reasons on their frontpage: http://twig.sensiolabs.org/ http://twig.sensiolabs.org/
- megous 10y ago
  Not much difference: <?= escape($var) ?> {{ var | escape }} Nevertheless, I used DOM/libxml on the server side in PHP/C, since 10 years ago, and was happy about it. It avoids all the other the template issues (balancing open/close tags, etc.) very well. A few helper functions and you're good to go, with simplicity, flexibility and speed you will not get from any templating library in PHP. Though, some coding customers don't know what to make of it. Some people have trouble with not being able to see HTML in the code, because "where do I paste my Google Analytics code?".
  - codedokode 10y ago
    Twig does not require you to write escape so you can have to write just {{ var }} That is a big difference because beginners always forget about escaping. > Nevertheless, I used DOM/libxml on the server side in PHP/C, There used to be XSLT templates but they don't seem to be popular now. Constructing DOM trees in the code without using templates is probably inconvinient and produces bloated code.
    - megous 10y ago
      Not that much bloated. And it can be quite readable if done well. You also don't need to learn peculiarities of for loops or macro language in a given templating system. The host language is it's own macro language with all the features you already know, and not limited to whatever template language authors decided to implement. Beginners also forget about balancing HTML tags, which is quite unpleasant experience when creating and changing more complicated templates with loops, conditions, etc. You can also do post-processing on the constructed DOM, even during construction. Bloated code only happens if the programmer fails to structure the code into nicely re-usable functions. Anyway, it seems to be quite popular right now with all the react hype - React.createElement is such a helper function to help construct DOM tree. It's pretty much the same concept on the server side. Except you don't need to care about DOM diffing, because server has no persistent DOM.