Monday, October 26, 2009

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.

Monday, October 19, 2009

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.

Friday, October 16, 2009

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.

Tuesday, October 13, 2009

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.

Sunday, October 4, 2009

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.

Sunday, September 27, 2009

Chapter 4:Lesson 1

  • Server-side state is secure but not quite scalable.
  • Client-side state is quite scalable but not secure.
  • Persisted state means saving state information into a database. Can be utilized if database server is heavy.
  • Shared state means storing copies of commonly accessed data on the server (caching) so that the server does not need to process page (or part of page) for every request.
  • ViewState stores object data that is not already represented as HTML in the page response.
  • Page.ViewState property is a Dictionary of type StateBag.
  • Object values on a page are hashed, compressed and encoded into Unicode string and stored using one or more hidden HTML fields (depending on how Page.MaxPageStateFieldLength is set)
  • ViewState includes MAC (Message Authentication Code) used by ASP.NET to check if it has been tampered with during the round trip.
  • ViewState can also be made to encrypt data, both on website level and individual page level.
  • For website level, we may enable viewStateEncryptionMode to Always in web.config, and for page level we set this value to Page directive of the page we want it encrypted for. (Page 189)
  • EnableViewState property on every server control allows for turning on/off ViewState management for that control.
  • ViewState and ControlState are handled as two different values in ASP.NET 2.0 and above. ControlState manages how a control would keep its appearance during Postbacks and therefore a control may still contribute to page size even if EnableViewState is set to false.
  • ViewState does not transfer from one page to another.
  • All Serializable objects can be embeded in ViewState.
  • ControlState cannot be disabled for a control and is used specially in case of custom server controls. (Refer back to Page 192)
  • Hidden Fields may also be used in place of ViewState, except that the Value property of a HiddenField control is not hashed, compressed or chunked nor does it support encryption.
  • Furthermore, HiddenField values would be accessible on server only if page is sent via POST method (and not GET method). So they won't work if user clicks on a Hyperlink on the page.
  • ASP.NET uses Cookies to maintain user sessions.
  • Cookies can be temporary or permanent. To make a Cookie permanent we set its Expire property. To delete a Cookie we may set Expire to a past date.
  • Like Session variables, Cookies need not necessarily be added to the Response.Cookies using Add( ) method. They may also be created using something like
    Response.Cookies["lastvisit"].Value = something;
  • Path property of the HttpCookie class may be used to restrict Cookie access to pages from a specific directory. Similarly, Domain property may be used to restrict Cookie access to a specific domain.
  • Typically, 20 cookies (each of max 4 KB) are allowed per site.
  • A single Cookie may contain multiple Key-Value pairs, e.g.
    Response.Cookies["pref"]["color"] = Color.Blue;
    Response.Cookies["pref"]["lang"] = "en-us";
  • When using QueryStrings, some browsers restrict URL size to 2083 characters which may become a problem. Moreover, QueryStrings require page submission using HTTP GET method.
  • Tip: Always validate values from QueryStrings.
  • QueryStrings provide advantage of maintaining state when users bookmark or email a URL. Typically URL should be limited to 70 characters to enable it to be sent via plain text email.
  • Tip: Always HtmlEncode( ) values from QueryStrings and Cookies, so that client-side scripts may not get processed.
  • Passing HTML code to a QueryString throws HttpRequestValidationException (if not disabled by web server administrator)

Monday, September 21, 2009

Chapter 3-Lesson 2

  • We may use Hyperlink control to enable Client-side Navigation within the page. No data is posted to the newly requested page, so we may need to use QueryStrings.
  • Page.PostBackUrl property is used for Cross-page Posting.
  • When a cross-page post is made, data from first page is posted to the second page. The second page may access that data using Page.PreviousPage property.
  • We may use properties to encapsulate controls on a page so that they could be accessed from another page as strongly typed values during a cross-page posting.
  • To access such porperties in the posted page, add PreviousPageType directive after the Page directive and set its VirtualPath attribute. (Page 169 for exact usage)
  • Response.Redirect( ) method is used to cause a Client-side Browser redirect. This is similar to using Hyperlinks as the browser is sent an HTTP 302 message with the URL to redirect.
  • Server.Transfer( ) method is used to cause a Server-side Page Redirection. PreviousPage property is populated for the new page in this case.
  • Sitemap class is used to access Web.sitemap (or other such) files from code. It has three properties namely Title, Url and Description.
  • Menu, TreeView and SiteMapPath are three navigational controls that use Sitemap files.
  • SitemapPath connects itself to the Sitemap file automatically. It can be put on a masterpage where it could check (automatically) current page on which it is displayed and show its bread-crumb trail.