Categories: "Full Stack Dev & Design"

Why I consider (MVC) Smarty templating inefficient

Most PHP developers (and other web developpers too) seem to evolve on a similar path which goes like this:

Step 1: take HTML pages an add PHP tags into them.

Step 2: Realize that on a large scale this is getting very hard to maintain.

Step 3: Learn about the MVC (Model View Controller) paradigm and begin to think it's cool.

Step 4: Use Smarty or another templating engine like that.

The way most of those templating engines work is basically this:
a) Do a ton of PHP processing in the framework and fill in variables.
b) Call smarty and let it fill in variables in a template.
c) Send the output.

The issue here is that during steps a and b, nothing is sent back to the user. The user is just waiting for a response. Sadly enough, steps a and b will take a lot of precessing time. So the user will wait quite a long time before he gets any feedback on his action.

Even worse, when the application gets bigger, step a will take even more time!
And the more complex page you request, the more time you'll be left in the dark...

This is why I don't like all those mainstream templating engines. I want to send output back to the user as soon as possible. I want to send the page header at the begining of step a. And as soon as something has been processed and is ready for display, I want to send it out.

The global processing time will be approximately the same, but if the user sees content begining to display immediately, instead of all the content displaying at once 2 seconds after clicking, he will get the (false but humanely useful) impression that the application is faster. (Please do not say AJAX here, it is so not my point :P)

I'm not saying MVC is a bad paradigm, I'm saying most implementations of MVC are flawed, and Smarty is the most common example of this in PHP. Because they do the M & C stuff and then they do the V (view) stuff at the end. In my opinion they definitely need to interleave all this a lot more.

In evoCore (b2evolution's framework) our approach is to have the Controller really control the processing flow. In other words: for every block of information the View wants to display, the Control will process data from the Model and immediately pass it to the View in order to display the result block by block.

Of course, this has drawbacks: you won't be able to change the block order of the output if it's hard coded into the Controller. But really, that's okay to some extent. Who really needs to move the global header and the global footer for example? This is what we use for the back-office.

However, for the front-office, we want more customization, and we want people to be able to rearrange blocks in any order. In this case we have a little more complex processing, where the View actually calls the controller everytime it needs to display something.

Anyway, in any situation, my point is: the View should not be handled last.

Efficient vs. effective

Guy 1: I am so efficient I can fold 100 parachutes in a hour.

Guy 2: I am so effective I can fold 100 parachutes and every single one of them will open right.

Would you rather give your parachutes to the efficient or to the effective guy?

Now what I'd like to know is why all these programmers we interview pride themselves on being efficient?

I'm so sick of their industrial strength bug generating skills... :/

iPod podcast listening frustration

Today, I've got this massive stack of clothes to iron... bleh :(

To make the experience a tiny little bit more pleasant, I'm listening to every podcast on my iPod I hadn't listened to yet...

Great time to catch up with all that stuff... but great frustration too!

A typical podcast has an average length of 15 minutes. And when the iPod is done with playing it, it just goes back to the main menu. Yes, that's the MAIN menu, not the podcast feed you where in, not the podcast menu either! It's all the way back to the main menu!

So you need to drill down into the podcast menu again and then into the feed you were listening too, select the next podcast you want to listen to and then, finally, you can continue to listen...

Wouldn't it have made sense for the iPod to automagically playthe next episode in the feed I was listening too!? Isn't the whole podcast concept somewhat supposed to mimic a radio with better programs? Do you need to click on your radio in order to listen to the next show?

Apple seems to have thought this through... at some point... but only halfway I guess: you can actually press play when a podcast feed is selected and the whole feed will get played. But in this case you'll suffer 2 major problems:

  • You'll listen to the feed in reverse chronological order. And you'll hear feedback on the previous episode before you hear the referred to episode! :(
  • You'll listen to everything, including the episodes you've already listened to before...

This second point is something else that has been bugging me for a while: there's no way you can see on your iPod what episodes you've already listened to and which ones are new.

Each episode definitely needs a 3 state icon in front of its title, indicating wether it's unplayed, partially played or completely played.

Testing web applications

Client Side Testing

Note to myself: unit testing is a great thing and I should do it more, I plan to do it more. But, unit testing is not enough...

What we need for web applications (or complex dynamic web sites if you prefer) would be something like this: the TEST program would act like a regular web browser, executing javascript and all the rest. The main difference with a web browser would be that the TEST program would be scriptable.

You could script it to log in, enter data into forms, perform search requests, check that the requested data appears on the screen, etc... You may even want to compare the generated HTML with a prerecorded excerpt. You may want to tolerate differences like white spaces and may be even non structural tags (ignore spans, styles attributes, etc...)

Of course, you'll want the TEST program to validate the XHTML output as well as the CSS styles.

Advanced testing would involve sending onclic events to specific objects on the page and see how the javascript behaves.

You'd have different scenarios you could run in sequence to fully test your application.

Even better: you could run multiple scenarios concurently (you'll need cookie isolated client threads for this) in order to stress load your application and record response times.

God, I gotta stop dreaming about it and find that gem...


I found a few potentially interesting tools here:

  1. Puffin Automation Framework. Open Source. [No longer exists]
  2. QEngine WebTest. Free / Commercial. [No longer exists]
  3. WAPT Web Application Testing. $ 250.
  4. WebKing. Commercial.
  5. OpenLoad. Commercial. [No longer exists]
  6. Web Performance Load Tester. 499 € +.
  7. iMacros. $30 - $499.
  8. eValid [No longer exists]

Mucho later:

There's more than the code...

Oh well... I think it's been too long since I last read some great wisdom like the one on Joel on Software.

I read this really insightful peace today about all the important things beyond just the actual software code.

Here's a funny quote:

Human emotions can be really, really superficial. In particular people ridiculously overvalue aesthetics and beauty when evaluating products. It's one of the reasons iPods, and, for that matter, Keanu Reeves, are so successful.

...but the whole article is definitely a must read!

Of course, this so much applies to b2evolution as well... :-/