Thanks for the Disposed explanation and the IHttpModule tip!

Two short articles that explains how to do what I want with IHttpModule (for
any other interested readers):
[url]http://www.15seconds.com/Issue/020417.htm?voteresult=5[/url]
[url]http://msdn.microsoft.com/msdnmag/issues/02/05/asp/default.aspx[/url]

- Tormod

"Graham" <graham@NOSPAMtecskor.com> wrote in message
news:ueuG6hJRDHA.2432@TK2MSFTNGP10.phx.gbl...
> Tormod,
>
> Disposed is called whenever the garbage collector feels like getting
around
> to it. Or never, if it doesn't need to. Not a good choice for anything
> other than disposing resources. Unload is a much better choice.
>
> Consider looking at IHttpModule interface. It might allow you to better
> accomplish some or all of what you are doing. IHttpModule lets you
> introduce processing in the "pipeline" that handles the user request and
> response before and after pages handle them. In otherwords, before a page
> is even instantiate to handle a request you can do processing with an
> IHttpModule and after a page is finished (in otherwords later than Unload
> event of Page) but deterministically as opposed to Dispose that you cannot
> predict when it will be called.
>
> So, basically a page is an endpoint of a request and an IHttpModule is one
> of a series of objects in the pipeline for processing the incoming request
> and out outgoing response. You could create am IHttpModule class that did
> everything you want to do. Also, IHttpModules are added to the pipeline
by
> configuring in web.config so, if your IHttpModule is not a necessary part
of
> your processing and is useful you can add it to other web applications by
> adding it/them to web.config and they will work regardless of the
> application (*some conditions apply). And of course you can remove an
item
> (say one for debugging) from the pipeline by just removing it from the
> web.config.
>
> Regards,
> Graham.
>
> "Tormod Hystad" <thyATkomplett.no> wrote in message
> news:eWcPRRJRDHA.2476@TK2MSFTNGP10.phx.gbl...
> > Quick intro: I'm making a base BasePage class that extends S.W.U.Page.
> This
> > page will contain the common functionality for all our ASP.Net pages
(all
> > their codebehind pages will extend this BasePage instead of the regular
> > Page). In BasePage, I want to be able to do "something" as early as
> possible
> > and "something else" at late as possible in the pages lifecycle, but
> > before/after anything is done in the derived classes. Examples of things
> > I'll want to do to in BasePage are: Customer site usage tracing, page
> > timing, logging, security.
> >
> > #1 I read that the Disposed event was the last thing that happened, but
> when
> > I try:
> > (in the constructor) this.Disposed += new
> > System.EventHandler(this.Page_Disposed);
> >
> > with this method:
> >
> > protected void Page_Disposed(object sender, System.EventArgs e)
> > {
> > log("Page_Disposed G <"+this.GetHashCode()+">: " +
> > System.DateTime.Now.Ticks);
> > }
> >
> > NOTHING happens when I view the page. Page_Disposed is never called.
(The
> > Unload event works great, though, used in the exact same way). Not
> > devastating, but I would like to know why Disposed seems to not work,
> might
> > learn something!
> >
> > #2 I would also like to append some debug info to the Response html,
after
> > all normal page processng is done, but before the page i sent to the
> client.
> > The thought is that when a global Debug is enabled, every page in the
> system
> > wil show timing info ++ at the bottom. I've not been able to add
anything
> > like this to BasePage, there seems to be no way the base class for a
> > codebehind class gets access to the Response after any dervied classes
are
> > "done". When UnLoad is triggered, it is too late. PreRender is too early
> > (everything you write to the Response there is shown at the top of the
> html
> > page). Any suggestions?
> >
> > #3 I've experimented my way to this design as the best:
> > BasePage has private Page_Load and Page_UnLoad methods where I do my
> common
> > stuff and in the constructor registers to listen for the Load and UnLoad
> > events with these methods. Any derived classes may or may not have their
> own
> > Page_Load/Page_UnLoad eventhandlers.
> >
> > This means that Load and UnLoad may trigger several eventhandlers,
should
> > not be a problem. Can you see any other potential problems I haven't
> thought
> > about?
> >
> > (The first design I tried had virtual protected Page_Load/UnLoad
methods,
> > and regisered the eventhandlers in it's constructor. Derived classes had
> to
> > override these if they wanted a piece of the Load action, BUT they also
> HAD
> > to say base.Page_Load(), so that "my" Page_Load got to run. If the
derived
> > class also registered a eventhandler for Load to call Page_Load, I ended
> up
> > with two calls that did the exact same thing. Not a great design...)
> >
> > - Tormod
> >
> >
>
>