I've seen it in many applications. I've even been guilty of it in the past. But how did it get started? I'm talking about the applications that look like the following:
protected void Page_Load(object sender, EventArgs e)
{
if (!Page.IsPostBack)
{
}
}
Why in the world do we do this? Developers that check if (Page.IsValid) are just as guilty. If you haven't figured it out I'm talking about using the Page property of the ASP.NET Page class.
If you're not familiar with the ASP.NET framework, you have System.Web.UI.Control which is the cornerstone of all visual aspects in ASP.NET. All visual elements inherit from that base class, including the ASP.NET page itself. The control class has a Page property which references the System.Web.UI.Page class which contains the control. In the case of the Page object, the Page property just returns itself.
Whenever we use Page.IsValid or Page.IsPostBack on our page we are saying "give me the page of this page and then check if it is valid" when we could just say IsValid or IsPostBack since then we would say is this page valid?
This is not something I've only seen once or twice, I've seen it on almost every ASP.NET project I've worked on. I have seen every developer I have ever worked with do this. But why would so many people choose to use Page.IsPostBack instead of just IsPostBack? I could understand one subset of developers doing this but it almost seems universal.
Out of curiosity I broke out Professional ASP.NET which is the oldest ASP.NET reference book I had available to me (Publshed June 2001) and I took a look at the IsPostBack section. Sure enough everywhere they gave sample code, it was Page.IsPostBack! Are these the guys to blame for this? Does anyone have a better reference that shows this behavior? I don't have access to the old MSDN documentation from the 1.0 days.
Next time we come across the Page.IsPostBack why not change it to Page.Page.IsPostBack or even Page.Page.Page..IsPostBack? If that's too confusing maybe we could try this.Page.Page.IsPostBack. There are endless possibilities here.
How did this happen? Am I off base here? Is this not as wide spread as I seem to think it is? Is it just my bad luck in the experiences I have had? Have people noticed this on other projects as well? Please tell me it is not just me!
--John Chapman
4 comments:
To piggie back off of this, if you are using strongly typed MasterPages, in order to get to the methods on or properties on your strongly typed masterpage, you must use the THIS keyword. Using Page.Master simply returns you a reference to the normal MasterPage and not your strongly typed master page.
Page.isPostBack does not nessecerally referring to the particular page in memory rather a new instance to a page class. I agree with Flipp, you should use THIS keyword.
Anonymous, you are wrong. The Page property of a System.Web.UI.Control refers to the Page that owns the control. It will never generate a new instance of the Page class (unless you write your own custom control and override this property)
Thanks, great post.
Post a Comment