SitePoint Sponsor

User Tag List

Page 4 of 4 FirstFirst 1234
Results 76 to 88 of 88
  1. #76
    Afraid I can't do that Dave Hal9k's Avatar
    Join Date
    Mar 2004
    Location
    East Anglia, England.
    Posts
    640
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Young Twig
    What I often do is assign everything (or near everything) to a variable, much like in a templating system. But instead of assigning it to a member of a tpl_var array, I just throw it all in the global scope and include the template.

    I'm sure tons of people are against the whole global concept, and I'm sure you could do things more elegantly, but I've found it to be the simplest, easiest method. It's also quite reminiscent of a template engine. Just with cooler syntax.
    I had another look at my earlier reply and fixed some things. Instead of making everything global, how about playing around with extract() and function scope?

    So there's a test.php:

    PHP Code:
    <?php


    $data 
    = array // practically would be taken from database
    (
        
    'username' => 'Fred'
        
    'page_title' => 'Admin'
    );


    function 
    view($array$file// Two line templating system?
    {
        
    extract($array);
        require 
    $file;
    }

    view($data'admin.php');

    ?>
    Then admin.php
    PHP Code:
    <?php view(array ('page_title' => $page_title), 'header.php'?>
            Welcome back, <?=$username?>!
    <?php view(array(), 'footer.php'?>
    header.php
    PHP Code:
    <html>
        <head>
            <title><?=$page_title?></title>
        </head>
        <body>
    footer.php
    PHP Code:
        </body>
    </
    html
    Each call of view() creates a scope that the variables are unpacked into for the PHP template, as far as I have tested. Though I'd be interested in what other people think of the code; I've never used it in a production environment.

  2. #77
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hal9k:
    Simple but not elegant. No reason to divide template into header.php and footer.php ... other variables could be right inside BODY.

  3. #78
    SitePoint Member
    Join Date
    Oct 2007
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Plain and simple, you have to chose for yourself what feels right. On a personal note, I've never liked heavy-*** template engines (as in Smarty) just to get the, for instance, {variable} effect. I simply don't see the benefits. The templates still becomes messy because lets face it, designers (almost) never cares about the beautiful code that we code-junkies desire. And don't come talking about restriction, all it does (for me at least) is to mess with m developing and I have to make sacrifices.

    I've been continuously looking at making a clean xml/xsl template-system with a transformation (client- and serverside), but I do worry about how heavy it might get and even performance-wise. That would for once give the designer the exact variable-tree from the start, and they can do pretty much whatever they want with it with a simple stylesheet. Man that would indeed be sexy. As for now, I'm satisfied with my embedded php templates, and I do not worry because My designer sure knows me (and PHP) well enough not to meddle with the wrong functions.

    Yours,

  4. #79
    SitePoint Member
    Join Date
    Feb 2006
    Location
    Sweden
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Brian Lozier has written an excellent article where he explains why template engines such as Smarty are redundant - php itself is a template language.

    Lozier also provides a simple example of how a simple php template engine with caching functionality could be built up using very few lines of code

    http://www.massassi.com/php/articles/template_engines/

  5. #80
    Afraid I can't do that Dave Hal9k's Avatar
    Join Date
    Mar 2004
    Location
    East Anglia, England.
    Posts
    640
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by masterdont
    Hal9k:
    Simple but not elegant. No reason to divide template into header.php and footer.php ... other variables could be right inside BODY.
    Without header.php and footer.php you'd be repeating a lot of HTML code for each template, it's desirable for the same reasons you would use SSIs.

    Quote Originally Posted by stupidknight
    I've been continuously looking at making a clean xml/xsl template-system with a transformation (client- and serverside), but I do worry about how heavy it might get and even performance-wise. That would for once give the designer the exact variable-tree from the start, and they can do pretty much whatever they want with it with a simple stylesheet.
    I've also experimented with that using PHP 5's extended XML support. Ideally you need the database to return sets formatted as XML, so you don't have to do it all yourself. The problem I found with XSLT files is that they can be quite verbose and in many cases more complicated than plain PHP.

    Quote Originally Posted by eagleorn
    Lozier also provides a simple example of how a simple php template engine with caching functionality could be built up using very few lines of code

    http://www.massassi.com/php/articles/template_engines/
    Nice link, the fetch() function works on the same premise as my example above.

  6. #81
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hal9k:
    repeating a lot of HTML code for each template

    How many page templates do you have?

  7. #82
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Young Twig View Post
    Short doesn't necessarily mean easier to read. I personally find PHP easier to read than Smarty (perhaps because I'm more familiar with PHP). Regardless, I still think "foreach posts as post" is easier to read than "foreach from equals posts item equals post."
    Except with smarty you can do this:

    Code:
    {foreach key=cid item=con from=$results}
        <a href="contact.php?contact_id={$cid}">{$con.name} - {$con.nick}</a><br />
    {foreachelse}
        No items were found in the search
    {/foreach}
    The foreach syntax is a bit odd, but comes from the fact that smarty's control structures are infact functions, which means you can write your own control structures. This gives you a lot of power you don't get with plain php.

    I'm not expecting to convert anybody to smarty, and in fact I hardly use it myself. I'm just trying to point out that it's wrong to state that templating languages have no advantage over plain PHP; Just because you don't see the advantages, doesn't mean there aren't any.

  8. #83
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by eagleorn View Post
    Brian Lozier has written an excellent article where he explains why template engines such as Smarty are redundant - php itself is a template language.
    PHP may be a templating language, but that doesn't necessarily mean it's the best tool to do that job in all circumstances.

  9. #84
    Afraid I can't do that Dave Hal9k's Avatar
    Join Date
    Mar 2004
    Location
    East Anglia, England.
    Posts
    640
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Mastodont View Post
    How many page templates do you have?
    More than one, which is all it takes to violate DRY. As I said: it's desirable for the same reasons you would use SSIs.

  10. #85
    SitePoint Member
    Join Date
    Oct 2007
    Location
    London
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Interesting thread..

    We adopted WACT (a framework) about 18 months ago and we do all our projects with it. It was at version 0.2 then and unfortunately there hasn't been a release since (although development does continue).

    WACT 0.2's template engine is different from Smarty in that it's tag-based so you can't actually do any real explicit logic in the template (there are some conditional tags but it's so cumbersome to use them to do things "the wrong way"). An example of doing a list with WACT 0.2:

    WACT template:
    Code:
    <h1>My friends:</h1>
    <list:list id="data">
      <ul>
      <list:item><li>{$first_name} {$last_name}</li></list:item>
      </ul>
    </list:list>
    WACT View code ("prepare" method):
    Code:
    // $friends is a WACT dataset of all my friends
    $this->Template->setChildDataSource('data', $friends);
    Obviously this type of template language isn't cheap to parse in PHP (not with 0.2's engine at least) but the compiled templates are cached and we find the overhead negligible.

    It's definitely worthwhile because our designers love it. They have to work with WACT and Smarty (in a third-party application we use) on a daily basis and they all prefer WACT.. even with its alpha-version shortcomings.

    It's also easy to extend it and add your own tags thanks to the way the framework is designed.

    My biased advice would be for you to sign up to the WACT mailing list and beg them to make a new release :-)

  11. #86
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Whenever I see any kind of PHP code in a Template file, it makes me shiver!

  12. #87
    SitePoint Addict Jasper Bekkers's Avatar
    Join Date
    May 2007
    Location
    The Netherlands
    Posts
    282
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees View Post
    Actually, you are achieving something. Compare the first lines:

    Code:
    {foreach from=$mydata item=data}
    
    vs.
    
    <?php $_from = $this->_tpl_vars['mydata']; if (!is_array($_from) && !is_object($_from)) { settype($_from, 'array'); }if (count($_from)):
        foreach ($_from as $this->_tpl_vars['data']):
    ?>
    Compare:
    Code:
    <? foreach((array)$from as $data): ?>
    Although DSLs have their use, it's hard to argue in favor of them in an environment that actually needs a regular programming language. There are some obvious advantages to using a DSL in this case, such as being able to restrict what a designer can do, or have a language with more specialized control structures. However, there are a load of use cases that don't have those requirements and then it makes more sense to stick with PHP to have a more coherent environment.

    However, as always, there is no absolute good or evil; you just have to pick what right for you and your project.
    Design patterns: trying to do Smalltalk in Java.
    I blog too, you know.

  13. #88
    SitePoint Addict pachanga's Avatar
    Join Date
    Mar 2004
    Location
    Russia, Penza
    Posts
    265
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by shypoint View Post
    Interesting thread..

    We adopted WACT (a framework) about 18 months ago and we do all our projects with it. It was at version 0.2 then and unfortunately there hasn't been a release since (although development does continue).
    We used WACT for more than 3 years and even made a fork of it in the Limb3 framework(we needed some features it was missing and the original author was too hard to reach on the dev. mailing list). But now we have moved to {{macro}}, an extensible templating engine which uses C/C++ macro alike tags. It has all the good features of WACT(compiled code caching, pluggable tags, etc) while having all WACT's runtime part complexities removed. I believe {{macro}} tags are much easier to write.

    If you are interested, I blogged about {{macro}} in my blog http://efiquest.org/2007-11-04/14/


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
  •