| 2:06 pm on Apr 25, 2008 (gmt 0)|
I'm not an expert, but as I understand it, there wouldn't be much processing overhead in turning on and off the PHP processing of the output stream. On the other hand, that code is a lot harder to read; you might find yourself wasting a lot more time in the debugging stage.
| 2:45 pm on Apr 25, 2008 (gmt 0)|
Yeah, I figure that the specific example I gave would be pretty hard to debug.
The sort of context that I had envisioned was one where you have quite a large chunk of (predominantly) HTML code that needs to be repeated. Instead of having to
print out heaps of HTML, you can let it just display.
I don't think this explanation is coming across as much as I like it. It makes sense in my head ^_^
| 6:05 pm on Apr 25, 2008 (gmt 0)|
I think I know what you are wanting to accomplish, I do this often, create all the values I will need before the HTML and use <?php echo $val; ?> all over the HTML part of the page and if its data coming from a db just add <?php mysql_close($dblink); ?> at the foot of the page
| 8:40 am on Apr 26, 2008 (gmt 0)|
Yeah, something like that. Oh, and nobody would by any chance know whether the shorthand way of printing out vars (
<?= $myVar ?>) works with the php.ini value
I thought that
<?php= $myVar ?> could work, but alas, it did not... :(
| 12:27 pm on Apr 26, 2008 (gmt 0)|
you could also look at this thread
Benchmarking PHP text output [webmasterworld.com]
| 12:35 pm on Apr 26, 2008 (gmt 0)|
It is my belief that long sections of HTML should not be anywhere near to PHP. They should be in template files (separately maintained) or stored in a CMS system. I find it is rare that you need much HTML in a PHP script.
That being the case, where HTML is in a PHP script, it is clearest for it to be enclosed in "", so that the variables may be inserted with ease and debugging is easy. I've spent hours rewriting the style of code you suggest above into more readable formats - and in doing so all the bugs became easy to spot.
| 12:41 pm on Apr 26, 2008 (gmt 0)|
well I have to disagree, stating templates as a hard and fast rule is a way to make sure that newer coders make slow sites
I use them but I also use some of the above, no problems in my mind, there is no absolute rule on this and you need to analyze your situation/site and make the best decisions for your users.
speed is one of the most important things on the web
a lot of the templating systems or cms's that I've seen are crap
| 6:42 pm on Apr 26, 2008 (gmt 0)|
When I started out doing it the "wrong" way, I saw page load times of 4 or 5 seconds or more...
By experimentation, and following various bits of advice found here, I have trimmed a couple of seconds off some of the pages.
There's still room for improvement.
| 7:38 pm on Apr 26, 2008 (gmt 0)|
I haven't experienced any performance problems in page load time when using PHP Shorthand on my sites. All of my pages takes less than one second to load (approx.) using a normal 512/256 mbit connection -- Shorthand or not.
However I have seen improvements in page load times ever since I began writing valid MarkUp and CSS some years ago. That's for sure.
| 2:18 am on Apr 27, 2008 (gmt 0)|
When you are looking at this kind of question, the answer is almost certainly to upgrade your hardware.
|stating templates as a hard and fast rule is a way to make sure that newer coders make slow sites |
I disagree, based upon simple mathematics. Take a typical site of 25 pages, to be built with and without templates on a one year lifecycle, not including the initial build costs (which are higher for the template-less site):
- Cheap slow hosting: $25/mo.
- Total hosting cost: $300
- Every change: 25 pages x 5mins = 2h 5mins
- Just one change a week: 108 h 20 mins
- Total time costing at $50/h: $5416.67
- Final cost excluding intial dev: $5716.67
- Dedicated: $200/mo.
- Total hosting cost: $2400
- Every change: 1 page x 5 mins = 5 mins
- Just one change a week: 4 h 20 mins
- Total time costing at $50/h: $216.67
- Final cost excluding initial dev: $2616.67
I have deliberately undervalued programmer time and underestimated change count. I have costed both programmers the same, despite the fact that realistically the templated site can be maintained by a non-PHP programmer with knowledge only of HTML, much less expensively. In more realistic cases the benefits of using some form of template system will be far higher.
You then need to look a step further at what happens next. Under site growth to say 100 pages, the model becomes even more in favour of the templated system.
Finally, don't forget how easy it is to miss a page when manually changing a small detail across a non-templated site. If you missed one in 25 pages each time, over a year of changes you'd average two mistakes a page and have a very ragged looking site.
| 9:39 am on Apr 27, 2008 (gmt 0)|
|It is my belief that long sections of HTML should not be anywhere near to PHP. They should be in template files (separately maintained) or stored in a CMS system. I find it is rare that you need much HTML in a PHP script. |
Some argue that PHP itself is a template engine. Thus, you don't actually need another template engine on top. It's not a question of mixing HTML code with PHP code. It's a question of mixing business logic with presentation logic.
Besides, template engines add complexity (as in too complicated for beginners) or they can have performance issues (if you don't cache).
I'm aware that a developer has to be more disciplined when working with PHP templates because of the lack of restrictions.
| 2:12 pm on May 3, 2008 (gmt 0)|
the trouble with your response though V3 is that your use of the word "templates" is non specific and this is why I say
"stating templates as a hard and fast rule is a way to make sure that newer coders make slow sites"
what do you mean specifically by templates?
just a header and footer include?
something like smarty?
in my mind those are the opposing ends of the templating spectrum. I think that newer coders should try to understand where in the spectrum their needs fall. This is a more complex understanding than just "templates save time and money".
I guarantee that your comparison is too basic for the complex question of templates.