SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 57 of 57
  1. #51
    SitePoint Enthusiast
    Join Date
    Nov 2009
    Posts
    82
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    RE> "Your criticisms here are a straw man.....snipped....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."

    Content in templating systems is still not in any way separated from logic. Now it's wrapped in yet another messy system and syntax. I find they make debugging more difficult.

    I see this as a post tables-layout-era HTML specific issue. With templates, if you want to re-arrange a layout, fiddling with tpl files is seldom enough. You have to grep blindly through PHP libraries to find all the places that tpl was used.

    There are more intuitive and less clumsy ways to map div contents to the codes that produce it. I predict (five years from now) templates will be like Corba. Time will tell.

  2. #52
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    988
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by pittendrigh View Post
    Content in templating systems is still not in any way separated from logic. Now it's wrapped in yet another messy system and syntax. I find they make debugging more difficult.
    I don't understand 'content' here... in 99% of cases the content will be coming from a data source such as the database.


    I see this as a post tables-layout-era HTML specific issue. With templates, if you want to re-arrange a layout, fiddling with tpl files is seldom enough. You have to grep blindly through PHP libraries to find all the places that tpl was used.
    I'd argue the exact opposite.. with templates you can update 1 file and affect everywhere it's used without needing to worry about the display logic running it.

    Two examples:
    -An added field 'Also include the RRP in product lists'. With reusable templates, I make 1 file edit and include the new variable appears everywhere the template is used.

    -Change the requirements 'Don't show products which have been out of stock for over a month'. Change the logic in one place and it affects all templates which use the logic. The same logic can be used for templates for search results/category listings/products by manufacturer/similar products/etc even if the layout of each page is entirely different because they use different templates.

    Without this clear separation of logic and markup I need to locate and edit every instance of a list of products... messy.

  3. #53
    Non-Member
    Join Date
    Dec 2010
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by furicane View Post
    There are template engines that actually separate html from php without implementing logic in "template" files.

    I hated smarty from the day I tried it and I was always wondering why would anyone use it since you're forced to learn some weird syntax that's so similar to php - so why not use php from the start?
    Good advice, I agree (I hated it, too).

  4. #54
    SitePoint Enthusiast
    Join Date
    May 2001
    Posts
    26
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by PCSpectra View Post
    There are two big reasons why I would use Smarty over alternative syntax:

    1. Template inheritence - yes you could re-implement that functionality using but why bother?

    2. If you need to allow clients the ability to update templates safely without running arbitrary code.

    It promotes some questionable practices, such as formatting dates in the template layer, but as a tradeoff I think it also handles any concern for XSS?!? I'm not 100% certain on that last part but its one moire thing to consider.

    Like any tool, there are times to use it and others not. Be frustrated with the previous programmer(s) not the library they chose - even that is subjective.

    Cheers,
    Alex
    Good points. Also, the tag-based syntax does have good use-cases.

    Example:

    Smarty:
    Code:
    {$title|lower|escape}
    PHP:
    Code:
    <?php echo htmlspecialchars(strtolower($foo),ENT_QUOTES,'UTF-8'); ?>
    To a PHP developer, PHP statements are of little concern. However for a web designer or non-programmer, the tag syntax is a huge welcome with plain english words.

    Is Smarty for everyone? Nope, and it never claimed to be. Much of this boils down to your own requirements: if you have PHP developers managing templates, a tag-based syntax may be of little importance. For a web designer or non-programmer, the latter is a huge welcome. Where the benefit really comes into play: such as a CMS/Wiki where templates are edited via a web interface by Joe Shmoe. Content with {tag} placeholders are by far easier to read than PHP statements, less error-prone, and minimize the learning curve.

    Of course templates can be abused with poor implementations. It should go without saying that Smarty still requires a level of competency from the developers and designers.

    It seems (by browsing around these forums) there is basically a one or two man army on a rampage against Smarty. I'm all for constructive criticism, but please backup your points. Bug ridden? By all means, point them out!

    As for the isset() concerns, this is certainly a known one and is being addressed. Check the dev forums for discussions on that topic. As of Smarty 3.0.5, the templates simply follow the PHP error reporting level or you can set a Smarty-specific one.

    Cheers!

  5. #55
    SitePoint Addict bimalpoudel's Avatar
    Join Date
    Feb 2009
    Location
    Kathmandu, Nepal
    Posts
    279
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks mohrt, it is pretty good to see you in Sitepoint Forums.
    Smarty 3.0.x really looks beautiful.

    As I am using Smarty since its early days, the change was really adaptable.
    It has really become flexible as well.

    For other users, if you simply hated Smarty without organizing it correctly, please consider revising its manual first. Even the .chm distribution of old version still works as a good reference. However you are always free to dislike it if you think using Smarty causes poor design in your architecture.

    I don't even suggest to write non-reusable smarty plugins, because it is likely to contain a major part of your business logic.

    @TomB:
    Regarding the data sources, you can directly assign your database objects and access them in a template loop to save time and memory. But still pulling unnecessary data (that you may not show in the page) isn't good again.

    The concept behind Smarty is very good. Rather we can discuss on what would have made it even easier to use, without having to confuse with normal programming or other general template engines.

    Hope to see you everyone using a template engine comfortably.
    Bimal Poudel @ Sanjaal Framework over Smarty Template Engine
    ASKING INTERESTING QUESTIONS ON SITEPOINT FOURM

    Hire for coding support - PHP/MySQL

  6. #56
    SitePoint Enthusiast
    Join Date
    May 2001
    Posts
    26
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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>
    Interesting stuff. However, how is this so different from:

    Code:
    {if $returning_user} 
    Welcome back {$user.name} 
    {/if} 
    
    {if $unregistered_user} 
    Welcome, Guest, Please login or register. 
    {/if}
    Does this not implement the same concept of separation? Or are you thinking of some further control from the business side, like manipulating/replacing content within the block?

  7. #57
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    988
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    At it's most basic level yes. registered_user has become meaningless outside the template. This is a good thing because it's no longer rooted in business logic. The meaning within the template can be updated and affect only the template. Consider it like a CSS class name, although meaningful in CSS it has no bearing on the data or structure of the element it's describing.

    As I said previously, it's not an issue with PHP syntax vs custom syntax but one which is often ignored. However, custom syntax template engines are in a better position to provide an eloquent solution.

    Consider this basic example (demonstration only...):

    PHP Code:
    interface TemplateRule {
        public function 
    process(Template $template);
    }


    class 
    TemplateUserCheck implements TemplateRule {
        protected 
    $user;
        
        public function 
    __construct(User $user) {
            
    $this->user $user;    

        }

        public function 
    process(Template $template) {
            if (
    $user->isLoggedIn()) $template->showSection('returning_user');
            else 
    $template->showSection('unregistered_user');
        }
    }
    //...
    $template->addRule(new TemplateUserCheck($user)); 
    I'd really go for a mix of a push/pull approach as I explained in post #16 for reusability purposes, but as a simple example that should give an idea of what I mean.

    By completely decoupling the display logic from the template you have two way reusability, both the templates and the logic behind them. This also adds an otherwise impossible degree of testability.


    Or are you thinking of some further control from the business side, like manipulating/replacing content within the block?
    It adds the possibility. look at my reusable pagination example. That's a case of reusable logic rather than strictly separation of concerns, but it's that separation which allows for reuse.


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
  •