question about the "Page Controller" pattern

[cmay]

In reading some documents from the Patterns and Practices group, I had
a question about the example given for the Page Controller pattern.


(I have posted the code for the BasePage below)
In short, their example shows a "BasePage " class for other pages to
inherit from.

The subclasses are supposed to implement the PageLoadEvent method
(which I guess should really be abstract, but can't because asp.net
won't let you inherit from a base page that is an abstract class).

Now, my question is this. I have seen many applications where the base
page, and the inheriting pages BOTH subscribe to the Load event, w/ the
Base class's event handler firing first, and then the subclasses Load
event handler.

In execution, it would work the same as what is described here, with
the only diff being that Page Controller would be intiating the Load
event on the page, rather than ASP.NET initiating the event.


Can someone explain why this matters? I guess if you were passing some
kind of information from the Page Controller to the sub class on the
PageLoadEvent method, but if you are doing just to "kick off" an event
that is already going to be kicked off by ASP.NET, what is the point?


Thanks...


Here is the Page Controller class:



using System;
using System.Web.UI;
using System.Web.UI.WebControls;
public class BasePage : Page
{
protected Label eMail;
protected Label siteName;

virtual protected void PageLoadEvent(object sender, System.EventArgs e)
{}

protected void Page_Load(object sender, System.EventArgs e)
{
if(!IsPostBack)
{
string name = Context.User.Identity.Name;
eMail.Text = DatabaseGateway.RetrieveAddress(name);
siteName.Text = "Micro-site";
PageLoadEvent(sender, e);
}
}

}

 

[Joerg Jooss]

In reading some documents from the Patterns and Practices group, I had
a question about the example given for the Page Controller pattern.


(I have posted the code for the BasePage below)
In short, their example shows a "BasePage " class for other pages to
inherit from.

The subclasses are supposed to implement the PageLoadEvent method
(which I guess should really be abstract, but can't because asp.net
won't let you inherit from a base page that is an abstract class).

Now, my question is this. I have seen many applications where the
base page, and the inheriting pages BOTH subscribe to the Load event,
w/ the Base class's event handler firing first, and then the
subclasses Load event handler.

In execution, it would work the same as what is described here, with
the only diff being that Page Controller would be intiating the Load
event on the page, rather than ASP.NET initiating the event.


Can someone explain why this matters? I guess if you were passing
some kind of information from the Page Controller to the sub class on
the PageLoadEvent method, but if you are doing just to "kick off" an
event that is already going to be kicked off by ASP.NET, what is the
point?

One reason why a base class and a derived class would subscribe to an
event is that both need to handle it without needing to know
a) that the other one handles it
and
b) how the other one handles it.


Thus there's never a requirement for a derived class to call the base
class implementation, which you must do for many framework event
handling methods (On<Event>).

But overriding methods is a dangerous thing -- you need to make sure to
fullfil the base class's expectations -- either it wants you to call
its own implementation, or it doesn't care, and in the first case you
must amke sure to call it at the correct point in time (start of
method, end of method, anywhere).

And there's no language construct to enforce either behaviour -- it's
purely driven by documentation.

This brings us to your code sample -- PageLoadEvent is a Template
Method, an extension point of a base class for modifying behaviour as a
child class sees fit.

In your BasePage example, the event handling aspect and the Template
Method server practically the same purpose, so I don't see any reason
to use both approaches at the same time.

Cheers,

 

[cmay]

Thanks for the reply.

I understand that you would not use both methods, but guess I am
questioning the reason for presenting this pattern for asp.net
development. (Why MS Patterns and Practices like this pattern).

It seems like you don't "gain" anything over simply using a custom base
class that doesn't bother calling a PageLoadEvent method, letting the
ASP.NET process raise that event.

Also, if you were to use the Page Controller method how could you have
an inheritance tree of more than 2 items deep? If each Page Controller
assumes that the class inheriting from it will implement the
PageLoadEvent method, wouldn't you hit a road block if you tried to
have 3 classes?

e.g. If you just build rely on ASP.NET to fire the PageLoad and catch
that at each level, then you could have:
BasePage (PageLoad does generic stuff)
SpecificFolderBasePage (PageLoad does stuff specific for its section)
EndPage (PageLoad Sets up the page)

but if you tried to do this same thing with the Page Controller, I
don't see how you could do it. In the SpecificFolderBasePage, you
would need a method PageLoadEvent to contain logic for when it is
called by BasePage, and also expect EndPage's PageLoadEvent to be fired
later, which wouldn't happen.

What I am trying to say is "SpecificFolderBasePage" and "EndPage" can't
both declare a method called PageLoadEvent have have the execution
propagate down the tree like you would need it to.

 

[Joerg Jooss]

Thanks for the reply.

I understand that you would not use both methods, but guess I am
questioning the reason for presenting this pattern for asp.net
development. (Why MS Patterns and Practices like this pattern).

It seems like you don't "gain" anything over simply using a custom
base class that doesn't bother calling a PageLoadEvent method,
letting the ASP.NET process raise that event.

The sample code is somewhat contrived. They implement a base class
version of Page_Load to provide the common page header -- that's why
Template Method is used, to provide a hook for derived classes to add
their own logic without accidentally removing the page header logic.

Also, if you were to use the Page Controller method how could you have
an inheritance tree of more than 2 items deep? If each Page
Controller assumes that the class inheriting from it will implement
the PageLoadEvent method, wouldn't you hit a road block if you tried
to have 3 classes?

Yep, this may bring trouble -- you need to thoroughly document who does
what with which side-effects, or provide yet another template method...

The point here though is that deep inheritance trees are evil anyway ;-)

e.g. If you just build rely on ASP.NET to fire the PageLoad and catch
that at each level, then you could have:
BasePage (PageLoad does generic stuff)
SpecificFolderBasePage (PageLoad does stuff specific for its section)
EndPage (PageLoad Sets up the page)

but if you tried to do this same thing with the Page Controller, I
don't see how you could do it. In the SpecificFolderBasePage, you
would need a method PageLoadEvent to contain logic for when it is
called by BasePage, and also expect EndPage's PageLoadEvent to be
fired later, which wouldn't happen.

What I am trying to say is "SpecificFolderBasePage" and "EndPage"
can't both declare a method called PageLoadEvent have have the
execution propagate down the tree like you would need it to.

They can, but this leaves with you with the original problem: Do you
need to call the base class's implementation? In this situation,
Strategy is a more useful Design Pattern.

Cheers,