Latest: buggy behaviour of parent:: in PHP 5.3.3

Content with Style

Web Technique

Templates from Babel?

by Pascal Opitz on June 4 2007, 09:16

MVC frameworks are in!

With the advent of the MVC framework hype and all its sceptical voices and fan videos side-effects we now see the MVC framework becoming more and more popular to quickly knock out applications. Application scaffolding and various out-of-the-box functions seem to be able to improve development drastically.

I have been using cakePHP recently on 2 professional projects and it definitely has some great advantages, speeding up my development drastically. But some stuff made me feel a bit puzzled, if not disappointed, and that’s the motivation for this article.

Personal observations

First of all, there was a bit of a lost control over the output stream. Views get rendered through an application lifecycle and a flush, for example, just didn’t have the effect that I expected.

Second, I felt that the SQL performance of the database abstraction models just wasn’t that great. I mean, let’s think about this: We do an explain on the table, then we get all the stuff back, then we return the result and use it for rendering. And if there’s a relationship between them, then you have selects for every row to join the additional data in. Doesn’t really cut the mustard, does it?

But what really struck me bad, and this is what I am going to write about in this article, was the views and how the rendering gets done.

But first, how do these frameworks work?

MVC frameworks usually break up the application into database abstraction (model), business logic (controller) and output rendering (view). This, in most cases, is done with a strict naming convention that has been put in place to make changes easier and the development process faster. To find out more you can read the Wikipedia article on this subject or just google for more

Why Layer Separation?

So why did people come up with layer separation and what do they usually think it is good for?

  • Each layer can be maintained without changes affecting the other parts of the application layers
  • Separate testing of each layer is possible, i.e. through Unit tests
  • It is possible to swap a layer for something different, i.e. MySQL against PostgreSQL
  • It often is easier to find the individual files when they need to be changed (Ruby on Rails calls this “Convention over configuration”)

A look into how we are rendering the view layer

We look around …

Starting my look around with cakePHP, I found that the views are embedding inline PHP that is able to call any framework method or custom PHP script. And that’s a lot. Have a look into the cakePHP cheat sheet and you’ll see what I mean.

Researching other frameworks I found that the same approach goes for most of them. Let’s have a look at a Ruby on Rails example, found on ONLamp.com :


<%= select("recipe", "category_id", Category.find(:all).collect
{|c| [c.name, c.id] }) %>

The same goes for Django, a python based framework, this time using curly brackets:


{% block content %}
<h1>{{ section.title }}</h1>

Discussing this amongst the CwS writers and other developers reveals that most frameworks offer some kind of mechanism to push data to the template from the controller so that direct method calls can be avoided. Examples would be the Partials in RoR or the $controller->set() method in cakePHP.

Still, those mechanisms are language and framework specific.

... and find a lot

So the situation we’re facing is that every individual framework has an different way of rendering the view templates.

Most solutions either incorporate the scripting language directly (i.e. cakePHP using inline PHP calls), are framework/CMS specific (i.e. TypoScript) or non-standard (i.e. Smarty).

Just the evaluation of these is already a pain, even when we restrict ourselves to a somehow narrowed down field of research, i.e. “MVC based frameworks in PHP”.

We want power …

Having script languages available makes template rendering extremely powerful. And there are good reasons for why we find those powerful mechanisms in the view rendering process: To introduce script calls into the template rendering itself usually happens because there is a need for more than just straight output, but somehow more complex processing like conditions, loops, includes or sorting.

... but get confusion?

As we could see earlier, when we looked into different frameworks, we often have function calls directly from the view itself. Sure, it is a powerful mechanism to render templates, but is it a really clean approach?

One of the most common arguments against using PHP is that its leading to spaghetti code . Most people that bash PHP pull out the “it’s just HTML with messy script tags” card first thing, and in my opinion they are right to say that this leads to an unmaintainable state.

Introducing inline code into the view rendering can cancel out the benefits of layer separation. If, for example, during an update process, parameter counts or method names get changed, we have two revise the views as well, otherwise the view could lead to a script error.

Even more drastic would be a port to another language. If we use a native scripting language like inline PHP or inline Ruby, we basically have to bin the whole application and do a complete rewrite. The view will not be reusable at all.

There are other ways.

Seaside for example, a Smalltalk based Framework that follows a very different paradigm, doesn’t contain any templates, but renders markup through methods only. This definitely seems drastic to most people, so it does for me, but I have to admit that it is a very clean approach.

Are standards an alternative?

Talking standards there are only a couple of techniques that spring to mind that offer interchangeable and platform-independent functionality… These being XSLT and XSL-FO.

XSL Transformations offer the power to do processing of any complexity if needed. XSLT parsers are available for most platforms out there, including PHP, ASP, ASP.NET, Python and many more.

So what do I think?

What I don’t really understand is why, after going to the trouble of creating system where model, view and controller are nicely separated, one would come up with a mixture of controller functions and markup in the view, that renders all the valid points above obsolete.

I am not sure if this is a misconception on my side when I digested the term “Layer separation”, but embedding inline PHP or script calls to controller methods in my eyes is a bit similar to putting inline styles into XHTML pages. They become less maintainable.

As mentioned above, we have the W3C standards that offer all the power we need for more intelligent template rendering. XSLT cuts out the learning curve for another proprietary template language, it’s powerful and it’s cross platform. Yet I see hardly any serious CMS or Frameworks embracing those official W3C standards available outside of the enterprise sector.

The only XSL based free blogging system I currently know about is Symphony but there might be others.

Where is the web going?

I recently ask myself this question more often than usual. Whereas a couple of years ago the web seemed to be aiming for better standards, with XHTML and XML/XSLT being the way out of the mess, the outlook nowadays seems much more clustered, diverse and maybe even confusing.

The current focus seems to be rapid development and AJAX integration, the new buzz word is Web 2.0, coming along with whole new variety of Frameworks, Libraries and Communities that bring new life to the web community. All this is very good.

But I think that in a bigger question we have to ask ourselves is: Why forget the old merits? Sure, frameworks and libraries can help to cut down development time, but can they cut out knowledge of the core techniques?

And yes, a big variety of techniques to choose from is great. Yet, is this the reason to disregard well defined standards and end up with a babble of languages and approaches, all adding to the initial learning curve?

If we go for a certain framework and technique now, but later the popular paradigm changes into something else, will we have to abandon most of what we’re using… or can we carry some standardised parts over to the new platform?

In any case, what we work with is down to each individual developer and the requirements of the individual project.

I hope I have highlighted some valid points in this article and am looking forward to your feedback.

Comments

  • You’re right on the money—templates should not contain business logic. And, by extension, business logic layers should not contain markup.

    I’m not very enthusiastic about XSLT-based solutions—I think XSLT is incredibly difficult to write, much less read, esp. for translating angle-bracket-delimited languages. I guess it’s just me, since there’s a ton of XSLT out there.

    The best templating engine I’ve seen that addresses these concerns is StringTemplate—its main intent is to maintain MVC layer separation, as detailed in the canonical whitepaper.

    Unfortunately, it doesn’t seem to have been ported to PHP….

    by Val on June 4 2007, 17:09 - #

  • Val, thanks for the comment. I think XSL is one of the easiest things to master once you get used to the weird tags, and it might be worth to give in another go?

    While the whitepaper on highlights a lot of things that came to my mind even more elaborately than I managed, StringTemplate itself and your comment on it actually serve as a good example why I think we need techniques like XSLT.
    The manual is massive, and you cannot jump right in. I’ve never heard about it before but it’s part of an ocean of template engines. Last but not least you said yourself that it hasn’t been ported to PHP, yet.

    by Pascal Opitz on June 4 2007, 17:31 - #

  • I find XSLT to be a logical extension to XML and XHTML. Not only does the syntax follow XML, but how you perceive the data is also the same (recursive and tree-like branching structure).

    At the core of XSLT, there are only a few instructions that are fundamental to understanding the concepts behind the language. The functional (rather than procedural) aspect of XSLT is also big, big plus.

    To me, the perfect templating language is one that naturally understands the structure of XML and XHTML, and XSLT fits the bill here perfectly – understandably so since it’s a language developed by the same group for all said lanuages.

    ...but naturally, I am biased :)

    by Allen on June 6 2007, 03:54 - #

  • Quick and dirty comments.
    The best tool is the tool that you can perfectly use.
    1. Since we have http protocol and html standards, every single one should stick around this basically.
    2. MVC helps to manage medium to large!!! software projects.
    We can choose JSF or Flex or any X way, but should always remember KISS. MVC frameworks helps at this point. I don’t have to reinvent session handler library for every new app. Just inherit and use it, this is OOP power. Thats why i am using cakephp for a medium size apps and Spring + JSF (and needed add ins) for a large enterprise apps with Java. Java already came up with tags solution and also Tiles, for a large web apps.
    3. To me, the problem is the quality of the coder. If you can understand OOP and business related requirements, well you can go with any language on presentation layer. Logic is already separated, therefore, web designer designs base skeleton of the site with choosen standars and pass that work the coder with good documentation. If youre skilled coder you can handle the job at this point. Cakephp have a best decision since they give php power back on presentation layer at this moment. After 23 years, when i see that some solution come with an idea to make our lifes easier, only adds more headache (like smarty). Things become more and more complex and life is getting harder.
    4. Sorry but, i hate all x*l based solutions. I am following rfc’s since sgml times and i’ve never have a good feeling for this garbage conversion thingies. The idea is safe data conversion and healty conversation between platforms. Of course we can use some techniques in some parts of app, but all of them seems like a temporary solution to me (viva la JSON for ajax). If i have to write my own data transfer format, i can write my transfer engine too. Always we’ll have the same story on conversion, vendor specific bugs, version conflicts blah blah. No thanks, i’ll stay away and trying to find easiest solutions like REST.

    Finally, we need to talk about qubits and future of computing, but talking about same all story more and more and more, cheers :)

    by kunthar on July 4 2007, 04:27 - #

  • Kunthar, thanks for the post and apologies for the delay …

    A couple of points in your post:
    Following the KISS principle, if you have to deal with multiple platforms for doing MVC style, RESTful apps, how does it help that all those have a different template language?
    Sure, you are free to hate anything basically, but I cannot really see how there’s a clash between an XSLT based rendering of the view and REST? After all, you need to output characters for the HTTP response. The REST principle for the application is neither violated by the usage of XSLT based templates for the response output, nor by using a non-standard template language like Smarty.

    While I completely agree with you that, if you understand what OOP is and the business requirements etc. the coding of an app with any language and templating engine should be feasible, I was merely advocating the use of W3C standards for at least the templating side of things, as we would not have to re-learn something for this step everytime we get thrown into a new environment.

    Also, with template languages like the one used by cakePHP, the controller logic is NOT separated from the view, at least it doesn’t have to be. And again, that is leading into a concern of mine: An army of newbie programmers that grab a framework and start doing push-style code for their applications …

    by Pascal Opitz on July 8 2007, 06:18 - #

  • Thank you for response, let me explain some more;
    1. xslt, “which is a language for transforming XML documents into other XML documents*.” I can use it to transfer data between two different domains. But template engine is another story. Adopting the xslt to the template system is would be a choice but not my choice, because;
    a) If i have to interpret parts of html, i can easily use my own, faster translation engine on page when i need, besides, you can check that, w3c not always offers well shaped solutions and not a final technical authority for me.
    b) The main question is, who writes the code inside of the presentation layer? This is you and me, coders and coders can use the tools can easily manage. Php itself can be used like a very powerful template engine and what else i need to convert from xml to something again and again and again? cakephp already offers view, layout and element fragments to make things simple. Web designers always separated from our working scope. They have totally different thinking style. Let them go and do their business by using their own way. On the other hand, MVC not helps to unify all my work. If i have to code with Java, sure i have to use it’s own platform and abilities and vice versa. There is no easy unique way to reuse code between projects. xslt is not an exception.
    c) MVC itself has a paradox in separation of the layers. This is not quite easy to totally separate controller from view, even in Java too. The answer is not xslt based template system to me on this situation.

    What would be an alternate solution?
    Well, use or create same tools and have vast experience on them. Follow a man criticise about template engines and shows us his own template engine. Basically, if i am talented enough, i do not have to deal with someones ideas, i can write my own, that’s it.
    RIA is knocking our door and we have to follow native GUI abilities on our web apps too.

    And finally, hope an army of programmers could find and start with true OO frameworks to code like cakephp. They could then understand the true world reality, refactoring of the problems and tie things up with power of OOP.

    by kunthar on July 9 2007, 14:03 - #

  • Kunthar:
    Point taken, and you are free to disagree.

    I, for my part, fail to see any benefits in the usage of proprietary, self-coded template languages other than maybe some speed improvement.
    I do see various benefits in utilizing XSLT for rendering templates. But most of them I already mentioned, and if things work better for you in another way, then there's no reason not to stick with it …

    For the last point: I hope that people that start coding with these new frameworks start looking into them and see the weak points as well, so that they know where and how to introduce some custom stuff in order to improve the app. The web standards movement did quite a good job, and I think we witnessed a huge improvement in quality of HTML code during the last couple of years. If the frameworks get people into using stuff and not abusing stuff, theres no reason to be concerned. It would be a shame if they get people to step away from caring about standards, accessibilty and best practice.

    by Pascal Opitz on July 9 2007, 17:46 - #

  • I totally agree with you,
    As soon as every single ticket handled, continuously well documented, explained and the idea improved on that frameworks, i will give my hand to do something better on. You know, every frog swims in nicely boiled water, can swim :)

    by kunthar on July 9 2007, 19:19 - #

  • There is a New PHP MVC Framework with an integrated AJAX CMS at: http://macs-framework.sourceforge.net/

    by Mac on December 2 2007, 14:30 - #

Leave your comment

Comments are moderated.
Tags allowed: a, strong, em, code, ul, ol, li, q, blockquote, br, p

Advertisement
Advertisement