Login Skip Navigation LinksWilsonWebPortal > Forums Search
Download WebPortal Download WebPortal
Download and start using the full WebPortal completely free, including the source for the basic modules so you can see how to create your own if the included modules aren't enough.

PayPal Subscribe
Get It All for $50 USD:
WebPortal, ORMapper,
Source Code, All Updates
PayPal

User Login User Login
Log In
 
 
Reset Password

Wilson WebPortal Forums Wilson WebPortal Forums : Advanced Topics : How does ASP.NET know what page to call?

Date Post
4/28/2006 9:10:13 PM Hello Paul

Thank you very much for sharing your WebPortal code, I have been reading it for a couple of days. However, I still feel confused about the life cycle of the framework.

Usually, we hard code the .aspx pages and put them in the server. When a user request a page, the ASP server will find the page and write its content to the user's
broswer. Now in your frameworks, everything is generated dynamically from the database. When a user request a page, it will first go to AppBase class, then Controller.DeterminePage() get the page object (assume the the page can be found in the database). The Controller class also store the current page request to the HttpContext.Current.Items property.

The PageBase class gathers all the rest information about the page and then display it to the user's broswer.


My question is: Who sits in between
AppBase class and PageBase class? Is that PageHandlerFactory class? If yes, how does the PageHandlerFactory call the object of PageBase class?

I hope I made myself clear.
Thanks a lot

Yin
4/28/2006 9:40:11 PM Hi Yin:

The key is the HttpContext.Current.RewritePath method that you will see called.  This is typically referred to as "Url Rewriting" and it is used by many web apps, including most portal apps.  You'll actually find that this technique of not having separate physical aspx pages is a very common architecture for data-driven web apps.  Anyhow, to answer your question, you'll notice that the last line in Controller.DeterminePage calls context.RewritePath("~/default.aspx").  That means that every request is internally "redirected" to execute the default.aspx page in the application root -- the one page that does physically exist, and which does also inherit from the PageBase class.  You'll find nothing else inside the that default.aspx page, since its just a stub to get things to work -- other options, like a custom PageHandlerFactory, could have even avoided that one page, but there's also no reason for additional complexity.  Does this make sense?

Thanks, Paul Wilson

5/1/2006 1:14:49 AM Hello Paul

Many thanks, it all makes sense now.

Yin