Jeffrey Palermo (.com)

Sponsors

The Lounge

News

Advertisement

Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Code-behind versus Design-behind versus Code-beside - level 200

Anders Norås' posted an interesting article about the intent of code-behind.  He says doing:

<TITLE><%# GetResourceString(“PageTitle”) %></TITLE>

is better than doing this:

public class MyPage : System.Web.UI.Page {
     protected HtmlGenericControl Title;
     private void Page_Load(object sender, System.EventArgs e) { 
          Title.InnerText=GetResourceString(“PageTitle”);
      }
}

On my team, there is much discussion about putting any function call int the aspx file whatsoever, so this strikes me as an interesting take.  Honestly, I do a mixture of both, but in the above case, I do exactly what the second code snippet does.  I do all programmatic manipulation in my code-behind file.  I try to have only markup in my aspx and ascx files. 

In v2.0, I imagine I would do the following:

public partial class MyPage{
      private void Page_Load(object sender, System.EventArgs e) { 
          Header.Title = GetResourceString(“PageTitle”);
      }
}

And I really don't agree that setting content in code is a bad thing to do.  If I was forbidden to do it, I would not be a very effective programmer at all.  For instance, I use a base page class to set the title of every page in my application.  There is no way that I am going to put a function call in the markup of every aspx just to set the title when I can do with one call in my base page.  That just doesn't make sense. 

Anders, your method works well for mostly declarative pages, but I disagree with you.  I prefer the code method.


Posted 08-19-2004 4:50 AM by Jeffrey Palermo

[Advertisement]

Comments

Anders Norås wrote re: Code-behind versus Design-behind versus Code-beside - level 200
on 08-19-2004 9:46 AM
There is no such thing as one solution to all problems. In some scenarios it would make the most sense to set top-level page properties such as the title, target and similar in code. I believe that this is an exception and not the rule. If it is more of a rule, such as with generated titles in ASP 1.x, where master pages aren’t supported. I would consider injecting or altering the HTML code for the TITLE element in an HttpModule. This would separate the presentation rules from the content.
This would of course be more difficult to develop than a extension to the System.Web.UI.Page class, but you would benefit from this in the long run since it would make the application easier to maintain.