I Believe in Presentation Logic

I believe in presentation logic, I really do. Call me a hack, but formatting logic mixed into your presentation code isn’t necessarily a bad thing.

I started Web development in traditional ASP. And I sucked at it, believe me. I wrote some of the most ridiculously convoluted apps that were absolutely full of business logic spread among HTML. I re-defined the word “trainwreck” in many instances.

Then I got smarter. When I started working with PHP, I learned to have all my logic at the top of the page, set a bunch of variables, and include a “template” PHP file at the bottom which worked off the variables set above it. Not perfect, but an improvement – the PHP to run the app was in one place, and the PHP to render it to a browser was in another.

From there, I found out about objects and started pushing all my business logic off to them. Then I found Smarty – a true templating system – and I was in much better shape. Smarty is great. It gives you a subset of PHP and a handy, easily-embeddable presentation logic. I have more fun developing with Smarty than about anything else.

Then I started working with ASP.Net.

ASP.Net – which I’ll admit upfront that I hate – does things differently. It enforces separation of logic and presentation by having a “code-behind” page for every “Web form” (HTML page). The code-behind is a Web page represented as an object. So all your logic runs in the code-behind, and you “reach through” to the HTML to set certain variables.

This part of ASP.Net is…okay. I don’t hate most of it, except that they take the “no presentation logic” too far in some cases. For example:

You can’t do an If…Then (technically, you can, but it’s considered wicked bad form). What you can do is surround HTML with an “PlaceHolder” tag, then set its “Visible” property to true or false. In fact, you can essentially turn any HTML element “on” or “off” from the code-behind. Same effect…I think (let me think longer, and I might come up with a reason why it sucks…)

This isn’t so bad – the PlaceHolder tag and I have made peace.

But repeating logic in ASP.Net really drives me up the wall, and it’s what prompted me to start this post out with “I believe in presentation logic…”

Here’s an extended example of how limiting the developer’s ability to use presentation logic can really suck –

In ASP.Net there are a half-dozen repeating controls. For example, a “Repeater” allows you to define a block of HTML to repeat, and specify where data gets dropped in the block. Then you take some iterable data structure in the code-behind (a database recordset, a series of XML nodes, an array, etc.) and “bind” it – essentially, you tell the repeater, “Use this data.”

Sounds great in principle, but here’s the problem: you can’t have conditional logic in your Repeater template. You can only drop data in certain spots.

However, I often need to format something differently based on the value of the data in the current iteration (“If the event has an ‘Importance’ of ‘High,' it needs to look like this…”). It’s right about here where things get to be a royal pain because you can’t use an If…Then statement in the Repeater template. You just can’t run logic in there.

What I’ve been doing to date is binding to the OnItemDataBound event of the Repeater, casting my data structure into the correct type, finding references to a bunch of controls in the template, casting them to he correct type, doing my logic, showing and hiding controls, etc. It’s ridiculous.

My .Net-loving friend (from this post) pointed out another way to do it today (using a “helper method”), and that might be a little better. However, it’s still not what I really want to do –

I just want a friggin’ If…Then statement in my HTML!

I’m sorry, complain all you want about mixing presentation and logic, but I can count six hundred or so situations over the last 18 months when a single, solitary If…Then statement would have saved me 20 minutes of coding and Lord knows how much processing overhead. The acrobatics I’ve done to replicate a simple If…Then in a Repeater is sometimes staggering.

Which leads me back to my point: presentation logic isn’t all bad. To understand why, you need to admit something important: sometimes, presentation is complicated. In fact, often times it can be the most complicated thing in your app. Write your object libraries right, and formatting and displaying intricate data on the page makes retrieving it downright pedestrian by comparison.

I wasn’t trying to pick on ASP.Net (yes I was), but my extended example above was meant to demonstrate that when you try to limit presentation logic – no matter how noble your intentions – you can really make things hard. Yes, it’s academically “correct,” but so is eating broccoli, and both those things piss me off.

So long as your business logic – the heavy lifting of your app – is nicely sequestered away in your object model, then logic to render your HTML isn’t going to kill anyone.

In fact, I’ve found that it’s easier to follow well-written presentation logic when it’s all right there and you can see how it interacts with the HTML tags that you see in the rendered source.

In the examples above of putting logic in ASP.Net Repeaters – either using the OnItemDataBound event or a helper method – you separate your presentation logic. To follow what’s going on, you have to keep switching back and forth between your HTML and wherever the rest of the code lies. Instead of the “evil” of mixing business logic in your presentation code, you’re mixing presentation logic with business code. Which is worse?

Rant over. Comments are open – have at me.