SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 51
  1. #1
    ********* Articles ArticleBot's Avatar
    Join Date
    Apr 2001
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Discussion thread for Beyond The Template Engine

    This is a dedicated thread for discussing the SitePoint article 'Beyond The Template Engine'

  2. #2
    SitePoint Enthusiast Sasa's Avatar
    Join Date
    Mar 2003
    Location
    Cologne, Germany
    Posts
    60
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice Article,

    shows how simple is always beautiful. Of course you could get rid of that nasty <?=$abc ?> syntax by using eval() for the fetch method. But that is a matter of taste I guess. The important thing is, like you say, "separate your business logic from your presentation logic" [img]images/smilies/wink.gif[/img]

  3. #3
    Anonymous
    SitePoint Community Guest
    While I appreciate the article, the problem still remains, trying to keep the HTML and php logic together in the presentation does not work unless you are a graphic designer AND php programmer. Once again another template related article fails to bring up pure CSS/XHTML as the obvious solution. eg.. see csszengarden.com for an example

  4. #4
    SitePoint Member
    Join Date
    Sep 2003
    Location
    A House
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Please tell me how using eval() could remove the "nasty" syntax.

  5. #5
    One website at a time mmj's Avatar
    Join Date
    Feb 2001
    Location
    Melbourne Australia
    Posts
    6,282
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by saberworks
    Please tell me how using eval() could remove the "nasty" syntax.
    It would be possible to use eval() to do this. However, the eval() statement would replace only the include() statement. It's just a matter of convenience. If you're loading a template from a file, you can use include(). If you're loading a template from a string variable (for example, after pulling it from a database), then you could use eval().
    [mmj] My magic jigsaw
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The Bit Depth Blog Twitter Contact me
    Neon Javascript Framework Jokes Android stuff

  6. #6
    One website at a time mmj's Avatar
    Join Date
    Feb 2001
    Location
    Melbourne Australia
    Posts
    6,282
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    It's a good article, and it makes some good points about the usefulness of some popular templating systems, including the point that PHP itself makes a good template system, eliminating the need to learn another syntax.
    [mmj] My magic jigsaw
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The Bit Depth Blog Twitter Contact me
    Neon Javascript Framework Jokes Android stuff

  7. #7
    SitePoint Enthusiast Sasa's Avatar
    Join Date
    Mar 2003
    Location
    Cologne, Germany
    Posts
    60
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sasa

  8. #8
    Anonymous
    SitePoint Community Guest
    I liked this article a lot, specially since it gives me good hope of creating a nice template system without learning another language, just a smart way of using PHP. I still have to learn classes though, but was gonna anyway hehe.

  9. #9
    Anonymous
    SitePoint Community Guest
    Thank you... You explained why Smarty and the other templates are so hard to sort out. Your artical was written so that I could understand the process.
    Thanks so very much..

  10. #10
    Anonymous
    SitePoint Community Guest
    Why smarty and not php code in the template? Well, smarty _is_ easier for people that don't know how to program php, smarty compiled templates have the php extension (thus are cachable by an accelarator), you control exactly what functions designers have access to, and in html editors and browsers the smarty tags look better than php ones. All of this for a small overhead...

  11. #11
    Anonymous
    SitePoint Community Guest
    Excellent article.. Ready for my collection of utils...

  12. #12
    SitePoint Addict Messiah's Avatar
    Join Date
    Jun 2001
    Location
    Bloomington, In.
    Posts
    216
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have been playing around with your template class. It seems to work as expected for your basic variable interpolation, however, I can't seem to figure out how to go about seperation when more than variable interpolation is required. Would it be possible to get an example of using a basic for loop with this template class?

    Or if anyone else out there is using it, could you provide an example?
    Messiah | Ink-Press: web publishing simplified!

  13. #13
    Can we go to a 48 hour day?
    Join Date
    May 2002
    Location
    MI
    Posts
    906
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    on a side note, anyone else have problems getting the printable version of that article to pint from firebird?
    mitechie.com
    "Techies just think a little differently
    ...at least that is what they keep telling me."

  14. #14
    Anonymous
    SitePoint Community Guest
    Warning: Unknown(/Users/moo/Sites/template/examples/caching.php): failed to open stream: Permission denied in Unknown on line 0

    Warning: (null)(): Failed opening '/Users/moo/Sites//template/examples/caching.php' for inclusion (include_path='.:/Library/PHP4/lib/php') in Unknown on line 0

    I get that on all files, even the user_list one, and I can't make any sense of it :/

  15. #15
    SitePoint Addict lundberg's Avatar
    Join Date
    Mar 2003
    Location
    Sweden
    Posts
    370
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What about caching If I want to have a template inside another one?

    Should I do like this:
    Code:
    <?php
    require_once('./include/template.php');
    
    $path = './templates/';
    
    $file = 'list.tpl.php';
    
    $cache_id = $file . $_SERVER['REQUEST_URI'];
    $tpl = & new CachedTemplate($path, $cache_id, 900);
    $body = & new CachedTemplate($path, $cache_id, 900);
      
    
    if(!($tpl->is_cached())) {
       $tpl->set('title', 'My Title');
       $tpl->set('intro', 'The intro paragraph.');
       $tpl->set('list', array('cat', 'dog', 'mouse'));
    }
    
    if(!($body->is_cached())) {
       $body->set('user_list', fetch_user_list());
    }
    
    $tpl->set('body', $body->fetch('user_list.tpl.php'));
    
    echo $tpl->fetch_cache($file);
    ?>

    Martin Lundberg
    Sweden

  16. #16
    SitePoint Zealot
    Join Date
    Jul 2003
    Location
    Los Angeles
    Posts
    199
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Cool

    If you want to use php as a templating system by imbedding php directives in html then it doesn't get any easier than Harry's AwesomeTemplateEngine at http://www.sitepoint.com/forums/show...esome+template


  17. #17
    SitePoint Addict lundberg's Avatar
    Join Date
    Mar 2003
    Location
    Sweden
    Posts
    370
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    nice But why is my code not working? when i go this page all i get is the user_list.tpl.php not the list.tpl.php =/

    Martin Lundberg
    Sweden

  18. #18
    Anonymous
    SitePoint Community Guest
    I like this article, especially the comments about extra layers of templating structure delivering little new functionality but lots of new complexity.

    However, I would go a step further and question the value of even this limited "Template Class". It seems that all it really adds to plain old php is caching.

    But why do we need caching anyway? Isn't the need for caching just a sympto m of the same structure bloat that template engines are guilty of?

    Over-layering causes the performance problems which caching solves by yet more layering!

    In any case, caching is increasingly useless for sophisticated e-commerce, where the content of any page needs customisation on the basis of the immediate request history of the viewer.

    And, at least in my experience, final performance for the end-user seems to be always limited by retrieval of third-party external content i.e. advertisements, referal counters etc.

    I would argue that plain old php, (a templating technology right from the start), is the best tool. It just needs further development e.g.
    a) Security: dynamic control over available php commands.
    b) Partial includes: include of a file section and not just the whole file
    c) Macros: dynamic recursive code snippets.

    Unfortunately all of these are made impossible by the concentration on a high-performance parser, (Zend), to cope with over-structured code! Personally I would rather have more functionality and less unnecessary performance.




  19. #19
    Anonymous
    SitePoint Community Guest
    This is a terrific article, that does a pretty good job of explaining why template engines generally do the wrong things, and so are a bad idea.

    The need for templates comes from the need to reconcile two opposed positions:

    1- Site performance is dependent on: bandwidth, disk i/o, memory, and mips (in roughly this order).

    2- Development performance is dependent on: abstraction, expression, composition. (All of which are increased by expending more disk i/o, allocating more memory, or using more mips.)

    Instead of saying 'img src="path/foo"' it's easier for me to write and call a function "show_image(foo)".

    I then build up to

    show_image_palette(foo, bar, baz)

    and from there to

    show_navigation_bar(...)

    and from there to

    page_header(...)

    Every time I increase the distance between the developer and the HTML, I improve the performance of my "development engine" -- more expression per byte written.

    But doing so in "pure php" comes at the cost of burning mips and memory and disk i/o to pull in all the classes and templates and who-knows-what needed to translage

    page_header(...)

    into:

    html..body..h1../h1..

    The solution, of course, is to use "software judo" to put abstraction and expression to work on the whole mips/bandwidth expenditure issue.

    The best answer to date is of course the one proposed in the article:

    1- Provide an abstract interface to the separation of business from presentation logic. Partitioning the code into "business parts" and "display parts" is a good idea, regardless of what languages are used for either part. (You could get away with a big horizontal line in your source code, if it comes to that:

    #----------- HERE BE PRESENTATION ----

    2- Develop a caching mechanism so that abstract code like page_header(...) only has to be converted to html once.

    Someone made the comment that caching was just covering up inefficiency. This is untrue. Caching is to PHP what compilation is to 'C++'. PHP doesn't get compiled to binary code, despite what the Zend wonks tell you. PHP is compiled to HTML, every time the user clicks the mouse. *THAT* is the ultimate output, so that's where the highest benefit is derived.

    To restate: This is a fine article, and a nice start at recognizing the 'real' requirements for a templating system. Kudos!

    =Austin
    Hustin_Aastings@Cahoo.Yom

  20. #20
    SitePoint Member
    Join Date
    Apr 2004
    Location
    Mexico City
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Anonymous
    I like this article, especially the comments about extra layers of templating structure delivering little new functionality but lots of new complexity.

    ... In any case, caching is increasingly useless for sophisticated e-commerce, where the content of any page needs customisation on the basis of the immediate request history of the viewer.
    Caching is useful for intranet projects, i.e. large (1MB) reports. Without caching, that adds LOTS of overhead to your SQL engine.

  21. #21
    SitePoint Enthusiast Adam E's Avatar
    Join Date
    Apr 2004
    Location
    Australia
    Posts
    91
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I like the idea of it caching the templates except the function is failing...I get the error

    Unable to write cache.
    Adam

  22. #22
    SitePoint Enthusiast 2slick's Avatar
    Join Date
    Jun 2004
    Location
    Philippines
    Posts
    50
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is a nice article.

  23. #23
    Spoutnik
    SitePoint Community Guest
    This is a great class!
    I have used it for one year.
    100% PHP is less difficult than learn PHP + Smarty template logic.
    Overall, caching works perfect!

  24. #24
    SitePoint Enthusiast Adam E's Avatar
    Join Date
    Apr 2004
    Location
    Australia
    Posts
    91
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Can anyone help with the error I am getting?

    Unable to write cache.
    Adam

  25. #25
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you have PHP5 access, just use an XSL template. 100% better than any other solution I've seen. Make yourself a "Writer" calss and a "Reporter" class. Pass the writer around your PHP code which records a DomDocument with all the info which needs to be on your page, then make a reporter which converts the XML output from your app (stored in the writer) and with a bit of XSL magic turn it into XHTML. The PHP code for the templating itself (in the reporter) is only about 4 lines of code! And you get total separtaion of presentation logic and otherwise, because of the intermediate XML (cachable) data stage. Any you want caching? Just write a CachingReporter based on any caching system you care to use. Easy!

    Douglas
    Hello World


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
  •