Page Element Attributes in Asp.Net 2.0 and there uses

In asp.Net 2.0 there are many attributes in the page tag itself. Each attribute has a special meaning to it. These attributes are defined in the page so that we can specify them for specific pages. Most of them are also defined globally so that we do not have define them in the page.

Here is a list of attributes of the Page Tag.

asyncTimeout – This is an optional attribute to define the timeout for the asynchronous handler during asynchronous processing of the page. The default value is 45 sec.

autoeventWireup – This is also an optional attribute that defines if the events in the page are automatically enabled. The default value is true. This means

if we define a Page_load(with same signature) method in the page class, the event will be automatically be attached with page load method.

buffer – defines if there will be response buffereing based on URL resource. The default value is true

Compilationmode – This attribute is defined for the asp.net compiler. It defines the compilation model for the page. The values can be Always (meaning page should be compiled every time), Auto (meaning) compiler should not compile the page if possible and never (meaning that the page should never be compiled).

EnableEventValidation – defines if the page controls will be validated in the postback /callback or not.

EnableSessionState - defines the usages of session in the page. Default value is true. Other possible values are false (session will not be saved) and read only (session values can only be read but not written to).

EnableViewState – As the name suggest the tag specifies if the view state will be enabled for the page.

EnableViewStateMac – checks for the authentication of the viewstate. The check is made to check if the viewstate has been tampered on the client side. The default value is true.

MaintainscrollPositiononPostback - Maintains the position of the scroll during post back. The default value is false.

MasterPageFile – Is used to define the master Page for the page (if any).

MaxPageStateFieldLength – This is another optional attribute which takes and int32 type parameter. The attribute is used to define max length of character for the state field of the page. When set to a positive number, the viewstate of the page is broken into many numbers with a max character provided in the field. If the value is a negative number that the viewstate is kept in one variable only. The default value is -1.

PageBaseType – Takes a string value defining the base type that will be used for the bage. The default is System.Web.UI.Page. The value gets overridden by the value in the inherits attribute in the standalone file.

PageParserFilterType - Specifies the type name of a filter that is used by the ASP.NET parser to determine whether an item is allowed in the page at parse time. The filter must derive from the PageParserFilter class.

smartNavigation – determines if the page is going to use smart navigation for IE browser (5.5+). When set to true, in the browser, Navigational flash is eliminated, scroll position is persisted, Element focus is persisted and the history of the browser only stores the last state of the page. The default value is false.

styleSheetTheme – defines the Theme to be used by the page. The theme defined in the attribute is used before the creation of controls.

Theme - Specifies the theme to be used for the page. The theme is applied after the creation of the control.

userControlbaseType – specifies the base type for controls to be used when the page is standalone.

ValidateRequest – Defines if Asp.Net will validate the request for potential dangerous data. Te default value is true.

ViewStateEncryptionMode – Defines the mode of encryption of the viewstate. The attribute will override any default value provided in the configuration value. Possible values are Always, Auto (Viewstate is only encrypted if a controls request for it) and Never. The default value is Auto.

Advantages and disadvantages of ASP.NET Server Controls and HTML Server Controls

Difference between ASP.NET Server Controls and HTML Server Controls

ASP.NET Server Controls

Advantages:

1. ASP .NET Server Controls can detect the target browser's capabilities and render themselves accordingly. No issues for compatibility issues of Browsers i.e page that might be used by both HTML 3.2 and HTML 4.0 browsers code is written in the Server Controls.

2. Newer set of controls that can be used in the same manner as any HTML control like Calender controls. Without any need of Activex Control without bringing up issues of Browser compatibility).

3. Processing would be done at the server side. In built functionality to check for few values(with Validation controls) so no need to choose between scripting language which would be incompatible with few browsers.

4. ASP .NET Server Controls have an object model different from the traditional HTML and even provide a set of properties and methods that can change the outlook and behavior of the controls.

5. ASP .NET Server Controls have higher level of abstraction. An output of an ASP .NET server control can be the result of many HTML tags that combine together to produce that control and its events. Example Gridview or Form control.

Disadvantages:

1. The control of the code is inbuilt with the web server controls so you have no much of direct control on these controls

HTML Server Controls

Advantages:

1. The HTML Server Controls follow the HTML-centric object model. Model similar to HTML

2. Here the controls can be made to interact with Client side scripting. Processing would be done at client as well as server depending on your code.

5. A HTML Server Control has similar abstraction with its corresponding HTML tag and offers no abstraction.

Disadvantages:

1. You would need to code for the browser compatibility.

2. The HTML Server Controls have no mechanism of identifying the capabilities of the client browser accessing the current page.

Using the 'is' and 'as' keyword

Using 'is' and 'as' keyword in C# instead of reflection:

Now a days people are so much relayed on the casting reference types and reflection that they forget the use of the other keyword in the system to work out the same. I support the use of the inbuilt keywords like as and is because they are faster and many a times they also make us rely on hard coding the type of the object.

Reflection is a very powerful tool but it also has some performance degradation as against the inbuilt keywords. Also if we use the inbuilt keywords we don’t have to hard code the type in the code. With reflection to check the type of an object we would write the following code.

if(Variable.GetType() == Type.GetType("System.String"))

Here we are using reflection to get the type of the variable. It has 2 disadvantages. First of all it’s using which has its own performance hit and second that for checking purpose the type of the Variable has been hard coded. We can do the same task simply without using any reflection.

if(Variable is string)

In the above code we are not using any reflection, but still are able to compare the type of the Variable very easily and the code would be extremely fast.

Also while casting a variable to one type we use reflection even when we can do away with it.

myVariable = (string)Request["myVariable"];

can easily be written as

myVariable = Request["myVariable"] as string;

Here if the variable cannot be cast the IL will return a null value. This method would only work for reference type. For value types like int etc we can use System.convert.

Overview of user controls vs. custom controls

Web custom controls are compiled components that run on the server and encapsulate the user-interface and other related functionality into reusable packages. They can include all the design-time features of standard ASP.NET server controls, including full support for Visual Studio design features such as the Properties window, the visual designer, and the Toolbox. There are several ways to create Web custom controls:

You can compile a control that combines the functionality of two or more existing controls. For example, if you need a control that encapsulates a button and a text box. You can create it by compiling the existing controls together.

If an existing server control almost meets your requirements but lacks some required features, you can customize the control by deriving from it and overriding its properties, methods, and events. If none of the existing Web server controls (or their combination's) meet your requirements, you can create a custom control by deriving from one of the base control classes. These classes provide all the functionality like other Web server controls. You only need to write the logic for the programming features you require.

If none of the existing ASP.NET server controls meet the specific requirements of your applications, you can create either a Web user control or a Web custom control that encapsulates the functionality you need.

The main difference between the two controls lies in ease of creation vs. ease of use at design time. Web user controls are easy to make, but they can be less convenient to use in advanced scenarios. Web user controls can be developed almost exactly the same way that you develop Web Form pages.

Like Web Forms, user controls can be created in the visual designer or they can be written with code separate from the HTML. They can also support execution events. However, since Web user controls are compiled dynamically at run time they cannot be added to the Toolbox and they are represented by a simple placeholder when added to a page.

This makes Web user controls harder to use if you are accustomed to full Visual Studio .NET design-time support, including the Properties window and Design view previews. Also the only way to share the user control between applications is to put a separate copy in each application, which takes more maintenance if you make changes to the control.

Web custom controls are compiled code, which makes them easier to use but more difficult to create. Web custom controls must be authored in code. Once you have created the control you can add it to the Toolbox and display it in a visual designer with full Properties window support and all the other design-time features of ASP.NET server controls. In addition you can install a single copy of the Web custom control in the global assembly cache and share it between applications

, which make maintenance easier.

Difference:

Web User Controls:
1) Easy to Create.
2) Limited support for consumers who use visual design tool.
3) A separate copy of the control is required in each application.
4) Cannot be added to toolbox in Visual Studio.
5) Good for Static Layout.
6) If the control you are going to create is only for a particular website then User
  Control is the best option.
7) It's an .ascx

Web Custom Controls:
1) Harder to Create.
2) Full support for consumers.
3) Only a single copy of the control is required in the GAC.
4) Can be added to toolbox in Visual Studio.
5) Good for Dynamic Layout.
6) One Custom control can share diffrent application.
7) It's a .dll