Setting Web Server Control Properties
Most Web server controls inherit from the WebControl class. All Web server controls must contain a unique (at the page level) ID attribute value to give you a way to programmatically reference the control. The other attributes and properties of a Web server control are used to control the look and behavior of the control.
Common Web Server Control Properties:
AccessKey The keyboard shortcut key. It can specify a single letter or number that the user can press while holding down Alt. For example, specify “Q” if you want the user to press Alt+Q to access the control. The property is supported only in Microsoft Internet Explorer 4.0 and later.
Attributes A collection of additional attributes on the control that is not defined by a public property, but that should be rendered in the primary HTML element of this control. This allows you to use an HTML attribute that is not directly supported by the control. This property is accessible programmatically; it cannot be set in the designer
BackColor The background color of the control, which can be set using standard HTML color identifiers, such as “red” or “blue,” or RGB values expressed in hexadecimal format (“#ffffff”).
BorderColor The border color of the control, which can be set using standard HTML color identifiers, such as “black” or “red,” or RGB values expressed in hexadecimal format (“#ffffff”).
BorderWidth The width of the control’s border in pixels. Not fully supported for all controls in browsers earlier than Internet Explorer 4.0
BorderStyle The border style, if there is any. Possible values are NotSet, None, Dotted, Dashed, Solid, Double, Groove, Ridge, Inset, and Outset
CssClass The CSS class to assign to the control.
Style A list of all CSS properties that are applied to the specified HTML server control
Enabled An attribute that disables the control when set to false. This dims the control and makes it inactive. It does not hide the control
EnableTheming The default is true, which enables themes for this control.
EnableViewState The default is true, which enables view state persistence for the control
Font An attribute that contains sub properties that you can declare using the property-sub property syntax in the opening tag of a Web server control element. For example, you can make a Web server control’s text
italic by including the Font-Italic attribute in its opening tag.
ForeColor The foreground color of the control. It is not fully supported for all controls in browsers earlier than Internet Explorer 4.0.
Height The control’s height. It is not fully supported for all controls in browsers earlier than Internet Explorer 4.0.
SkinID The skin to apply to the control
TabIndex The control’s position in the tab order. If this property is not set, the control’s position index is 0. Controls with the same tab index can be tabbed according to the order in which they are declared in the Web
page. This works only in Internet Explorer 4.0 and later.
ToolTip The text that appears when the user hovers the mouse pointer over a control. The ToolTip property does not work in all browsers.
Width The width of the control. The possible units are Pixel, Point, Pica, Inch, Mm, Cm, Percentage, Em, and Ex. The default unit is pixels.
Tuesday, August 10, 2010
Web server Controls and Adding Web Server controls
Web server Controls
ASP.NET provides programmers a set of Web server controls for creating Web pages that provide more functionality and a more consistent programming model than that of HTML server controls.
Web server controls are able to provide more functionality because they are not tied to a single HTML tag element. Instead, they typically render many HTML tags and may also include client-side JavaScript code. Web server controls also have the ability to detect the Web browser’s capabilities and render the appropriate HTML based on those capabilities.
A Web server control can be added to an .aspx page using the Visual Studio Design view or Source view, or dynamically using code.
Eg: Adding Web Server Controls Using Design View
1. Open a Web page in Visual Studio.
2. Click the Design tab at the bottom of the Web page.
3. Open the Toolbox and click the Standard tab.
4. Drag a Web server control from the Toolbox and drop it on the Web page.
Eg: Adding Web Server Controls Using Source View
1. Open a Web page in Visual Studio.
2. Click the Source tab at the bottom of the Web page.
3. In Source view of the Web page, type the Web server control element and its attributes..
4. Alternatively, you can drag a control from the Toolbox directly into the page source..
Eg: Adding Web Server Controls Dynamically Using Code
1. Open the Web page’s code-behind page in Visual Studio.
2. Create a handler for the Page_PreInit event.
3. In the Page_PreInit method, add code to create a new instance of a TextBox Web server control.
4. After creating the instance, add code to set the control’s ID property.
5. Finally, add the control to the Controls collection of form1. This will make sure the control is output as part of the form.
protected void Page_PreInit(object sender, EventArgs e)
{
TextBox textBoxUserName = new TextBox();
TextBoxUserName.ID = "TextBoxUserName";
form1.Controls.Add(textBoxUserName);
}
ASP.NET provides programmers a set of Web server controls for creating Web pages that provide more functionality and a more consistent programming model than that of HTML server controls.
Web server controls are able to provide more functionality because they are not tied to a single HTML tag element. Instead, they typically render many HTML tags and may also include client-side JavaScript code. Web server controls also have the ability to detect the Web browser’s capabilities and render the appropriate HTML based on those capabilities.
A Web server control can be added to an .aspx page using the Visual Studio Design view or Source view, or dynamically using code.
Eg: Adding Web Server Controls Using Design View
1. Open a Web page in Visual Studio.
2. Click the Design tab at the bottom of the Web page.
3. Open the Toolbox and click the Standard tab.
4. Drag a Web server control from the Toolbox and drop it on the Web page.
Eg: Adding Web Server Controls Using Source View
1. Open a Web page in Visual Studio.
2. Click the Source tab at the bottom of the Web page.
3. In Source view of the Web page, type the Web server control element and its attributes..
4. Alternatively, you can drag a control from the Toolbox directly into the page source..
Eg: Adding Web Server Controls Dynamically Using Code
1. Open the Web page’s code-behind page in Visual Studio.
2. Create a handler for the Page_PreInit event.
3. In the Page_PreInit method, add code to create a new instance of a TextBox Web server control.
4. After creating the instance, add code to set the control’s ID property.
5. Finally, add the control to the Controls collection of form1. This will make sure the control is output as part of the form.
protected void Page_PreInit(object sender, EventArgs e)
{
TextBox textBoxUserName = new TextBox();
TextBoxUserName.ID = "TextBoxUserName";
form1.Controls.Add(textBoxUserName);
}
ASP.NET Page Life Cycle Events
Page Life Cycle Events:
1. PreInit: This is the first real event you might handle for a page. You typically use this event only if you need to dynamically (from code) set values such as master page or theme. This event is also useful when you are working with dynamically created controls for a page. You want to create the controls inside this event.
2. Init: This event fires after each control has been initialized. You can use this event to change initialization values for controls.
3. InitComplete: Raised once all initializations of the page and its controls have been completed.
4. PreLoad: This event fires before view state has been loaded for the page and its controls and before PostBack processing. This event is useful when you need to write code after the page is initialized but before the view state has been wired back up to the controls
5. Load: The page is stable at this time; it has been initialized and its state has been reconstructed. Code inside the page load event typically checks for PostBack and then sets control properties appropriately. The page’s load event is called first. Then, the load event for each child control is called in turn (and their child controls, if any). This is important to know if you are writing your own user or custom controls.
6. Control (PostBack) events: ASP.NET now calls any events on the page or its controls that caused the PostBack to occur. This might be a button’s click event, for example.
7. LoadComplete: At this point all controls are loaded. If you need to do additional processing at this time you can do so here.
8. PreRender: Allows final changes to the page or its control. This event takes place after all regular PostBack events have taken place. This event takes place before saving ViewState, so any changes made here are saved.
9. SaveStateComplete: Prior to this event the view state for the page and its controls is set. Any changes to the page’s controls at this point or beyond are ignored. This is useful if you need to write processing that requires the view state to be set.
10. Render: This is a method of the page object and its controls (and not an event). At this point, ASP.NET calls this method on each of the page’s controls to get its output. The Render method generates the client-side HTML, Dynamic Hypertext Markup Language (DHTML), and script that are necessary to properly display a control at the browser. This method is useful if you are writing your own custom control. You override this method to control output for the control.
11. UnLoad: This event is used for cleanup code. You use it to release any managed resources in this stage. Managed resources are resources that are handled by the runtime, such as instances of classes created by the .NET common language runtime.
1. PreInit: This is the first real event you might handle for a page. You typically use this event only if you need to dynamically (from code) set values such as master page or theme. This event is also useful when you are working with dynamically created controls for a page. You want to create the controls inside this event.
2. Init: This event fires after each control has been initialized. You can use this event to change initialization values for controls.
3. InitComplete: Raised once all initializations of the page and its controls have been completed.
4. PreLoad: This event fires before view state has been loaded for the page and its controls and before PostBack processing. This event is useful when you need to write code after the page is initialized but before the view state has been wired back up to the controls
5. Load: The page is stable at this time; it has been initialized and its state has been reconstructed. Code inside the page load event typically checks for PostBack and then sets control properties appropriately. The page’s load event is called first. Then, the load event for each child control is called in turn (and their child controls, if any). This is important to know if you are writing your own user or custom controls.
6. Control (PostBack) events: ASP.NET now calls any events on the page or its controls that caused the PostBack to occur. This might be a button’s click event, for example.
7. LoadComplete: At this point all controls are loaded. If you need to do additional processing at this time you can do so here.
8. PreRender: Allows final changes to the page or its control. This event takes place after all regular PostBack events have taken place. This event takes place before saving ViewState, so any changes made here are saved.
9. SaveStateComplete: Prior to this event the view state for the page and its controls is set. Any changes to the page’s controls at this point or beyond are ignored. This is useful if you need to write processing that requires the view state to be set.
10. Render: This is a method of the page object and its controls (and not an event). At this point, ASP.NET calls this method on each of the page’s controls to get its output. The Render method generates the client-side HTML, Dynamic Hypertext Markup Language (DHTML), and script that are necessary to properly display a control at the browser. This method is useful if you are writing your own custom control. You override this method to control output for the control.
11. UnLoad: This event is used for cleanup code. You use it to release any managed resources in this stage. Managed resources are resources that are handled by the runtime, such as instances of classes created by the .NET common language runtime.
Monday, August 9, 2010
The Importance of View State
The Importance of View State:
View state is a mechanism used by ASP.NET to store user-specific request and response data between page requests. The data being stored is typically associated with the server controls. This data is referred to as control state. Again, the view state data is not stored by the server. Instead, it is saved into the page’s view state (stage 7, rendering) and sent in the page’s response back to the user. When the user makes the next request, the view state is returned with his or her request. When the page processes, ASP.NET pulls the view state from the page and uses it to reset property values of the page and its controls (stage 4, load). This allows ASP.NET to have all the object data between requests without having to store it on the server. The result is a more scalable Web server that can handle more requests.
View state is a mechanism used by ASP.NET to store user-specific request and response data between page requests. The data being stored is typically associated with the server controls. This data is referred to as control state. Again, the view state data is not stored by the server. Instead, it is saved into the page’s view state (stage 7, rendering) and sent in the page’s response back to the user. When the user makes the next request, the view state is returned with his or her request. When the page processes, ASP.NET pulls the view state from the page and uses it to reset property values of the page and its controls (stage 4, load). This allows ASP.NET to have all the object data between requests without having to store it on the server. The result is a more scalable Web server that can handle more requests.
Life Cycle of an ASP.Net web page
Life Cycle of an ASP.Net web page
The life cycle starts when a user requests a Web page through his or her browser. The Web server then processes the page through a series of stages before returning the results back to the user’s browser. These processing stages define the life cycle of a Web page. Understanding how ASP.NET processes a Web page on the server is key to being able to successfully develop Web applications.
1. page request: Compile page (if necessary) Pull from cache (if available)
2. Start: Set request and response. Determine IsPostback.
3. Page Init: Initialize page controls (but not their properties). Apply page theme.
4. Load: If PostBack, load control properties from view state.
5. Validation: validate page and validator controls.
6. Post back Event handling: Call control event handlers (for post back requests).
7. Rendering: Save ViewState. Render controls and output the page.
8. Unload: Unload Request and Response. Perform clean-up. Page is ready to be discarded.
When a Web page is requested, the server creates objects associated with the page and all of its child control objects and uses these to render the page to the browser. Once the final stage is complete, the Web server destroys these objects to free up resources to handle additional requests.
The life cycle starts when a user requests a Web page through his or her browser. The Web server then processes the page through a series of stages before returning the results back to the user’s browser. These processing stages define the life cycle of a Web page. Understanding how ASP.NET processes a Web page on the server is key to being able to successfully develop Web applications.
1. page request: Compile page (if necessary) Pull from cache (if available)
2. Start: Set request and response. Determine IsPostback.
3. Page Init: Initialize page controls (but not their properties). Apply page theme.
4. Load: If PostBack, load control properties from view state.
5. Validation: validate page and validator controls.
6. Post back Event handling: Call control event handlers (for post back requests).
7. Rendering: Save ViewState. Render controls and output the page.
8. Unload: Unload Request and Response. Perform clean-up. Page is ready to be discarded.
When a Web page is requested, the server creates objects associated with the page and all of its child control objects and uses these to render the page to the browser. Once the final stage is complete, the Web server destroys these objects to free up resources to handle additional requests.
Message Exchange Patterns
Message Exchange Patterns
MEPs describe the protocol of message exchanges a consumer must engage in to converse properly with the service.
• Request/Response
• OneWay
• Duplex
1. Request/Response
This is by far the most common MEP and very little has to be done to set it up because the default value for the IsOneWay property of OperationContractAttribute is false.
Even with a void return type, if you are using Request/Response, then a response message is still going back to the consumer when the operation is called; it just would have an empty SOAP body.
2. OneWay
Sometimes, you simply want to send a message off to a service and have it trigger some sort of business logic, and you aren’t in fact interested in receiving anything back from the service. In such cases, you might want to use the OneWay MEP, that is, have the consumer simply send one-way messages into the service endpoint without any responses back from the service. This MEP is declared by setting the IsOneWay property on the OperationContractAttribute to true.
The most important one is that such an operation cannot pass any data back to the client application; it must return a void and cannot have parameters marked as out or ref.
When a OneWay operation starts running in the service, the client application has no further contact with it and will not even be aware of whether the operation was successful or not.
If the operation raises an exception that would normally generate a SOAP fault message, this SOAP fault message is simply discarded and never sent to the client.
Eg:
[OperationContract(IsOneWay=true)]
void Cancel(string action);
Duplex
The Duplex MEP is a two-way message channel whose usage might be applicable in either of these two situations.
• The consumer sends a message to the service to initiate some longer-running processing and then subsequently requires notification back from the service, confirming that the requested processing has been done.
• The consumer needs to be able to receive unsolicited messages from the service.
There are two Service contracts to consider in a Duplex MEP scenario, namely
1. the Service contract and
2. the Callback contract
This MEP is declared by associating the Callback contract with the Service contract. This association is done through the CallbackContract property of the ServiceContractAttribute that is adorning the service that needs to be capable of calling back to a consumer.
MEPs describe the protocol of message exchanges a consumer must engage in to converse properly with the service.
• Request/Response
• OneWay
• Duplex
1. Request/Response
This is by far the most common MEP and very little has to be done to set it up because the default value for the IsOneWay property of OperationContractAttribute is false.
Even with a void return type, if you are using Request/Response, then a response message is still going back to the consumer when the operation is called; it just would have an empty SOAP body.
2. OneWay
Sometimes, you simply want to send a message off to a service and have it trigger some sort of business logic, and you aren’t in fact interested in receiving anything back from the service. In such cases, you might want to use the OneWay MEP, that is, have the consumer simply send one-way messages into the service endpoint without any responses back from the service. This MEP is declared by setting the IsOneWay property on the OperationContractAttribute to true.
The most important one is that such an operation cannot pass any data back to the client application; it must return a void and cannot have parameters marked as out or ref.
When a OneWay operation starts running in the service, the client application has no further contact with it and will not even be aware of whether the operation was successful or not.
If the operation raises an exception that would normally generate a SOAP fault message, this SOAP fault message is simply discarded and never sent to the client.
Eg:
[OperationContract(IsOneWay=true)]
void Cancel(string action);
Duplex
The Duplex MEP is a two-way message channel whose usage might be applicable in either of these two situations.
• The consumer sends a message to the service to initiate some longer-running processing and then subsequently requires notification back from the service, confirming that the requested processing has been done.
• The consumer needs to be able to receive unsolicited messages from the service.
There are two Service contracts to consider in a Duplex MEP scenario, namely
1. the Service contract and
2. the Callback contract
This MEP is declared by associating the Callback contract with the Service contract. This association is done through the CallbackContract property of the ServiceContractAttribute that is adorning the service that needs to be capable of calling back to a consumer.
Subscribe to:
Posts (Atom)