Results 26 to 29 of 29
Feb 15, 2012, 06:33 #26
- Join Date
- Jan 2008
- Knoxville TN
- 43 Post(s)
- 0 Thread(s)
Hey! I resemble that remark.
Feb 15, 2012, 07:04 #27
I've delivered solutions to plenty of clients where there is a marketing department, where some marketing or design person who is versed in HTML will be altering the UI from time to time, outside of a CMS capacity. Should my system allow this individual to do what they need to do, as per the companies requirements, in a safe manner. Or should I tell them that they need to replace their marketing guy with a designer who is versed technically from a programming perspective?
For example, I had a client a couple of years back who had an internal design and marketing department, one of the staff members was a designer who was "trained as a web designer" and would be adding custom skins to the site at certain seasons (Christmas, Easter, Summer and Autumn if I recall correctly). Their task; as in what they wanted to do each "season" would require them to do some amount of HTML editing on the site.
The template engine I delivered to them allowed this designer to create separate seasonal skins which were activated and deactivated (preserving the default skin), allowed the designer to create their skin updates without having to concern themselves with PHP code at all; as the PHP code shouldn't affect them, and the system prevented them from inputting any PHP code, accessing any data they shouldn't access or modifying any variables. So if the designer decided they wanted to be smart (ill judgement) or made any silly mistakes it wouldn't affect the operations of their application.
Of course this all depends on how the system will be used and who will have access to it, your comment above is only really relevant if you know for certain your system is only going to be handled by skilled and experienced developers and designers, which isn't always going to be the case.
I for one never advocated using Smarty (I can't stand Smarty and agree it bloats the application) and don't advocate creating a template language that needs to be parsed unless the solution explicitly calls for such a thing to exist.
The rudimentary template system you demonstrated in your post is achieving exactly what I'm advocating, how templates are structured and the features of the "engine" are of course purely down to developer preferences and project requirements. If a system demands only a simplistic template engine then that's great, if it demands something more feature-some then you can introduce that.
I don't believe that HTML should be embedded into your applications code, that approach is just messy and can lead to problems down the line, so some kind of template engine, even a rudimentary one like the one you demonstrated, is required in most circumstances.
I still don't think its a good idea to allow PHP code to be entered directly into templates. In doing so and I feel in your responses, you are making a lot of dangerous assumptions about who will be coming into contact with the application in the future.
It is interesting you say this, the two biggest issues I encounter as a developer, when working with existing systems are:
1. Poor code structure and code bases that have been hacked about by developers in a bad manner; leading to systems that are difficult to maintain and often have issues that have been introduced at some point down the line.
2. Code bases that don't use template engines, where a "designer who knows some PHP" has attempted to make UI changes or front end redesigns and caused damage to the system in some way because they as a non developer didn't really understand the systems code base or appreciate the nuances of development that is second nature to developers.
Introducing some kind of template engine, preferably that prevents PHP insertion into templates can help the second problem and in some cases help the first; as oftentimes I have found its UI type changes that are leading to the hacking around of code by a designer who has been hired to do some design work but has also taken on a few bits that involve a bit of coding.
Feb 20, 2012, 22:08 #28
- Join Date
- Feb 2012
- 0 Post(s)
- 0 Thread(s)
I wasn't here for a couple of days.
Thanks for keeping up answering.
I will try your recommendation as it seems to be sensible.
I'm just wondering why you thought you needed to use double quotes and /t /n just to add carriage returns and tabs...
I know now that there are better ways to do it and that was my main intention in coming here and ask my question.
Thank you guys!
Feb 20, 2012, 23:26 #29
Personally, I like both raw PHP and Twig. For the Symfony fans here, remember that raw PHP is the template system in Symfony 1.
But I also don't think we should ignore the advantages that can come from an extra layer of templating logic. It can allow our output to be automatically HTML escaped, which I think is the biggest advantage. It keeps our applications secure by default. We'd have to go out of our way to screw up. The second-best advantage is that it prevents UI coders from mucking around. Of course, you could just tell everyone to only write templates in the proper way, but eventually someone -- maybe a new hire -- will be less than perfect. I think it's a good thing when the language helps you enforce good practices. And finally, a new syntax designed for templates, and templates only, can be slightly shorter and easier to type. This last one is clearly the least significant advantage, but it's an advantage nonetheless.
If it's performance you're worried about, then there's two things to keep in mind. The first is that, if you profiled a real-life application with database fetches and inserts and other logic, I'd wager that a templating engine would be a small factor of the overall performance. And the second thing to keep in mind is that Twig, at least, actually compiles the templates to raw PHP. So it parses the template just once, and every request thereafter is served as raw PHP.