SitePoint Sponsor

User Tag List

Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 100
  1. #26
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Personally, I think PHP should be altered to allow semishort tags: <?php=$variable ?>. Simple and you don't need to worry about xml declarations messing things up.
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  2. #27
    SitePoint Wizard silver trophy redemption's Avatar
    Join Date
    Sep 2001
    Location
    Singapore
    Posts
    5,269
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by M. Johansson
    You know, this is EXACTLY the reason I'm considering switching from PHP to ASP.NET. Their "templating" is soo good. Someone really should rip it off for PHP.

    ...

    Will work perfectly in a wysiwyg editor for your designer, since it's XML.
    JSP had these xml-compliant tags and tag libraries and i believe Microsoft was emulating that success, which was a good move imo... it isn't particularly difficult to understand and has perhaps a _slightly_ higher learning curve than using a 3rd-party template engine like Smarty...


    Vincent: care to comment on my previous post please? ... don't feel pressured to rant, a shorter reply's fine, but go ahead and rant if you want to

  3. #28
    Wanna-be Apple nut silver trophy M. Johansson's Avatar
    Join Date
    Sep 2000
    Location
    Halmstad, Sweden
    Posts
    7,400
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by redemption

    JSP had these xml-compliant tags and tag libraries and i believe Microsoft was emulating that success, which was a good move imo... it isn't particularly difficult to understand and has perhaps a _slightly_ higher learning curve than using a 3rd-party template engine like Smarty...
    Yeah, I think much of the Web forms in ASP.NET is pretty much a rip off from Jakarta Struts. The nice part about it is that it's XML compliant and good looking, not that it's easy for the designer to understand.
    Mattias Johansson
    Short, Swedish, Web Developer

    Buttons and Dog Tags with your custom design:
    FatStatement.com

  4. #29
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Vincent: care to comment on my previous post please?
    Of course! The fact is I'm pretty busy right now, and don't have all the time I need to properly post something here. Also, I thought I'd wait a bit to see if other useful comments came up.

    About the syntax of the template engines versus the one from PHP: I guess it's a matter of opinion of what you like best, but I really don't see why it would be easier for someone to learn a specific template engine's language instead of a bit of plain, basic PHP. (On a sidenote: I never use the <?= tag myself either, but I think you can safely do that. Of course it is possible to disable this tag, but find me one ISP running PHP that did that.) I do not agree with the statement that third party template engines simplify the HTML code. But then again: this is probably a matter of opinion. (By the way, if you look at the ASP template examples Mattias posted, you'll see that there is ASP code inside the template, but just the code necessary to influence the presentation.)

    yes Dreamweaver MX (which not all my clients would have) does support PHP but you don't get what i'm trying to say i think: when i deal with the templates, or when i pass them on to a designer, we shouldn't have to care about PHP code embedded in the code... the template is the HTML page and shouldn't depend on the business logic that will use the template... what they should ideally see is a HTML file with placeholders, and they should be able to work around these placeholders easily and do their stuff...
    Naturally, I agree with business logic not belonging in the templates. But I do not quite understand the sentence 'we shouldn't have to care about PHP code embedded in the code'. As long as the templates use simple PHP, just for influencing the layout, I don't see a problem there. What your web designers see is a HTML file with placeholders, with the placeholders in PHP and not in some ugly template engine specific language. The advantage is that PHP is much more powerful than template engines, so a web designer who knows PHP could do really cool things. (Of course, this is a disadvantage as well: he could do things he shouldn't be doing.) Generally, web designers don't know PHP, and when they first start out on their job, they don't know template engines either. Teaching them the basics of PHP, necessary for placing placeholders in the HTML templates, or teaching them the peculiarities of a template engine doesn't make much of a difference. At least to me it doesn't.

    All in all, I can see the need for template engines, but if I had my way I would do it a lot different from how it's done now: I would do it on the client side, and not on the server side. I would give the designers a tool with a nice GUI that allows them to build good-looking designs. Then I would give the programmers a tool to translate these designs into PHP (or ASP, or JSP) which they can place on their servers. Their PHP doesn't need a template engine then, because all templates have allready been processed (and logically, any template need only be processed once). In my opinion, this puts the responsibility where it belongs: somewhere between design and development. All the time we're saying we don't want to burden designers with PHP, but why do we not mind if we burden the developer with parts of the design? I don't want to use a template engine like Smarty in my PHP code just because it makes it easier for my designers to create new sites. I think there should be a step in between, one that doesn't place burdens on any part of the site creation process.

    There is an analogy with graphical user interfaces here. The programmer shouldn't be bothered with how the various windows in an application look, like which button is placed where and what its caption is. This is better left to people who know about user interfaces (which is more of a psychological thing and has little to do with computer science). Currently, the developers (ranging from VB kiddies to C++ professionals) are often given descriptions of what the various windows should look like, so they still have to build them themselves. The necessary tools for cleanly separating design from development don't exist yet. But I'm convinced they will some day.

    what you're doing is essentially a template engine too, isn't it? you're creating your own template engine on top of PHP (the 'other template engine')
    That depends on your definition of the term 'template engine' .

    Seriously now, although I see where you're going, I don't agree. Examine the various template engines out there and look what parts they consist of: they introduce an engine-specific syntax for the placeholders, use a parser to find and translate these placeholders, and often store these translated templates in some cache. I don't do all of that. I do not use some specific syntax but plain PHP instead and therefore needn't implement a parser to wade through all those lines of HTML code, looking for the placeholders. For these reasons I believe I haven't built my own template engine. I use PHP as the template engine, one which can be 'activated' or used in many ways. Writing a couple of classes is just one way.

    someone with strong opinions like yours make for good discussions and a new learning experience every time
    I guess that's one way to look at it, and I'm glad you do... I can imagine many other views on my posts, and most of them aren't that positive. So thanks a lot! And of course I learn a lot from these discussions as well. That's the whole point of my participation in them.

    Vincent

  5. #30
    SitePoint Wizard silver trophy redemption's Avatar
    Join Date
    Sep 2001
    Location
    Singapore
    Posts
    5,269
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Of course! The fact is I'm pretty busy right now, and don't have all the time I need to properly post something here. Also, I thought I'd wait a bit to see if other useful comments came up.
    oops sorry ... i was just afraid you'd miss my comments (it's freaky but i saw you reading this post yesterday under 'Where are they?'... yes, i've nothing better to do ) as i value your input on this... anyway, you shouldn't feel bad about just posting as and when something you want to say comes up... you don't have to accumulate all your thoughts and dump them at one shot ...

    About the syntax of the template engines versus the one from PHP: I guess it's a matter of opinion of what you like best, but I really don't see why it would be easier for someone to learn a specific template engine's language instead of a bit of plain, basic PHP.
    all they designers will need to know is simple syntax which does only changes in formatting and presentation... i'm trying to say that you can't throw a complex PHP script to your designers and expect them to work with that, can you? by separating that complexity away, you allow your designers to see and change only what they have to see, while you (or your developers) handle the business logic, again separately... sure you can teach your designers basic PHP (it's really a very simple, clean language imo), but so what? you still can't expect them to safely deal with a more complex PHP script can you?

    (By the way, if you look at the ASP template examples Mattias posted, you'll see that there is ASP code inside the template, but just the code necessary to influence the presentation.)
    i am aware of how that works ... so are you trying to say this is a good or a bad solution?

    Naturally, I agree with business logic not belonging in the templates. But I do not quite understand the sentence 'we shouldn't have to care about PHP code embedded in the code'. As long as the templates use simple PHP, just for influencing the layout, I don't see a problem there.
    i meant if, like you said, the designers were to work on PHP scripts instead (see above )

    I would give the designers a tool with a nice GUI that allows them to build good-looking designs. Then I would give the programmers a tool to translate these designs into PHP (or ASP, or JSP) which they can place on their servers.
    that's a brilliant idea

    That depends on your definition of the term 'template engine' .

    Seriously now, although I see where you're going, I don't agree. Examine the various template engines out there and look what parts they consist of: they introduce an engine-specific syntax for the placeholders, use a parser to find and translate these placeholders, and often store these translated templates in some cache. I don't do all of that. I do not use some specific syntax but plain PHP instead and therefore needn't implement a parser to wade through all those lines of HTML code, looking for the placeholders. For these reasons I believe I haven't built my own template engine. I use PHP as the template engine, one which can be 'activated' or used in many ways. Writing a couple of classes is just one way.

    admittedly, you're right... but just to let you in on what i was thinking: you were essentially abstracting your content away from logic using your classes... that seemed at the time like the idea behind template engines but now i realise my mistaken interpretation... still, i kinda visualise your classes as a sort of templating solution (call this method to place header, call this method to make text bold, etc.)

    I guess that's one way to look at it, and I'm glad you do... I can imagine many other views on my posts, and most of them aren't that positive. So thanks a lot! And of course I learn a lot from these discussions as well. That's the whole point of my participation in them
    if there weren't harsh critics and opininated (sp?) people around, the world would probably never move forward...

    - Joel
    Last edited by redemption; Jul 18, 2002 at 01:27.

  6. #31
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    To sum things up a bit, you are making two remarks:
    1. Template engines are easier to use than PHP for web designers.
    2. You can trust web designers with (complex) PHP scripts.

    We already agree on the second point, I think. The only code to be in a template should be code that directly influences that template. Almost by definition, that is simple code. When using a template engine, that code must be simple, because the engine doesn't allow complex things; its code structures only allow you to do fairly trivial things. But for how long?

    Rembember that PHP started out as a simple template engine with more or less the same features as the template engines that exist on top of PHP now. Just as PHP has evolved, those template engines will as well. That's just the nature of these things. Users keep on demanding more and more 'features'. I bet my hat on it that in less than a year Smarty has evolved so much that for many developers it has become too complex (heck, we already see that now). These developers then either fall back on another, simpler engine, or decide (like me) not to use such an engine at all.

    In computer science, it's considered good practice to use an indirection to solve some problem if that problem can't be solved directly. You don't want complex PHP in the presentation layer? Then introduce a templating engine like Smarty that uses its own simple syntax. In a while a new indirection will be introduced: Smarty will be so large and complex that it has become too hard to configure it by hand, so a new PHP software package will be created that does that for you. Give that package a simple XML configuration file and it will create code for you that in turn uses Smarty. When focusing solely on their respective problem areas, these indirections all seem to make sense. When viewing the bigger picture, they do not. Instead of introducing indirections to solve new problems, they are used to solve the same problems over and over again. So the pipeline becomes longer and longer while it doesn't add anything significant.

    Why is PHP so complex? It's not the language itself; PHP is just an imperative language with a couple of basic constructs (assignments, conditionals and loops) and data types (integers, floats, strings, arrays, classes). The thing that makes PHP complex is its extremely large function library. There are over 50 functions that can be used with simple strings, each having its own peculiarities. To handle arrays, there are again over 50 functions available. In software development it all boils down to placing the right functions in the right order, and when there are many functions, finding that order and what functions to use is very hard.

    To lower the complexity of PHP, you can build a library that encapsulates many of the different functions, and leaves out the ones you never use. This is again an indirection, but a good one this time, because you can now offer an API that is much smaller and easier to use, while keeping the flexibility and power of the original library. Object-oriented programming is very suitable for this. You can write a single API for accessing databases, after which developers can use it with any DBMS. No need to remember all those mysql-, pgsql-, or mssql-functions. Just define an abstract class Database and the methods it should support, and require all subclasses (one for each DBMS) to implement them. Developers need only know the interface of the abstract class, and they can instantly use any DBMS without having to learn any new function. Less functions, less possible orderings of these functions, and lower complexity.

    Here's a shameless self-plug : take a look at http://www.sunlight.tmfweb.nl/eclipse. There you'll find an object-oriented programming library for PHP I have written. I use it all the time, which is why I'm not that good at using low-level PHP anymore. I never use fopen(), fgets() and fclose() to read text files, or pgsql_connect() and pgsql_query() to talk to PostgreSQL databases. I almost never even use constructs like 'for ($i = 0; $i < count($array); $i++) $item = $array[$i];'. I do all my looping with 'iterators', hiding the necessary counter - $i in this case - from sight, which makes sense because it is only an implementation detail, and has nothing to do with the problem I'm solving or the algorithm I'm implementing. In effect, all I have done (or better: tried to do ) is hide the complexity of PHP. Now I can write code much faster, because there are less functions to remember. Also, the code is much more readable, because the same (small) set of functions (in fact: classes and methods) is used over and over again; it's just the order that differs everytime.

    I think you can consider this post as a rant again...

    Vincent

  7. #32
    SitePoint Wizard silver trophy redemption's Avatar
    Join Date
    Sep 2001
    Location
    Singapore
    Posts
    5,269
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    To sum things up a bit, you are making two remarks:
    1. Template engines are easier to use than PHP for web designers.
    2. You can trust web designers with (complex) PHP scripts.
    you really mean 'can't' right?
    yes those are 2 of my points...
    also (as far as i can recall now... in a hurry):
    - templates allow developers and designers to work independently so they don't have to be forced to delve into one another's realm (too much)
    - voostind should be here more often to rant about good topics

    on a different note, the whole point of my article was to explain Smarty and put forward why it compares better to other template engines of its like, not why you should use templates

    We already agree on the second point, I think. The only code to be in a template should be code that directly influences that template. Almost by definition, that is simple code. When using a template engine, that code must be simple, because the engine doesn't allow complex things; its code structures only allow you to do fairly trivial things. But for how long?
    if you meant 'can't' then we agree

    i think you misunderstand the idea behind templates (or at least i think you misunderstand)... with the template, you can code whatever complexity that's needed in the script... then the script 'uses' the template you've designed to format itself nicely as a pretty web page... that's MVC not unlike that when you use servlets...

    i only have time to comment on these 2 points now... gotta go back home now i'll have to take a look later when i get back...

    - Joel

  8. #33
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    you really mean 'can't' right?
    Yup! Small typo, big difference in meaning...

    The fact that we both see templates a little different is probably because of the word itself. There is no clear definition for a 'template', neither in my own dictionary, nor in the Webopedia (http://www.webopedia.com/TERM/t/template.html). It's all words, but words can be so confusing...

    Vincent

  9. #34
    SitePoint Enthusiast
    Join Date
    Jun 2002
    Location
    Planet Earth
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by voostind
    Here's a shameless self-plug : take a look at http://www.sunlight.tmfweb.nl/eclipse. There you'll find an object-oriented programming library for PHP I have written. I use it all the time, which is why I'm not that good at using low-level PHP anymore.

    Vincent
    Hi Vincent, I must say I am very impressed with your rantings I am going to try eclipse now and from the glimpse I had, it looks awfully familiar back to the c++ days and looks a lot like java libs well done and I am very happy to find your lib! I hope you will keep maintaining it.

    Vincent, I'd appreciate if you could give us some examples on your OO site design by having the Application class etc, it would help me tremendously to start changing my development style. Perhaps a working example or a source code of one of your site (e.g. the eclipse site) would be very educational.

    Thanks very much once again

    regards
    Jim
    Fluid Hosting LLC - High Performance Web Presence
    New!! Virtual Private Server
    ICQ: 151540687 MSN: fluidhosting_jim@hotmail.com

  10. #35
    SitePoint Enthusiast Bartimeus's Avatar
    Join Date
    Dec 2000
    Location
    Norway, Trondheim
    Posts
    35
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have also been looking at eclipse lately and i agree that some examples would be usefull. I've build som manipulators and done some real nice structures with the loop class. It is extremly cool and beneficial to use i think.

    So i join the crew, show us some of your "magic" vincent
    Bjarte S Karlsen
    Roleplayer and webdeveloper with a high nerd factor.

  11. #36
    Your Lord and Master, Foamy gold trophy Hierophant's Avatar
    Join Date
    Aug 1999
    Location
    Lancaster, Ca. USA
    Posts
    12,305
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by whofarted
    Thanks for the info, I updated.

    Do any of you know of a good forum for help with smarty templates? & using templates period?

    TIA
    I am sure if you asked around here you would get a lot of good ideas and advice.
    Wayne Luke
    ------------


  12. #37
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    An example.

    Okay, here goes.

    A site has multiple pages. Each page is of a certain class (but class Page is always a parent), and excepts a number of arguments. These arguments are nothing but 'field1: value1; field2: value2;' lists. It's a bit limited, I know, but it works good enough for me. I store the necessary page-information in a single textfile, thus describing the whole site. An example:

    PHP Code:
    name caption | class      | arguments
    main 
    Home    StaticPage files'html/welcome.html, html/introduction.html';
    news News    NewsPage   directory'news/'size10;
    faq  FAQ     FaqPage    directory'faq/'
    As is hopefully clear from my other post, it's the class that defines the arguments. So class StaticPage expects a 'files' argument, with all the names of all static HTML files it must include. Class NewsPage on the other hand expects a 'directory'-argument where all newsmessages are stored (HTML), and an optional argument 'size' that describes how many messages it may show at most.

    At program startup, class Application reads the menu into memory. Normally I use a cache for that, but for simplicity I'll leave that out here:

    PHP Code:
    <?php
    require_once(ECLIPSE_ROOT 'DataFile.php');
    require_once(
    ECLIPSE_ROOT 'DataFileReader.php');
    require_once(
    ECLIPSE_ROOT 'DataFileIterator.php');

    class 
    Application
    {
        var 
    $menu;
        
        function 
    Application()
        {
        }
        
        function 
    run()
        {
            
    $this->loadMenu();
            
    $page =& $this->loadPage($this->getCurrent());
            
    $page->show();
        }
        
        function 
    loadMenu()
        {
            
    $this->menu =  array();
            
    $data       =& new DataFile('menu.dat', new DataFileReader);
            for (
    $it =& new DataFileIterator($data); $it->isValid(); $it->next())
            {
                
    $current =& $it->getCurrent();
                
    $this->menu[$current['name']] = $current;
            }
        }
        
        function 
    loadPage(&$item)
        {
            
    $class $item['class'];
            require_once(
    'classes/' $class '.php');
            return new 
    $class($this$item['name'], $item['arguments']);
            
        }
        
        function &
    getMenu()
        {
            return 
    $this->menu;
        }
        
        function &
    getCurrent()
        {
            if (isset(
    $_GET['page']) && isset($this->menu[$_GET['page']))
            {
                return 
    $this->menu[$_GET['page']];
            }
            
    reset($this->menu);
            return 
    current($this->menu);
        }
    }
    ?>
    And that's about all there is to class Application! Hardly interesting, now is it?

    Class Page is a baseclass for pages on a site, offering a set of methods subclasses can use (like parsing arguments, including HTML files, and so on). Here's some of it:

    PHP Code:
    <?php
    require_once(ECLIPSE_ROOT 'ArrayIterator.php');

    class 
    Page
    {
        var 
    $application;
        var 
    $name;
        var 
    $arguments;
        
        function 
    Page(&$application$name$arguments)
        {
            
    $this->application =& $application;
            
    $this->name        =  $name;
            
    $this->parseArguments($arguments);
        }
        
        function 
    parseArguments($arguments)
        {
            
    $it =& new ArrayIterator(explode(';'$arguments));
            for ( ; 
    $it->isValid(); $it->next())
            {
                list(
    $field$value) = array_map('trim'explode(':'$it->getCurrent()));
                if ((
    $value $this->parseValue($field$value)) !== false)
                {
                    
    $this->arguments[$field] = $value;
                }
            }
        }
        
        function 
    parseValue($field$value)
        {
            return 
    $value;
        }
        
        function 
    show()
        {
            
    $this->showHeader();
            
    $this->showMenu();
            
    $this->showContents();
            
    $this->showFooter();
        }
        
        function 
    showFile($file) { }
        function 
    showHeader()    { }
        function 
    showMenu()      { }
        function 
    showContents()  { }
        function 
    showFooter()    { }
        
        function 
    getArgument($name)
        {
            return isset(
    $this->arguments[$name]) ? $name false;
        }
        
        function &
    getApplication()
        {
            return 
    $this->application;
        }
        
        function &
    getMenu()
        {
            
    $application =& $this->getApplication();
            return 
    $application->getMenu();
        }
    }
    ?>
    Again, I left the caching part out. Normally, once an application is running correctly, it is a bit silly to keep parsing the same page arguments over and over again, so that's why I cache them.

    The method 'parseValue' may seem a bit strange, as it does nothing. It is intended for subclasses to override. This, for example, is class StaticPage (all of it!):

    PHP Code:
    <?php
    class StaticPage extends Page
    {
        function 
    parseValue($field$value)
        {
            if (
    $field == 'files')
            {
                return 
    array_map('trim'explode(','$value));
            }
            return 
    false;
        }
        
        function 
    showContents()
        {
            
    $it =& new ArrayIterator($this->getArgument('files'));
            for ( ; 
    $it->isValid(); $it->next())
            {
                
    $this->showFile($it->getCurrent());
            }
        }
    }
    ?>
    In other words: subclasses can easily extend class Page to correctly parse the parameters they need (and only those parameters).

    Well, I could go on here, but I think it wouldn't be very interesting. I hope that when you look at this code you find that it's extremely simple. It uses few lines, uses no tricks whatsoever, but is pretty powerful. If you count all the statements in the code, you'll see there are very little; The largest method has about 5. Also, there is no complicated code to read the menu from file, nor are there 'for ($i = 0; $i < $size; $i++)'-like loops. Those are implementation details that can and should be hidden.

    By the way: on a larger (more complex) site, I normally refactor the menu in a separate object (of class Menu). As it is now, class Page requests the menu from the Application object, and then traverses this datastructure (an array) to show the various items on it. If the site is large this places too many burdens on class Page, and then I introduce use class Menu, which knows how to read itself from a file (or the cache), and how to show itself as HTML. So all class Page does in that case is: '$menu =& $this->getMenu(); $menu->show();'.

    Vincent
    Last edited by voostind; Aug 21, 2002 at 00:44.

  13. #38
    SitePoint Enthusiast Bartimeus's Avatar
    Join Date
    Dec 2000
    Location
    Norway, Trondheim
    Posts
    35
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Excellent example vincent, you should realy consider writing a book or atleast a sitepoint article about this stuff
    Bjarte S Karlsen
    Roleplayer and webdeveloper with a high nerd factor.

  14. #39
    SitePoint Wizard silver trophy someonewhois's Avatar
    Join Date
    Jan 2002
    Location
    Canada
    Posts
    6,364
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Talking Sowi's turn to rant!

    Ok, I've got a semi-rant now. Not the smae as Vincents, but I've got something to say about templates now..




    Smarty: Who needs it?
    By: Someonewhois

    So you've got your site, and you need to change a link. Well, lucky for you you are using Smarty, so you just have to change the layout.html file. Yay, isn't that easy!

    So you think, "What's the catch?" then you run some tests, and regular PHP with the HTML copied in is 10x faster.


    Well, I've found that out, over my tests, and have relized this: Smarty just has waaay to many features! Now I know about all the cache and all that speeds it up, but you still don't need if's in a template, that's the whole perpose of templates: Seperating PHP from HTML!


    I looked at FastTemplates code (not Smarty's, but I'm sure it's even more) and I found out it's about 6 pages just going page down (and I have a 19 inch monitor at 1152x864 ). Well, that's just too long. It takes time to process through it!

    Now a few seconds may not seem a lot, but on public scripts it's important.

    I did tests with FastTemplate (I couldn't get Smarty to work the same wasy as FT, so I couldn't test it), and BANG it's over a full second to do a little test page. This test page, has a basic HTML design, add some links on it. It could well be a .html file, but I was testing with PHP, so I used it.
    The only PHP in it, was the execution time script I was using.

    Over a full second... I made my own MySQL templating system (Ok, it might be like comparing apples to oranges, but it's an example) last night, with VERY simple features (fits on my 19 inch monitor without scroll), and it runs it in 0.00023 seconds, on the exact same server!


    So I ask you, why do you want all these featurse? Why not use PHP for the features, and the template just for seperating HTML from PHP!

    I must admit, templating is VERY USEFUL, becuase you don't have to change every file and copy everything etc., but when they come out with if's, and all this other feature crap, then it becomes slow, and it's just wasting time becuase you aren't using the pages of code t hat are there.


    So if you can make a simple template program, that only replaces tags with other things, that runs over a second quicker, why would you WANT all those featurse?

    This has 3 main things: Display, assign, and parse. Parse just meaning you can assign a tag with another template, which even could be integrated with assign to make it faster, but I was sorta lazy and didn't feal like it..



    Then Smarty 2.2.0 comes out, and everybody goes "WWWWAHOO, LOOK AT ALL THE FEATURES", well, I rephrase that to: "WWWAHOO, LOOK AT ALL THE FEATURES THAT SLOW OUR SCRIPT EXECUTION TIME DOWN AND WE DON'T EVEN USE!".

    So what's the point?

    Oh, and it says it has "bug fixes"... Well if you don't have that many features, and just have a VERY simple class, then you don't end up with bugs in the first place.

    Please explain this to me.

    Thanks,
    ~someonewhois

  15. #40
    Talk to the /dev/null Theiggsta's Avatar
    Join Date
    Mar 2001
    Location
    Tampa, FL
    Posts
    376
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    My "rant"

    Well I think adding my 50 cents to this would be a good idea seeing as vincent is ranting.

    I have tested and tried every single templating system/style on the web and I should tell you my conclusions and will tell you about the top 2.

    Smarty:
    Very cool concept, especially with the caching of output as a php file. The interesting point that separates this from the rest is the fact the designer can control the output of the script. This is however not completely true since the PHP script itself controls the blocks that render and to do mysql queries, you need to do this in the PHP page first. On top of this many lines of configuration for a large project make this cumbersome to use on projects that depend on dynamic content. Overall I would say the addition of plugins is a great idea but there still isint enough documentation and designers will have trouble making it work properly.

    patTemplate/patXMLRenderer:
    This "templating engine" impressed me since it truly allowed for the designer to control output and layout of the website. The XML part of this engine made XML a practical use for templating and the addition of XSL-Style extensions made it almost convincing this is the best answer for your designers. However the patTemplate engine was incredibly slow (multiple and large pages slow it down to over 200ms) due to its extensive use of ereg line by line on every template. Since patXMLRenderer uses this as its tag definition section, this slows down the processing time down to a crawl and thus, your site suffers. Needless to say this is perfect, but the methods used are incredibly slow.

    Note:
    I have researched the current technologies available and saw XML/XSL being the most practical for a templating system mainly because XML is for content delivery and XSL being the made language for translating the output. However XSL is very hard to pickup and the language is only for those who know and have read a book on it. Another would be using a super class as Vincent discusses which would output everything lightning fast since it is native PHP code and not extra processing which of course has to process more in order to translate it back to a PHP equivalent output.

    Conclusion:
    In conclusion I completely agree with Vincents rant, however there should be more of a designer-friendly system that uses a web standard such as XML/XSLT since its more universal. Look @ ASP.NET and how they did everything, but I will never switch to ASP since after all, windows will never beat Linux. I actually treat PHP as actual software or as some dummies books call it an "application" even though it isint. PHP is just a syntax for a script which instructs the interpreter how to return content. Template engines are just something thats on top of what I already use in PHP since they too translate all their own syntax into PHP equivelent output.

    </rant>

    ^_^
    Last edited by Theiggsta; Aug 22, 2002 at 19:06.
    Aaron "Theiggsta" Kalin
    Pixel Martini
    Ruby and Rails Developer

  16. #41
    As the name suggests... trickie's Avatar
    Join Date
    Jul 2002
    Location
    Melbourne, Australia
    Posts
    678
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    small rant

    here is a small rant:

    All the analysis above is very interesting, and i especially like Vincent's style. I have a problem though with all of the 'template' solutions provided.

    If you are trying to seperate the content from the presentation then what happens if a client wants to view the same content in something other than HTML? All these 'template engines' are web/HTML specific. That is fine if the information that you have is only ever going to be published for a web browser, but i think that a good 'template engine' should address the issues associated with delivering content to any client that so desires it.

    I can see ways that some of the systems above could be tailored to address some of these concerns, but once the location and the protocol used to serve information become more ambiguous or abstract(web services etc) then it will be hard to justify the performance of those systems.

    I am just saying this cause i'm working on a XML spec that defines some formats for community information (polls, forums etc), and i think that some of the problems with the above systems lies in the fact that there is no formal structure for the data that these systems use. I know that it is impossible to create a data structure format that meets everyones needs, but i think that this problem isn't being addressed at all by the above systems.

    I also think that i have wandered a bit off the track!

    any way there is a rant. No where near as impressive as Vincents, but i had a go!

  17. #42
    SitePoint Enthusiast
    Join Date
    Jun 2002
    Location
    Planet Earth
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    *my turn to rant *

    Hi, I have been using Smarty for a while now on two of my main projects, including Fluid Hosting.

    The advantage that I feel is that it forces me to separate my application logic on one file and the output / html in another file, so basically for each page it requires two files, one the php and one is the .tpl template file.

    Before you start flaming me.... I know you can easily do it in php instead of using template system as well It is a fact that php is obviously more powerful and capable than any templating systems out there!

    I am sure for every point I make there will be a counter argument about it. So what I am trying to do here is share my experience with Smarty.

    Theiggsta says:
    Smarty:
    Very cool concept, especially with the caching of output as a php file. The interesting point that separates this from the rest is the fact the designer can control the output of the script. This is however not completely true since the PHP script itself controls the blocks that render and to do mysql queries, you need to do this in the PHP page first. On top of this many lines of configuration for a large project make this cumbersome to use on projects that depend on dynamic content. Overall I would say the addition of plugins is a great idea but there still isint enough documentation and designers will have trouble making it work properly.
    I am not sure why you said "not completely true" because PHP is supposed to do the queries and the template does the output without having any trace of query / data extraction etc. The logic embedded and supported by Smarty is only to allow you to control the *output* of the page based on the data that the php script gave to it. (Once again you can always use php to do this too )

    As for "many lines of configurations for a large project make this cumbersome"... not sure what you meant either..

    Let me give you an example on how I implemented Smarty:

    - First I create a file called "config.inc.php". This file will be included in every php files I have.
    - In this file, I created a derived class, extending the Smarty class. I normally call this Template:
    - In this Template class' constructor I then set the various paths required by smarty to find the template files location.

    This would be a sample of my class:

    PHP Code:
    $HOME_DIR '/home/jim';

    class 
    Template extends Smarty {
        function 
    Template()
        {
            
    $this->Smarty();
            
    $this->template_dir $GLOBALS['HOME_DIR'] . "/php/templates";
            
    $this->compile_dir $GLOBALS['HOME_DIR'] . "/php/templates_c";
            
    $this->config_dir $GLOBALS['HOME_DIR'] . '/php/configs';
        }
        
        function 
    display($page$sections null)
        {
            if (
    $section['none']) {
                
    parent::display($page);
                exit;
            }
            
            
    $default_sections = array(
                
    'left' => true
                
    'right' => true,
                
    'menu' => true,
                
    'body' => true,
                
    'footer' => true,
                
    'top' => true
                
    );
            
    $content $page $this->fetch($page) : '';
            
            
    $sections array_merge($default_sections$sections);
                
            
    $this->assign('_sections'$sections);
            
            
    parent::display('header.tpl');
            
    parent::display('top.tpl');
            
    parent::display('menu.tpl');
            
    parent::display('left.tpl');
            echo 
    $content;        
            
    parent::display('bottom.tpl');
            
    parent::display('footer.tpl');
        }

    So only the pure html code between <body>...</body> will be in each template. Headers, and any constructing html for the site goes in the various template bits that I am displaying inside the overriding display() function.

    The $sections parameter allows me to specify which section to include and tells the template to show / hide various parts of themselves.

    So that's the configuration. You don't need to override the display() function like I did since it is just one way to do it. You can include those various bits from inside your template, although you must do this in every templates.

    Next the pages themselves.

    Most of my "static pages" - those that don't have any dynamic contents in it will look like this:

    PHP Code:
    <?php
    require_once ('config.inc.php');
    $smarty = new Template// note here I use Template instead of Smarty
    $smarty->display('static_page_about_mary.tpl');
    ?>
    and here is a sample of a simple dynamic page that pulls information from a database:

    PHP Code:
    <?php
    require_once ('config.inc.php');
    require_once (
    'flights.inc.php');
      
    $smarty = new Template;

    // this part gets the data
    $airports $db->getAll("SELECT * FROM airports ORDER BY name");

    // then assigns it to smarty for output
    $smarty->assign('airports'$airports);
    $smarty->display('airports.tpl');
    ?>
    Now in the airports template, I can make the output with alternating row colors like this:

    PHP Code:
    <table border="1" cellpadding="1" width="300" align="center" cellspacing="0">
      <
    tr>
        <
    td class="header">Code</td>
        <
    td class="header">Airport</td>
      </
    tr>
      {
    section name=loop loop=$airports}
      <
    tr
      
    {if %loop.indexis odd}
        class=
    "alt1"
      
    {else}
        class=
    "alt2"
      
    {/if}
      >
        <
    td>{$airports[loop].code}</td>
        <
    td>{$airports[loop].name}</td>
      </
    tr>
      {/
    section}
    </
    table
    trickie
    If you are trying to seperate the content from the presentation then what happens if a client wants to view the same content in something other than HTML? All these 'template engines' are web/HTML specific. That is fine if the information that you have is only ever going to be published for a web browser, but i think that a good 'template engine' should address the issues associated with delivering content to any client that so desires it.
    Smarty and I think any template engine can be used to generate text output for any purpose, be it html, xml, email message, text file, etc.

    Now that's all about smarty from me....

    I am very interested in Vincent's way of creating Application class, and might do it this way on my next project! Thanks vincent for showing me the way!

    Regards
    Jim
    Last edited by FHJim; Aug 22, 2002 at 00:49.
    Fluid Hosting LLC - High Performance Web Presence
    New!! Virtual Private Server
    ICQ: 151540687 MSN: fluidhosting_jim@hotmail.com

  18. #43
    Talk to the /dev/null Theiggsta's Avatar
    Join Date
    Mar 2001
    Location
    Tampa, FL
    Posts
    376
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You obviously didd'nt get what I meant.

    The designer doesnt have complete control of output, only a marginal control using if/else/while statements. Mysql queries are done behind the scenes along with other code that could be called on within the template to allow for the designer to pick what goes on the page and how it should be rendered. To see what I mean, check out patXMLRenderer, the extensions allow you to return database queries, load files/remote content, language support, etc.

    However the simple approach of using classes and objects to do this work is far more practical since there is no overhead of loading some 3rd party system. Thus you can concentrate on your script rather than your template system.
    Aaron "Theiggsta" Kalin
    Pixel Martini
    Ruby and Rails Developer

  19. #44
    As the name suggests... trickie's Avatar
    Join Date
    Jul 2002
    Location
    Melbourne, Australia
    Posts
    678
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by FHJim

    Smarty and I think any template engine can be used to generate text output for any purpose, be it html, xml, email message, text file, etc.
    What i meant is the separation process between design work and data structuring could still be refined.

    Say for instance, you had content that had to be delivered via HTML and PDF, there must be a good way to let the designers specify the design used in the PDF creation AND the HTML creation.

    Maybe there already is a way, i haven't delved to deeply into the templating with PHP arena

  20. #45
    SitePoint Member
    Join Date
    Aug 2002
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think Vincent has the right idea. I've been using an idea pretty similiar to what he is talking about.

    I have it set up into three folders. One for the content - all the text and occasional pictures. Another for the global files - config files, error reports, functions, and what I call the loading constructor. And finally one for the templates - I dissect a page into seperate parts, the title, meta-tags, css, javascripts, body tags, Top part of the html, the navigation, the content wrapper, bottom part of the html, and the imagemap (if there is one). There can be more depeding on what type of modular piece you want to insert, but those are the basics. I know it sounds like a lot, but for me as a designer, this is the easiest way to go. All I have to do is basically design one page in dreamweaver and seperate it out into my sections then I let the loading constructor do the rest.

    How I get it to work is by basing everything off the name of the file - index.php, about_us.php, contact_information.php, etc. The actual file that has the page name is basically a dummy, all the pages have the same two lines of code telling it to load the constructor. When the constructor loads, it determines the name of the page which is easy - $PHP_SELF. Just from that info, the constructor tells it how to layout the page and which html modules to load basically using switch(), include(), a few if() statements and the few html functions I wrote.

    It works fairly well for me, and has allowed me to create my websites extremely fast. Once I have my design finalized and all my images cut up, I can create a 30-50 page website in 1-2 days. I don't really have to bother with the code as much as I did, and I can put more focus on the design which is what I am better at. Granted there is a little tweaking here and there depending on the web-site, but for the most part the code I originally wrote for this hasn't changed. The reason for all this? Well I can basically change the entire look of the website by just making one page in dreamweaver. I can make a site multilingual and wrap a new template around it depending on what language they choose.

    Probably the only real set-back is the fact that it is name based. The content files have to be named the same as the dummy file. And the header files have to be named the same too. Example would be about_us.php which would need a content file called about_us.inc inside the content folder and HDR-about-us.gif in the images folder. But besides that it works great for me.

    I don't claim to be a great PHP coder, because I'm not. I'm a designer and thats what I got my degree it. But I have a good basics of how PHP works and from that and little help from the PHP manual, I've been able to write this thing which helps me work faster. And the people I work for dig it a lot and can't believe that a designer wrote it.

    Good ideas Vincent, and the right track to be on in my opinion.
    --Lycurgus

  21. #46
    SitePoint Member
    Join Date
    Sep 2002
    Location
    Buenos Aires, Argentina
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hello, I'm new to this forum, which I recently found out thanks to some guy from the php.smarty.general list.

    Besides templating, I use Smarty for some other things. As I live in South America, and develop for clients in other countries, my applications has to be multiligual, and multitemplate.
    Multitemplate is easy to achieve with smarty, just generate different sets of templates in different directories, and then extend the class and override the Smarty constructor to accept a parameter to look for templates in the right directory:
    PHP Code:
    class SmartyUsr extends Smarty {
        function 
    SmartyUsr($_template_dir 'Templates') {
       
               
    // Class Constructor. These automatically get set with each new instance.
            
    $this->template_dir $_template_dir.'/';
            
    $this->compile_dir $_template_dir.'/templates_c/';
            
    $this->config_dir $_PHPLIB['appdir'].'configs/';
            
    $this->cache_dir $_PHPLIB['appdir'].'cache/'
            
            
    $this->caching false;
            
    $this->assign('app_name','PTA FO');
            
    $this->compile_ckeck true;
            
    $this->force_compile true;
            
    $this->debug_tpl 'debug.tpl';
            
    $this->debugging false;
            
    $this->default_template_resource 'file:';
            
    $this->autoload_filters = array('post' => array('lang'));        
       }

    You would pass the template name to the constructor, which could be stored in the user profile, cookie, etc.
    Besides using differents templates sets to get differents HTML "skins", as some guy said before, this would be useful to produce differents output formats such as xml, pdf, etc.

    Multilingual is a little bit more difficult, because the easy way would be to assign an array with the string translation just before calling display, but this would be done for every script and very time consuming, because the translations array is usually only one, and in large app would become huge (remember EVERY string in the app needs a translation). Split the array in different subarrays would be a partial solution, since every subarray would probably end with some of the same strings as others.
    So I took advantage of the compiling feature of Smarty, and wrote a couple of plugins which basically parses the {lang} Smarty tag and replaces with the translated string. Since templates are only compiled once if there's no new changes, the translated strings are replaced just once during compile time, thereafter the compiled templates are used. Different languages are achived by passing a different compile_id to the display() function for every language, and Smarty will store the compiled template in a different directory for every language.

    Even with dynamic applications, many pages could be cached for improved performance, but automatically generated. For example, I have one page with a select box from where you can select a country, and based in this selection, another select would be filled with a list of cities of the previoulsy selected country. It's easy to cache the (or have a static) countries page, because countries don't change too often (or do they? ). But to write a static cities page for every possible country, even though is possible, is a pain. So I just let Smarty do it for me, by passing a different cache_id (with the country code) to every call to display(). Smarty will store the cached page (pure HTML here) in a different directory for every country's city list, and directly show this cached for the duration of the cache.

  22. #47
    SitePoint Guru okrogius's Avatar
    Join Date
    Mar 2002
    Location
    US
    Posts
    622
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by Bartimeus
    Excellent example vincent, you should realy consider writing a book or atleast a sitepoint article about this stuff
    I second that.

    One stupid question about those classes... what does teh & symbol before a method name symbolize?

  23. #48
    SitePoint Wizard Mincer's Avatar
    Join Date
    Mar 2001
    Location
    London | UK
    Posts
    1,140
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by Codename49
    One stupid question about those classes... what does teh & symbol before a method name symbolize?
    I signifies that the method will return a reference to an object, rather than the object itself.

    If you want some further reading, there are a couple of articles about php references over at onlamp.

    Matt.

  24. #49
    SitePoint Member
    Join Date
    Sep 2002
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    One mighty educational debate. A couple of points for Vincent.

    Security. You have an application that manages content for the clients, but delegates the presentation layer entirely to them. The application virtually hosts a large number of clients. What is your opinion on an abstraction layer in this case?

    And a matter of taste. You can use PHP for the presentation layer, or you can use a third party module. Whatever you do with one, you can do with the other one as well. Now you also have C, and you have C++. Same rule applies. I leave it to you.

    @+
    D

  25. #50
    SitePoint Member
    Join Date
    Dec 2002
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Smile ASP.NET Clone

    I'm new to this forum. I just so happened to stumble upon this "ranting" thread, when I was doing some research for my project.

    For starters, personally, I like templates, and I have all the credentials that our friend vincent has. I also started programming when I was 12, and I just turned 28 last week. Does that make me older? Hmm.

    Anyway, I eventually got into web developement with ASP, ASP.NET, then PHP. I like all three of them. I like the how robust PHP is, but I like the OO of ASP (PHP hasn't yet allowed the use basic parameters in classes) , and the way ASP.NET does templates. All of these caused me to start my own little "template engine", UltraTemplate, which evolved from one that I created four years ago.

    My goal, at first, was something like FastTemplate or even the touted Smarty, but eventually I came to the conclusion that caching, and all that other good stuff was still not enough, so in a way, I agree with Vincent. So I took another look at what I wanted my "template engine" to do. In Vincent's case, it led him to create his stew of classes. In mine, well, it caused me to start my ASP.NET clone project.

    The things I love most about ASP.NET, like Johansson said, are the way it allows you to easily manipulate the design of a page with special controls, the repeater, datalist, and datagrid being the most powerful. I wanted to have something like this for PHP. After a few tries, I was able to emulate the repeater, not fully, but for me, close enough. Now, I plan to do the other two, and ultimately, once the project is complete, release it as an extension that'll run faster than even Smarty claims to run, which isn't fast at all. It runs faster than FastTemplate, of course, but it's still slow when you compare it to some of the newer alternatives, even mine. http://www.ultratemplate.com/benchmarks/more/ (I didn't add mine to the downloadable file, but if anyone would like the copy that I'm running, just send me an email or post it to my messageboard)

    This isn't a plug. Johansson's posts just caught my eye. Also, if there is anyone out there that would like to help, just let me know. I would like to spend as little of my money as possible on this project.

    Here's where I am now:

    1. I'm rewriting the underlying code of the current script. It doesn't use objects anymore, mainly because I kept having variable scope issues. So far though, the code is smaller, and it runs faster than previous versions.

    2. I'm researching if using XML to parse the tags would be a better idea.

    3. Whether I want to emulate ASP.NET completely and use runat="server".

    4. Whether it should run as an extension to the language of choice or as an extension to the web server. (as an Apache rather than PHP)

    5. What the name of this project should be once completed. "UltraTemplate" doesn't really make a good name.

    6. I'm still working on it by myself. At least the last time I checked.


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
  •