490 likes | 1.42k Views
Anatomy of an ASP.NET Page. My Version of the Big Picture (1). Server. Your application. ASP Worker (Engine). Runs. Other applications. Request. Response. Session 1. Session 2. Client (Browser). User 1. User 2. My Version of the Big Picture (2). Server. User Controls.
E N D
My Version of the Big Picture (1) Server Your application ASP Worker(Engine) Runs Other applications Request Response Session 1 Session 2 Client (Browser) User 1 User 2
My Version of the Big Picture (2) Server User Controls Your ASP.NET application ASP Pages Master Page(s) contains Content Page(s) HTML Docs Web.config Site.master
What is an ASP.NET Page? • Roughly speaking, an ASP.NET page contains • Markup (appears in the .aspx page) • Server-side code that the ASP.NET worker executes (appears in the .aspx page or in a separate code behind page) • The resulting HTML is sent out to the client (browser) by the asp worker process
ASP.NET Coding • There are two ways to do it • Inline (code appears in the same file as the .aspx file) • Put in a <script> block with runat=“server” • Separate code behind file • This is what I generally do
ASP.NET Code Behind • They are matching .aspx and .aspx.cs files that are hopelessly tied together • @Page directives are important • The CodeBehind attribute points to the .cs file • The Language attribute identifies the programming language • VB / C#
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 System.Web.UI.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 and is handled by ASP.NET itself
IIS File Mappings • .asax – application files • .ascx – ASP user controls • .asmx – Web services • .aspx – ASP.NET Web pages
IIS Process Models • Hosting prior to Windows Server 2003 uses IIS 5.0 • Later versions use IIS 6.0 or IIS 7.0 • In this class, we will assume and use the IIS 7.0 process model but for the most part it will not matter
Processing Directives (1) • 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 %>
Processing Directives (2) • Processing directive are used to configure the runtime environment • Processing directives have the following format: <%@ directive_name attribute=“value” attribute=“value” %>
Processing Directives (3) • Processing directives are used to • Describe the page itself (@ Page) • Describe a special type of a page called a master page (@ Master) • Control caching (@ OutputCache) • And more • We’ll refer back to these as the course progresses
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
Processing DirectivesPage Compilation • 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
Processing Directives(Page Output) • Most of these directives relate to localization and multiple cultures • ClientTarget allows pages to be rendered for a specific browser
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)
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”
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
Page Life Cycle (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 so you CAN reference them in code
Page Life Cycle (Init Event) • 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 • Note that view state has not been restored yet
Page Life Cycle (InitComplete Event) • Here, view state tracking is turn on • The event fires only for the page • PreLoad event • System initialization is complete • We don’t typically do much here • The event only fires for pages and not controls
Page Life Cycle (PreLoadEvent) • System initialization is complete • We don’t typically do much here • The event only fires for pages and not controls
Page Life Cycle (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 • We won’t work with dynamic controls here • Use IsPostBack to check whether the page is being loaded in response to a postback or new page
Page Life Cycle (LoadComplete Event) • LoadComplete fires after Load • At this point, the page begins its rendering phase • We don’t generally do much here
Page Life Cycle (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
Page Life Cycle (PreRenderComplete Event) • Raised only for the page after PreRender has fired for all child control instances
Page Life Cycle (SaveStateComplete Event) • It fires for all constituent controls and then the page itself • Any changes made will not be persisted after this • Next, the markup is generated
Page Life Cycle (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
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
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
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 (discussed in Chapter 5)
Folder Structure • So far, you have seen a project from an empty template • Now for a real one
Folder Structure • You get many template files and folders for free • All this gets compiledon the server to makeup an ASP.NET app
Folder Structure • App_Code is designed to store shared code files (classes, .wsdl pages) • App_Data is designed to store data files • Users can read and write data in this folder • The folder Scripts is not magical but we store JavaScript and jQuery here • Note that the jQuery scripts are copied here by default from the standard template
Global.asax • Global.asax is the global application startup, shutdown, and error file • It contains procedures that are called by the application infrastructure • Application_Start called when the application gets its first request • Application_End not used much • Application_error to handle all unhandled errors
The Class Designer • This is not really and ASP thing as it is a .NET thing • It lets you build the prototypes for the various class parts