I Believe in Presentation Logic

By Deane Barker on August 23, 2007

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.

What This Links To
What Links Here


  1. I think it’s just a matter of preference. I remember back in the ASP 3.0 days, I’d look at the kind of code structure that was precursor to ASP.NET (mainly coming from Interdev at the time) and hated it. However, now I wouldn’t go back to the scripty presentation loops for anything.

    Once you really embrace the event driven methodology, it becomes effortless. If you spend your time trying to hammer a square peg into a round hole, of course you’re going to be unhappy.

  2. I strongly feel your presentation layer ought to be seperate from your business logic — that’s a no-brainer. But seperating your presentational code from your presentaion logic? That’s wicked-bad inefficient over-abstraction. I’d love to hear someone take the other position — what do you gain by not placing your presentaional PHP code in with your HTML?

    Once someone told me that it helped keep you from being tempted to put business logic in your HTML; but that strikes me as a discipline problem, not an engineering weakness. That’s like saying “you shouldn’t drive because you might be tempted to speed.”

  3. Once you really embrace the event driven methodology, it becomes effortless.

    Dave, I’m sorry, but unless I’m doing something wrong, I’m gonna call BS on that statement.

    To replicate an If…Then in a Repeater ItemTemplate, here’s what I do:

    1. Create a function.
    2. Bind the OnItemDataBound event of the Repeater to that function.
    3. In the function, get the DataItem of the current iteration, and cast it to whatever it really is.
    4. Get references to the PlaceHolder that’s pretending to be an If…Then, and cast it. Also get correctly-typed references to any other controls I might need.
    5. Do my logic.
    6. Change the “Visible” property of the PlaceHolder based on the result.

    If I’ve made a mistake here, please let me know, but I can’t see how that will ever be considered “effortless.”

    Not only does this take time, but now my presentation code is split — some of it is in the ItemTemplate (in the Web form), and some of it is in a function in a completely separate file (the code-behind).

    This blows. An embedded an If…Then would be (1) faster to code, and (2) easier to follow.

  4. Specfic answer to your problem this is not an argument for or against just my solution, which I feel keeps it clean and readable.

    Inside your repeater template, add 1 PlaceHolder for each section and databind the Visible Property to your condition.



    Case 2 Markup

  5. ’>

    As an aside to the main point, I think code snippets like the one above — while necessary in some cases — are kind of funny.

    We’re using server-side code to actually write server-side code (note the tag embedded in the attributes of another tag and the necessity to change the quoting style to handle it). It’s like some crazy-ass reflection with invalid XML as an abstraction layer.

    (I would love it if the ItemTemplate above generated JavaScript. Then we’d be using server-side code to write server-side code that writes client-side code. There’s a rabbit hole somewhere around here we should be falling into right about now…)

    It highlights another thing that mystifies me about ASP.Net — when does everything run in relation to everything else? In this code, the data-binding of part of it (the embedded bit) needs to happen before the data-binding of another part (the Repeater’s data source), since the execution of the second data-bind depends on the results of the first…right? The first data-bind is actually writing code that the second data-bind will use to control its logic.

    More to the point: tell me how the code above is any less complicated than an embedded If…Then. You have to be kidding me if you think that code is somehow cleaner and more noble.

    With ASP.Net, I have never quite been able to figure out when all the different things fire. I’ll admit, however, that this is a personal failing. I’ve been told that understanding the “ASP.Net page lifecycle” is the most important concept to understand in the entire framework. I have not studied this enough.

  6. Ironically, I noticed this article today in the Start Page for Visual Studio:

    Tutorial 11: Custom Formatting Based Upon Data

    Look through that article objectively. The code in there is ten times more complicated and, frankly, ridiculous than any embedded formatting I’ve ever done.

    I realize that high-and-mighty Microsoft thinks this is all so much better and that they’ve done us all a big favor by developing this presentation methodology, but if you look at it dispassionately, it’s tough to see it as anything other than retarded in the extreme.

    We all have preferences and biases, but to think that the stuff presented in that article is any kind of leap forward is patently insane.

  7. If I’ve made a mistake here, please let me know, but I can’t see how that will ever be considered “effortless.”

    You could do that pretty easily with CSS.

    Just have a CSS class for each priority level and assign that to your row’s container’s class attribute using an < %# DataBinder.Eval(Container.DataItem, "Priority") %> in the CssClass attribute.

    If you really need to toggle visibility of a control, you could do something similar with a ternary operator like < %# DataBinder.Eval(Container.DataItem, "Priority") == "High" ? true : false %> as the control’s visibility property.

    I can’t see any reason to even need code-behind for what you’re wanting to do, unless I’m misunderstanding.

  8. Dave, all actual examples and solutions aside, take an objective look at that code you wrote above. Do you honestly think that’s any better than an embedded If…Then statement?

  9. Better? It is an embedded If…Then statement.

    I was just showing you how you could write it the way you want to instead of using the ItemDataBound event.

  10. I just got into this argument with my boss a few weeks ago. The exact same argument. Hilarious. I decided to try using a foreach loop in the front end instead of using a repeater control and was thrown to the wolves for writing in “classic ASP style.”

    I HATE the OnItemDataBound event. ((Button)Item.FindControl(“btnDelete”)).CommandArgument = ((DataClass)Item.DataItem).Id; How can ten million casts for every data item be considered proper?

    ASP.NET attempts to allow programmers to avoid writing anything but C# or VB by putting shit like width and color properties on server controls, virtually doing away with anything resembling web standards or proper purist CSS.

    Someone asked me today why I decided to code a custom tree view control instead of using ASP.NET’s. Short answer: because mine outputs proper markup, allowing it to be styled and accessed by JavaScript.

  11. Deane, in ASP.NET (typically) your code behind is where your presentation logic sits. No business logic should be in the web page’s code-behind; that goes in separate class files. When I mentioned using a helper method, I think you misunderstood; you wouldn’t use the OnItemDataBound event at all. Inside of your repeater, it’s business as usual BUT you’re wrapping a method around your display property.

    < % ShowProperty(#Eval(“Location”)) % >

    Then in the code behind, you’re setting the visibilty of the div surrounding the property based on it’s value. It’s a simple if/then but separated into the code-behind (presentation logic).

Comments are closed. If you have something you really want to say, email editors@gadgetopia.com and we‘ll get it added for you.