SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 57
  1. #26
    SitePoint Guru aamonkey's Avatar
    Join Date
    Sep 2004
    Location
    kansas
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    I never said anything about performance. I'm talking about maintainability. Do you ignore classes and objects because they're slower? Performance is a non-issue. Servers are cheap, development time is expensive.




    Yes, you're right. But ignoring tag names, I can change the meaning of logged_in_user for the templates without affecting $user->isLoggedIn() which will more than likely be used in the code for all sorts of things. Yes "logged_in_user" becomes a wrong label and difficult to understand for those looking at the code now which is why I'd advocate better tag names to begin with but my point still stands, it's a single change rather than a lot.

    A better example, then, and yes this is contrived too but similar real world (and more complex) problems do frequently happen:

    I have a simple forum, I want to extend my it to have a section where only users with over 10 posts can do anything. I have various marked up buttons, links, forms, etc. If they are just marked up I can change the logic in one place. With php logic in the template I need to update each occurrence.

    My point was not that trivial example but rather to show that including logic in templates creates unnecessary repeated code. As I said, it's like CSS inline styles vs an external stylesheet.

    Keep in mind also, that by abstracting the logic to a separate class, the logic is entirely testable with phpunit/simApletest/etc.
    That's great, but it doesn't require a (second) parser to accomplish this. You can just assign values to variables using whatever logic you like in your business logic layer, and pass those variables to the templates. It's essentially exactly what you are describing - without the extra overhead and without the need to learn a custom syntax. Why not use php for what it is best at?
    aaron-fisher.com - PHP articles and more

  2. #27
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    I'm also wondering why use the extra parsing layer. Supposing your proposed 'returning user' and 'unregistered user' are what we want to check for then why instead of:
    Quote Originally Posted by TomB View Post
    PHP Code:
    <returning_user>
    Welcome back <?php echo $user->name?>
    </returning_user>

    <unregistered_user>
    Welcome, Guest, Please login or register.
    </unregistered_user>
    don't we use this:
    PHP Code:
    <?php
    if ($user->isReturningUser()) {
    ?>
    Welcome back <?php echo $user->name?>
    <?php
    }
    if (
    $user->isUnregisteredUser()) {
    ?>
    Welcome, Guest, Please login or register.
    <?php
    }
    ?>
    This way we can keep isLoggedIn() method for all the other usage cases. This looks simpler to me.

  3. #28
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by aamonkey View Post
    That's great, but it doesn't require a (second) parser to accomplish this. You can just assign values to variables using whatever logic you like in your business logic layer, and pass those variables to the templates. It's essentially exactly what you are describing - without the extra overhead and without the need to learn a custom syntax. Why not use php for what it is best at?
    1) You can skip that binding logic entirely.

    2) and more importantly it lets you easily abstract away common display logic (see the pagination example).

    3) It lets you have total control over what's possible without working PHPs syntax around it. For instance, I use code like this:

    PHP Code:
    <tabsheet>
        <
    tab name="Tab 1">
            <
    h1>This is tab 1</h1>
            <
    p>foo</p>
        </
    tab>

        <
    tab name="Tab 2">
            <
    p>tab 2</p>
        </
    tab>
    </
    tabsheet
    Which is automatically translated into something like this:

    PHP Code:
    <div class="tabsheet" id="tabsheet1">
        <
    ul class="tabheader">
            <
    li id="tabsheet1_1 current">Tab 1</li>
            <
    li id="tabsheet1_2">Tab 2</li>
        </
    ul>
        <
    div class="tabpage current" id="tabsheet1_page1">
            <
    h1>This is tab 1</h1>
            <
    p>foo</p>
        </
    div>
        <
    div class="tabpage" id="tabsheet1_page2">
            <
    p>tab 2</p>
        </
    div>
    </
    div
    Which displays a set of tabs and pages that maps directly into my existing CSS and javascript and just *works* without any messing worrying about attaching the javascript events, getting element ids/names right. All the generation logic is abstracted away and even supports nesting. It makes for very fast built templates. I have various other components including a headed, potentially draggable box which I just use <box title="Box">Contents</box> rather than multiple divs. If I need to change the way the box is drawn, it's its own template in one and it will affect the site globally. I have similar componentalised form generation. Where this is especially useful is for mobile browser versions.

    I'm also wondering why use the extra parsing layer. Supposing your proposed 'returning user' and 'unregistered user' are what we want to check for then why instead of:
    This requires knowledge that things may change regarding that condition. What if that changes to $user->isReturning() && $forum->minAccountAge < $user->accountAge()*. My point is, you can't know how things will change. As I stated previously, it's the equivalent of CSS stylesheets vs inline styles. I can essentially update the "stylesheet" (the logic) in one place and affect everything.

    *Again, think beyond this trivial example to real-world scenarios where things do change all the time.

  4. #29
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    er... the auto-generated ids are needed so the javascript can automatically link the tab buttons to the content.

  5. #30
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    Elements aren't supposed to have multiple ID's. (I'm 95% sure of that).

    id="tabsheet1_1 current" is not valid markup since there are 2 ids there.

  6. #31
    Utopia, Inc. silver trophy
    ScallioXTX's Avatar
    Join Date
    Aug 2008
    Location
    The Netherlands
    Posts
    9,094
    Mentioned
    153 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    Elements aren't supposed to have multiple ID's. (I'm 95% sure of that).
    Indeed. One element can have zero or one id's, but not more.
    Rémon - Hosting Advisor

    SitePoint forums will switch to Discourse soon! Make sure you're ready for it!

    Minimal Bookmarks Tree
    My Google Chrome extension: browsing bookmarks made easy

  7. #32
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    Elements aren't supposed to have multiple ID's. (I'm 95% sure of that).

    id="tabsheet1_1 current" is not valid markup since there are 2 ids there.
    Off Topic:

    yep sorry, was supposed to go in the class name, I was only typing that out for demonstration purposes

  8. #33
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    Elements aren't supposed to have multiple ID's. (I'm 95% sure of that).
    Then become 100%

    id="tabsheet1_1 current" is not valid markup since there are 2 ids there.
    Correct, it shoud be
    Code:
    id="tabsheet1_1" class="current"
    or something similar

    Edit: It looks like my post was almost simultaneos with the previous ones...

  9. #34
    SitePoint Wizard rguy84's Avatar
    Join Date
    Sep 2005
    Location
    Durham, NC
    Posts
    1,659
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    The introduction of the logged in tags made me laugh. You'd rather write a new doctype vs making a php function? Same with the tab.
    Ryan B | My Blog | Twitter

  10. #35
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    It's not a new doctype? It gets translated into html. The markup itself is valid xml.

    Whereas:

    PHP Code:
    <div class="<?php echo $className?>"></div>
    Is not.

  11. #36
    SitePoint Wizard rguy84's Avatar
    Join Date
    Sep 2005
    Location
    Durham, NC
    Posts
    1,659
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    is not where? When parsed?

    Also, Turning <tabsheet> into a nested div requires that your browser does parsing. Somewhere something must tell it to do that. To my knowledge, tabsheet is not a valid html tag.
    Ryan B | My Blog | Twitter

  12. #37
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    It's not a new doctype? It gets translated into html. The markup itself is valid xml.

    Whereas:

    PHP Code:
    <div class="<?php echo $className?>"></div>
    Is not.
    Who cares if server side preparse files are valid as long as they parse into valid markup?

  13. #38
    SitePoint Wizard rguy84's Avatar
    Join Date
    Sep 2005
    Location
    Durham, NC
    Posts
    1,659
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    Who cares if server side preparse files are valid as long as they parse into valid markup?
    exactly my thoughts. if somebody is worried about preparsed, you can't use anything other than html, not even, gasps javascript
    Ryan B | My Blog | Twitter

  14. #39
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by rguy84 View Post
    is not where? When parsed?

    Also, Turning <tabsheet> into a nested div requires that your browser does parsing. Somewhere something must tell it to do that. To my knowledge, tabsheet is not a valid html tag.
    On the server... in php... which this entire thread is about

    Who cares if server side preparse files are valid as long as they parse into valid markup?
    My IDE cares, it lets me use the full extent of the HTML/xml editing capabilities if it's valid.

  15. #40
    SitePoint Wizard rguy84's Avatar
    Join Date
    Sep 2005
    Location
    Durham, NC
    Posts
    1,659
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    On the server... in php... which this entire thread is about



    My IDE cares, it lets me use the full extent of the HTML/xml editing capabilities if it's valid.
    so, you made a function that allows you to made random tags, then parses those tags to valid ones?

    If no, how does
    Code:
    <tabset>
    <tab>tab 1</tab>
    ... or whatever
    become
    Code:
    <div class="tabsheet" id="tabsheet1">
        <ul class="tabheader">
            <li id="tabsheet1_1 current">Tab 1</li>
    ........
    without needing an external source to tell the browser how to handle the <tabset> and <tab> tags?
    Ryan B | My Blog | Twitter

  16. #41
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Yes. A php function translates it. It *could* equally be done by XSLT on the client.

  17. #42
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    On the server... in php... which this entire thread is about



    My IDE cares, it lets me use the full extent of the HTML/xml editing capabilities if it's valid.
    If your IDE chokes on the presence of valid PHP tags you need another IDE.

  18. #43
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    A "valid" php tag in an XML attribute causes validation errors which means I can't get a quick overview of where any markup errors are using the IDEs xml validator, which is useful for quickly identifying mismatched tags and other syntax errors.

  19. #44
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    Eclipse and Zend have no problem ignoring PHP tags when validating XML. Just say'n.

  20. #45
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Zend Studio 7.0 html and xml editors give the error:

    Code:
    -Invalid character used in text string
    -Start tag (<div>) not closed
    on:

    PHP Code:
    <!doctype html>
    <html>
        <head>
        </head>
        <body>
            <div class="<?php echo 'foo'?>"></div>        
        </body>

    </html>

  21. #46
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    Ah. I'm running 8.

  22. #47
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    You sure you're not validating it in the PHP editor? In which case it wont check the HTML/XML anyway. a < in an attribute *should* give a validation error, i'd say it's a bad thing if it allows it.

  23. #48
    SitePoint Enthusiast
    Join Date
    Nov 2009
    Posts
    90
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    I'm doing cleanup today on a legacy project at work that uses smarty. ............?
    Templating languages considered harmful?

    I have never seen the value of any templating language. At least not so for an interpreted language. In Java coding they can be handy, because they do allow you can change application output by editing html fragment files, without recompiling the jar file. In PHP I've never seen the point.

    Pundits invariably say "templates help separate content from logic."
    But to the contrary, they do just the opposite. They complicate debugging by pushing content into a parallel maze of annoyingly ugly looping, if and else logic constructs. If you find HTML errors you now have to search in at least two places (tpl files and/or the calling PHP functions) to find the trouble.

    I use a system that defines content divs in a small and cleanly-nested XML file. My home-rolled cms spits out the divs, as found inside the XML, and then fills the div contents as needed. Sometimes content comes a file_get_contents() on a fragment file, sometimes a database call and sometimes a plugin function call. Debugging is easier. Cleaner. Each div contents comes from an atomic source (not a maze of hard-to-find tpl archives). You hand edit a fragement file. Hand edit an SQL select, or debug a clearly identified plugin class.

    .....Want to find a problem output in a typical tpl directory? It's all too often
    redined 2 or 3 times over, in different tpl files files, called by ever-changing runtime conditions.

    In my system each URI can specify a different layout parameter, which maps through to a different XML file. Appearance is governed by CSS. There could be a thousand other such non-templating solutions--also cleaner and easier to deal with than annoying templating syntax.

  24. #49
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    You're preaching to the choir. I didn't build the thing, I just have the job of maintaining the SOB.

  25. #50
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by pittendrigh View Post
    templates help separate content from logic."
    But to the contrary, they do just the opposite. They complicate debugging by pushing content into a parallel maze of annoyingly ugly looping, if and else logic constructs. If you find HTML errors you now have to search in at least two places (tpl files and/or the calling PHP functions) to find the trouble.
    Your criticisms here are a straw man. You're arguing against poorly designed systems rather than template systems specifically, either template systems or non-template systems can suffer these problems. In fact having to search through repeated display logic is a problem more common to not using template systems because reusing display logic is difficult.

    .....Want to find a problem output in a typical tpl directory? It's all too often
    redined 2 or 3 times over, in different tpl files files, called by ever-changing runtime conditions.
    This is exactly the reason for templates.

    By mixing logic and markup there is a necessary need for repeated logic. You will end up repeating conditional logic, loop structures, etc. By removing this from the template it is entirely reusable with different templates (or the same template with different logic!). If you have logical conditions and control structures in your template it's not and encourages a copy/paste attitude to repeated display logic or places where something slightly different needs to happen.

    The other huge benefit is an otherwise impossible level of testability. By moving the logic away from the markup the logic can be properly unit tested (see my post a few pages back.) If you're mixing HTML and PHP, unit testing is out of the question.


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
  •