Chapter 6-Lesson 1

• In Client-Server model, a thin client is one where most processing is done on server, while a thick client is one where most processing is done on the client.
• Every ASP.NET AJAX page should contain one ScriptManager control.
• This control is reponsible for generating Microsoft AJAX Library code for the client.
• If a page that uses AJAX controls, contains a ScriptManager, it would conflict if the page uses a masterpage that also uses a ScriptManager. To overcome this, use ScriptManagerProxy control inside the child page.
• Similarly use ScriptManagerProxy for User Controls that use AJAX, so that they may not conflict with any ScriptManager that is present in the page that employs the User Control.
• UpdatePanel control defines areas of the page that are able to send Asynchronous Postbacks to the server.
• Setting UpdatePanel.UpdateMode property to Always denotes that its contents will be updated on every Postback (partial or complete) that occurs from within the page.
• We may set the UpdatePanel.UpdateMode property to Conditional so that it updates its contents upon certain conditions, e.g. in case of nested UpdatePanels as described in Page 334.
• Another way is to call the Update( ) method on the UpdatePanel from server-side code. (This might be done during another Async Postback)
• By default Nested UpdatePanel (whose UpdateMode is set to Conditional) will not cause update to the parent UpdatePanel. To enable this, set ChildrenAsTriggers property of the outer UpdatePanel to true.
• We may assign different trigger controls to an UpdatePanel using either markup () or using properties pane.
• If an error occurs during an Async Postback, it may be handled using the AsyncPostbackError event of the ScriptManager control.
• All the content is place inside ContentTemplate control within an UpdatePanel.
• UpdateProgress control present inside an UpdatePanel ContentTemplate would render as a hidden div in the resulting HTML.
• By default the UpdateProgress control shows up on every Async Postback. To associate it with a particular UpdatePanel, set its AssociatedUpdatePanelId property.
• We may also change the DisplayAfter property to number of milliseconds for the UpdateProgress after which it would show up following the Async Postback. (This defaults to half second)
• PageRequestManager class contains abortPostBack( ) method which may be used to cancel a partial postback if called from a control within UpdateProgress control.
• Timer control is used to execute certain code (at Tick event) on the client on periodic basis. If it is placed inside an UpdatePanel, the TimeInterval property will be reset after the UpdatePanel postback is complete. If placed outside, it will be reset as soon as the event is fired.
• In case a postback is in progress if the Tick event fires, the first postback is cancelled.
• The Timer control can also be used from outside an UpdatePanel to trigger it for Async Postback.

Chapter 5-Lesson 3

• Webparts are components within a webpage that can have their own personalization, positioning and event systems.
• Any control can be a webpart.
• Using webparts on ASP.NET pages requires ASPNETDB (a SQL Express) database to be used which keeps track of user personalizations for specific webparts.
• Webparts are placed inside WebpartZone controls that define an area within a page that contains or may contain webpart(s).
• Within WebpartZone control we need a ZoneTemplate to allow us to place standard controls within a zone.
• Webparts may be created by simply placing standard ASP.NET controls or even a user control inside the ZoneTemplate. The WebpartManager will take care of the rest.
• A WebpartManager control (non-visual) is required on every page that uses webparts (or any controls present in System.Web.UI.WebControls.Webparts). It handles events and other stuff related to the Webparts.
• Webparts may be displayed in various modes allowing users to view, design and even edit the webpart.
• We may switch between different webpart display modes by setting DisplayMode property to one of SupportedDisplayModes collection values of the WebPartManager class.
• Webparts within a same page may connected statically or dynamically.
• Static connections are the ones that are defined by the developer and cannt be modified or removed by the user. On the other hand, Dynamic Connections are modifiable by users.
• To create a static connection, we create a Provider class, a Consumer class and then tell the WebPartManager control about these two using StaticConnections markup within WebPartManager markup.
• The provider class should have a method decorated with ConnectionProvider attribute. Similarly, the consumer class should have a method decorated with ConnectionConsumer attribute. The value returned by the Provider method would go as argument into the Consumer method.
• For dynamic connections, all we need is to add a ConnectionsZone object to the page and enable the user to switch to Connect mode using WebPartManager. Once in this mode, the user can create or break connections between any existing Provider and Consumer.
• Personalization is enabled by default for WebParts, and it uses client-side Cookies to match the user with his/her record in ASPNETDB.
• If we wish to disable this personalization, we need to set WebPartManager.Personalization.Enabled property to false, either by using code or markup.
• We may also allow some users of the site to apply changes to WebPart page in such a way that the changes are visible to all users. This is called Shared Personalization.
• To enable Shared Personalization, we add authorization tag within section of web.config file. Then we define allow tags to specify which users are allowed to do what to our page.

Chapter 15-Lesson 2

• An ASP.NET Theme may consist of .skin files, CSS files and images.
• Themes are stored at the root of the Application in App_Themes folder.
• Themes are applied at page level using Theme/StylesheetTheme attribute in the @Page directive, or at site level using pages Themes/StylesheetTheme attribute in web.config file.
• Skin files specify settings for ASP.NET controls while CSS files specify settings for HTML elements.
• A skin may be applied to either all the instances of a particular control (default skins) or applied to specific controls (Named skins)
• In case of named skins, we set the control properties in the skin file and give it a SkinID. Later on whichever control in the .aspx page matches the SkinID attribute with the named skin would conform to that particualr skin.
• Theming at various levels follows precedence as mentioned on Page 284.
• We may disable themes for a particular page by setting EnableTheming to false in @Page directive.
• Page.Theme property may be used to change the theme programatically during Page_PreInit event.

Chapter 5-Lesson 1

• Masterpages derive from Masterpage and have a @Master directive.
• ContentPlaceholder can also be placed in the head section.
• asp:Content tag defines the substitution content for a ContentPlaceholder in Page that derives from a Masterpage.
• Everything (except the Page directive) inside an ASPX page that derives from a Masterpage should be enclosed within a Content control.
• Settings on the masterpage usually take priority over settings made on content pages.
• Masterpages may be applied at individual page level, folder level or entire web application level. This is done respectively using @Page directive or pages section in web.config file.
• Content pages can reference/access public properties defined in the Masterpage class.
• @MasterType directive should be defined in the content page where masterpage properties need to be accessed. This enables the use of Master class to access Masterpage's public properties.
• We may reference Masterpage controls from within content pages using Master.FindControl( ) method.
• Events first get fired for Masterpage and then for content page.
• Masterpages can be nested into one another.
• Page.MasterPageFile property may be used to switch masterpages programatically. We only need to make sure all the different masterpages provide exactly same number and names of content placeholders to ensure compatibility.

Chapter 4-Lesson 2

• Application State and Session State are the two Server-side State Management options available in ASP.NET
• Page.Application is of type HttpApplicationState.
• Request for an ASP.NET page is processed by ISAPI (Internet Server Application Programming Interface).
• ApplicationManager is an AppDomain that manages all the execution for a single ASP.NET application (including global variables).
• HostingEnvironment class allows access to resources (such as files and directories) inside a hosting environment.
• HttpContext, HttpRequest and HttpResponse are the core objects used to process any ASP.NET page request.
• Application is started by using (or re-using an existing) an Instance of HttpApplication. When this instance is created objects/modules such as SessionStateModule also get loaded.
• This Application object serves as the pipeline for all application execution.
• An Application can have one instance of Global.asax (Global Application Class)
• Application_LogRequest event is fired when a request is made to the Application.
• Since Application object can be accessed by more than one page (running on different threads) at the same time, its always a safe practice to use Application.Lock( ) before altering any Application State values.
• Application object is a collection with members of type object, therefore boxing is required.
• Session state is scoped only to current browser/user and only available to that session.
• Session object is of type HttpSessionState.
• ASP.NET_SessionId is a cookie containing a 24-byte value to keep track of session.
• Setting SessionState mode property to OFF in Web.config would improve performace.
• Values stored in Session must be serializable.
• Page directive also contains an attribute to enable/disable session state for individual pages. This can also be set to ReadOnly.
• Sessions can be configured to be Cookieless.
• ASP.NET would raise Session_End event only when state mode is set to InProc.
• InProc mode keeps session data in server memory and is the default state mode.
• StateServer hands over state data to ASP.NET State Service which preserves data between Application startups and multiple servers. This Service is present on all IIS Servers but set to manually start by default. To use it we must set its startup to Automatic.
• SQL Server also preserves session state data but on SQL Server database. It also requires connection string in web.config when configured for use.
• Profile properties are also scoped to current user.
• However, Profile properties are always persisted in SQL Server database (and not in server memory)
• Also, values stored in these profiles can be strongly typed objects.