Category: "PHP"

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.

Web application caching

Blogs, as most current web applications, need to address the server-side caching issue in order to reduce webserver load.

It looks like most people are quite happy with caching static versions of their pages for some defined amount of time. This method has often been called something like "half-baked/half-fried" in reference to the long running baked (static) versus fried (dynamic) discussion.

I'd actually call it "baked on demand"... but regardless of what name we use, I would not be satisfied with this.

I have actually done some experiments caching my blog homepages which is enough to significantly reduce load, but this really makes them too static for me. I do want to log some stuff in realtime, I do want new user comments to show up instantly, and most of all: I do want the page to be customized for each user: display new posts since last visit, display his personal choice of categories, etc... Caching a whole page for every possible combination seems plain stupid. (And it is! :>> )

Actually, the only smart caching mechanism one can be satisfied with in high-end web-applications is block-caching. As a matter of fact, a web page can actually almost always be considered as an assembly of different blocks. Some are static, some are dynamically updated several times a day, some are related to the user himself and some are so dynamic they change everytime the page is displayed, no matter what! By caching each of these blocks individually when it makes sense and rebuilding only those necessary at a given time, you can then reconstruct your whole page dynamically significantly faster than if you had to reconstruct all blocks from scratch every time.

And there you have it: performance and functionality. Yeah, Okay, I know... it's also much more complex to implement than any other caching mechanism... ;D

PHP oddities :(

Actually I had not really looked into PHP since early version 3 betas... I knew it had gotten better, but sometimes I wonder if I didn't overestimate this... :-/

Looks like PHP 4.3 still requires that you name a collection of checkboxes or a select multiple with a name ending with "[]" such as <input type="checkbox" name="collect[]" value="3" />. That [] makes it impossible to DOM-handle the objects with javascript... but if you don't include the [], you just won't get all the checked values, neither as a table nor as a list... only the last one! :!:

What year is this? 1995? :'(

As far as I remember, ColdFusion and ASP have been handling this elegantly since version 1.0!