SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 29 of 29
  1. #26
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,034
    Mentioned
    65 Post(s)
    Tagged
    0 Thread(s)
    Hey! I resemble that remark.

  2. #27
    SitePoint Addict FizixRichard's Avatar
    Join Date
    May 2003
    Location
    UK
    Posts
    372
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    I'm not the designer's babysitter, and neither is my code. The only time such filters make sense is when dealing with end-user supplied content. Using them elsewhere is unnecessary overhead.
    Well personally I would advocate that a programmers code should protect against the actions of anyone other than the developer. Of course this depends on the environment in where the application will be used and who will ultimately be working with the application.

    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.


    Quote Originally Posted by Michael Morris View Post
    What part of rudimentary did you not understand?

    I use a templating system. That means I do use templates. Hell, in my example the class was called "Template" and that should have been a clue that, no, I'm not against using templates. What I'm against is coming up with a new syntax or language specifically for the templates and then parsing that language in PHP. I'd rather use PHP itself to parse the templates.
    Then quite frankly I'm not sure what this argument is about?

    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.


    Quote Originally Posted by Michael Morris View Post
    Don't even get me started thinking about the living HELL I've had to put up with in production for the last two years. The code is approaching 9 years old, executive meddling has prevented any meaningful revision in that entire time, blocks of the turd are written in PHP 3, there are 5 data modelling systems in place, 3 distinct incomplete frameworks and that's just the surface of 3 pages of critical problems with the thing.... just, no. What I deal with day to day is a sterling example of how not to code.

    The system I've cited is from a new framework I'm working on, but its not complete and I can't find the time and energy to complete it.

    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.
    FIZIX - Full Service Digital Agency - Engaging websites, apps and games.
    Follow us @FIZIXAgency

  3. #28
    SitePoint Member
    Join Date
    Feb 2012
    Location
    Bali
    Posts
    6
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi there,

    I wasn't here for a couple of days.
    Thanks for keeping up answering.

    deathshadow60:
    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 am just getting into the potential of PHP and with my example code I tried to create a clean ouput of HTML code.
    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!

  4. #29
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,277
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    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.


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •