Anatomy of an ASP.NET Page

1. Anatomy of an ASP.NET Page

2. Compiling an ASP.NET Page • An ASP.NET page is compiled when it is rendered for the first time • A page is compiled to a class that derives from Page • Parse the .aspx file and create a class that derives from Page • The preceding class is then compiled to an assembly • This process is transparent

3. Compiling an ASP page(Illustration)

4. IIS File Mappings • .asax – application files • .ascx – ASP user controls • .asmx – Web services • .aspx – ASP.NET Web pages

5. Processing Directives • Processing directives are used to configure the runtime environment • Directives can appear anywhere on a page but best practices dictate that they appear at the beginning of the page • Directives begin with <%@ and end with %> • Make sure you don’t forget the %>

6. Processing Directives • Processing directive are used to configure the runtime environment • Processing directives have the following format: <%@ directive_name attribute=“value” attribute=“value” %>

7. Processing Directives (@ Page) • It can appear only in .aspx pages • Attributes are divided into roughly three categories • Compilation • Page behavior • Page output • There are other tools to configure the same options beyond processing directives

8. Processing DirectivesPage Compilation • See Table 3-5 on page 104 for a complete list • CodeFile lists the file containing the VB or C# code for the .aspx page • Language describes the programming language for the CodeFile • ClassName explicitly sets the name of the class created upon compilation

9. Processing Directives(Referenced Assemblies) • Most assemblies are automatically provided by the compiler • Assembly references can also be added using the @Assembly directive • Assembly references can also be added in the web.config file

10. Introduction to the Page Class • The Page class provides the basic behavior for an ASP Web page • It’s objects allow you to reference • The application itself (Application) • The server itself (Server) • The HTTP request (HttpRequest) • The HTTP response (HttpResponse) • The user’s session (Session)

11. Page Class Properties (1) • Controls returns a collection of controls on the page • IsPostBack indicates whether the page is being loaded in response to a postback or is being loaded for the first time • PreviousPage returns a reference to the caller page • Only meaningful in case of a cross-page postback • Check IsCrossPagePostback

12. Page Class Properties (2) • ClientTarget allows you to specify the type of browser • Note that automatic browser detection is disabled • EnableTheming and Theme allows you to set page themes (more later) • MaintainScrollPositionOnPostback allows the page position to be persisted from one postback to the next

13. Page Class Methods (1) • DataBind binds all data bound controls to their data sources (more later) • Validate causes validation controls to validate their data • SetFocus sets input focus to the desired control instance • There are methods to work with client script

14. Introduction to Page Events • First, this topic is very important to getting your ASP applications to work • ASP uses the eventing model to • Persist state from one postback to the next • Create static and dynamic controls • Bind control instances to data sources • And much more • As your book says “state is an illusion of continuity”

15. Page Life Cycle (1) • When a page is requested • The runtime figures out why the page is being processed • Normal request • Postback • Cross-page postback • callback

16. Page Life Cycle (2) • PreInit Event • It’s the first event in the page life cycle • Master page has not been associated • Themes have not been associated • It’s possible to change master page or theme association at this time • IsCallback, IsCrossPagePostback and IsPostBack are set at this time • Control instances have been created

17. Page Life Cycle (3) • Init Event • Master page and theme have been set and cannot be changed • Child controls are initialized and the ID is set • Child controls are initialized recursively • Init event fires for all child controls before the event fires for the page itself

18. Page Life Cycle (4) • InitComplete event • Here, viewstate tracking is turn on • The event fires only for the page • PreLoad event • System initialization is complete • We don’t typically do much here

19. Page Life Cycle (5) • Load event • The event is raised first for the page and then recursively for all child controls • You can access control properties and view state at this time • Create dynamic controls in this event • Use IsPostBack to check whether the page is being loaded in response to a postback or new page

20. Page Life Cycle (6) • LoadComplete fires after Load • At this point, the page begins its rendering phase

21. Page Life Cycle (7) • PreRender event • Fires for the page first and then recursively for all controls • Use to update controls before the output is rendered • PreRenderComplete event • Raised only for the page after PreRender has fired for all child control instances

22. Page Life Cycle (8) • SaveStateComplete event • It fires for all constituent controls and then the page itself Next, the markup is generated • Unload event • After rendering, the event fires for all control instances and then the page itself • Use this event to close files or database connections