Loose Coupling

Andrei » 20 January 2004 » In PHP »

Ryan Norris has written up a good article on the benefits of tiered application development in PHP. As he correctly points out, there is a difference between keeping your logic and presentation completely separate and dividing it along the more appropriate line of business logic vs. presentation and its related logic. I have long been an advocate of this latter approach and a lot of it is reflected in Smarty, at least when I used to work on it. If you developing a PHP application consisting of more than a couple of pages, it would probably be a good idea to read this article and apply it to your project.

Trackback URL

  1. andrei
    Coder
    20/01/2004 at 12:16 pm Permalink

    How come you don’t work on Smarty any more?

  2. andrei
    Andrei
    20/01/2004 at 12:51 pm Permalink

    Because most of the challenging work has already been completed by the time I stopped working on it. Plus, I didn’t exactly agree with some of the enhancements that current maintainers are doing.

  3. andrei
    Coder
    20/01/2004 at 12:55 pm Permalink

    Yeah, I can’t think of any MAJOR changes it might need, except maybe for full-on MVC/Model 2 functionality, if possible.

    What enhancements don’t you agree with? I think the newer object template functions are much much easier to use than the individual separate php file functions.

  4. andrei
    Andrei
    20/01/2004 at 1:08 pm Permalink

    Being able to call object methods from templates, for one.

  5. andrei
    Coder
    20/01/2004 at 1:13 pm Permalink

    Why’s that bad compared to being able to call plain old regular functions? Object functions and vars can be made private with the “_” prefix. I love the object functionality - sooo much more convenient.

  6. andrei
    Ryan
    20/01/2004 at 1:18 pm Permalink

    I think that Smarty is what it is. To try to turn it into some sort of framework would be really altering what the core functionality is. I’ve done quite a bit with Jakarta Struts. It has a great deal of extension points as part of it’s API, which makes it flexible, but it still has to live within a certain set of rules that are imposed through the layout of the API.

    Smarty makes a great presentation layer, and the point of my article is largely that you should be able to interchange each layer. If you attempt to turn Smarty into some MVC/Model 2 framework, I think you’d end up losing some of that. That said - I think it’s a positive that there are PHP-based MVC frameworks out there like Mojavi that are built around Smarty.

    My main contention is that if there is a framework layer to connect the middle and web tier (like Struts), that it should be transparent such that I can interchange that layer and the surrounding layers without drastically re-engineering anything. I’m pretty sure this is why Sun is introducing Java Server Faces as the standard for Model 2 design in the J2EE environment.

  7. andrei
    Ryan
    20/01/2004 at 1:21 pm Permalink

    Calling object methods from within a template == bad.

    That’s what plugins are meant to do. Calling business logic from your templates is bad. Objects in templates should be reserved for accessing DTO’s, and that’s it (if you’re familiar with Java, these are called beans).

    Something valuable that Smarty could look at? I would suggest XML compliant syntax, such that templates can be transformed if an when neccessary. Just an idea.

  8. andrei
    Coder
    20/01/2004 at 1:25 pm Permalink

    So do you use Mojavi (or other PHP MVC framework)? I’ve been looking for one I like. I tried phrame, but, well, I don’t know…

    I thought Faces was just UI components.

  9. andrei
    Coder
    20/01/2004 at 1:29 pm Permalink

    Nah, just because it’s an object doesn’t mean it’s business logic. You could have an object with the following methods:

    get_links()
    get_article()
    get_title()
    get_comments()

    and so on. With individual functions it’s a much bigger hassle - importing global settings, multiple files, registering each function, etc. An object is much much more convenient.

  10. andrei
    Coder
    20/01/2004 at 1:32 pm Permalink

    BTW, is Smarty used at Yahoo? I saw a presentation by Rasmus once, and based on the code he showed, I don’t think he’s a tiered kind of guy ;).

  11. andrei
    Ryan
    20/01/2004 at 1:33 pm Permalink

    I’ve written my own which fits the needs of the apps I work with better than I think a generic framework can. Java has a leg up in terms of being able to accomodate frameworks that require large scale, complex configuration because of the VM.

    Faces is UI, however, the goal is to make it so that people who use Struts or other Java MVC frameworks can interchange Struts for something else without changing their templates (e.g. currently, you’d have to recode your Struts Tag Library stuff to whatever you were changing to, like Velocity).

  12. andrei
    Ryan
    20/01/2004 at 1:38 pm Permalink

    Coder - you example is ok i guess, so long as the contents of those functions don’t do things that belong on the middle tier (e.g. mysql_query(…)). Otherwise, your PHP that does the template work should do something like:

    $links = get_links();
    $template->assign(’links’, $links);

    That way, if you change the template layer, you can override an assign() method that performs the same thing smarty does, and it may not neccesarily disrupt your template, and shouldn’t disrupt your “Action” either. The more I think about it, the more I don’t like the idea of plugins either - but I largely use plugins to write UI components anyhow.

  13. andrei
    Coder
    20/01/2004 at 4:05 pm Permalink

    Hey Andrei - why’s it named “Smarty”?

  14. andrei
    Andrei
    20/01/2004 at 4:30 pm Permalink

    Before Smarty, I wrote SmartTemplate, which was never released. But I think Monte actually came up with the name.

  15. andrei
    Rasmus
    21/01/2004 at 11:34 am Permalink

    Not sure why you would say I don’t believe in tiers. I do indeed. PHP was written to be a templating system specifically to separate the backend business logic from the front end presentation layer. And if you have seen any of my more recent talks you would have seen me present a 4-tiered architecture. Have a look here:

    http://talks.php.net/show/lca04/29
    http://talks.php.net/show/lca04/30

    The difference between this and Ryan’s is that I strongly prefer a template-driven approach in the sense that the template gets control instead of some dispatch script that then chooses a template as in his suggested architecture. Beyond that the architectures and guidelines are very similar.

  16. andrei
    Coder
    21/01/2004 at 8:34 pm Permalink

    I just like to have greater separation and abstraction (Smarty, MVC, etc.). I’ve always disliked combining PHP and HTML together in the same files. I’ve also had many debates with people who say there’s no need for a templating system like Smarty, since PHP is supposedly a templating system. I really like Smarty’s separation - just provide an API of functions and vars to template users, and they don’t need to know/use PHP. Plus features like security, caching, and the plethora of other ready-made functionality.

  17. andrei
    Harry Fuecks
    02/02/2004 at 2:21 am Permalink

    If you’ll excuse the promotion of a project I’ve been involved with, there’s further discussion of templating here: http://wact.sourceforge.net/index.php/TemplateView - it looks at the characteristics of different template engines in attempt to fully define the problem and all the approaches to solving it.

    WACT itself (http://sf.net/projects/wact) is something like a compromise between Ryan’s and Rasmus’s view of templating.

    You still have a script handles an incoming request, then selects a template. From there it tells the template what data sources it should use but it’s the template itself (so to speak) which actually “pulls” in the data, as opposed to the originating script “pushing” the data to it.

    Otherwise the template syntax is mainly declarative - the clearest example right now is;

    which results in the rendering of calendar.