Building the Right Environment to Support AI, Machine Learning and Deep Learning
Visual Basic developers have long enjoyed the ease of programming with forms and controls. Writing a VB form-based application is as simple as dragging some controls onto a form and writing some event-handling functions. This is one of the main reasons VB attracted lots of programmers interested in development speed. Microsoft used the advantage of VB in ASP.NET. ASP.NET simplifies Web page development with form-based programming. In ASP.NET, these forms are called Web Forms and are analogous to VB forms, replacing ASP Pages. As a part of the .NET Framework, ASP.NET can be used to write Web applications as well as for writing Web Services. Similar to VB, Web Forms programming is also event based. We don't have to write in-line ASP scripts and rely on the top-down parsing interpretation as in ASP programming. To match the rich set of ActiveX controls that VB programmers love in their toolset, ASP.NET equips ASP programmers with server controls. To further enhance developers' productivity, ASP.NET's Web Forms also allow for the separation of the application logic and the presentation layer.
- Clean separation between the application logic (server-side code) and the presentation layer (HTML markup)—no mixed code.
- A rich set of server controls that automatically render HTML suitable for any clients and that additionally manage their states.
- Enhanced session-state management.
- An event-based programming model on the server side, which is simple and more intuitive.
- Application logic that can be written in any Microsoft .NET language (VB, C#, Managed C++, and so forth); application server-side is compiled for better performance.
- Visual Studio .NET as a RAD tool, which simplifies the development process of Web Forms.
The System.Web.UI Namespace
The System.Web.UI Namespace defines classes and interfaces used in constructing and rendering elements on a Web Form. The most important class in the System.Web.UI Namespace class is the Control class, which defines properties, methods, and events that are common in all server controls in the Web Forms framework. Another important class in this namespace is Page, a derivative of the control class. To have an extensible framework, the System.Web.UI namespace also includes the UserControl class, which is similar to the UI Page class except that it is mainly used as the base class for user controls.
The Control Class
The Control class has the following important properties: Controls, ID, Parent, EnableViewState, Visible, Context, and ViewState. We will go over each of these properties briefly to show you what the Control class is made up of and how deriving from Control class would create a model that is consistent and easy to work with.
The Control property represents the children of the control instance; the Parent property defines the control's parent. These properties enable the hierarchy of controls on a Web page. The ID property allows the control to be accessed programmatically by just using the ID and the dot notation to get to the object's properties and methods; for example, MyObjectId.propertyname. It also allows us to write event handlers for events raised by this control.
The EnableViewState flag indicates whether the control will maintain its view state, as well as all view states of its child controls. If this flag is set to true, the control will remember its previous view state when the page posts back to itself. For example, if EnableViewState is set to true, the user's preserved automatically when the user performs some operation that requires a postback. When the page is sent to the browser, the user can just continue filling in the form as if he never left it. This is how all derivatives of the control class maintain their states between requests and free developers from plumbing works with hidden form fields.
The Context property enables us to get to information about the current HTTP request, such as the Application, Server, Session, Request, and Response objects. ASP developers should be familiar with these intrinsic objects. You will likely use the Context property when you are processing the Web page's OnLoad event to get to application- or session-level variables and request parameters to set up your page. Through the Context property, you can also get other information, such as cached resources—including database connections—for performance improvement; the trace property, for debugging purpose; and the user property, for security validation.
The ViewState property is an instance of the StateBag class, which is used to store name/value pairs of information that can be made accessible across multiple requests for the same web page. These name/value pairs are instances of the StateItem class.
Control Class Methods
The list of methods for the control is much longer than what I've covered in this article; however, this short list is probably all you need to know the get started with the Control class.
|DataBind||Binds the control to a data source. This method is used in conjunction with the data-binding expression syntax on the Web Form. When this method is called, all data-binding tags, <%#%>, are re-evaluated so that the new data is bound to the appropriate tag location.|
|CreateChildControls||Called before any compositional custom control is rendered. A compositional custom control is similar to an ActiveX control: It composes other controls. You would not use this method simply to use the control. When developing custom controls, this method can be overridden so that custom-control developers can create and layout child controls prior to rendering the control, whether for the first time of for postbacks.|
|Render||Similar to the CreateChildControls, primarily used to develop custom controls. Control developers override this method to render the control content through the provided HtmlTextWriter parameter.|
As mentioned earlier, the Page class is actually a derivative of the Control class. This means that it inherits all properties, methods, and events exposed by the Control class. In addition to the inherited things, the Page class defines more specific properties, methods, and events for a Web page in an ASP.NET framework.
If you've done ASP development, you already know that Application, Request, Response, Server, and Session are intrinsic objects that you can access while scripting your ASP page. With ASP.NET, these objects are actually properties of the Page class. In addition to these familiar objects, the Page class also exposes other properties such as Cache, ErrorPage, IsPostBack, IsValid, Trace, and Validators.
Page Class Properties and Methods
This list is not complete; however, it includes some of the more important features:
|Cache||Points to a Cache object of the Context for the current page. Here, resources such as database connections are stored for re-use without having to re-create the connection, given that the cache item is not yet expired.|
|ErrorPage||Specifies the page to display when an error occurs. You can also specify the error page by using @Page.|
|IsPostBack||Indicates whether the page request is an original request or a postback, because the interaction between the user and the server controls requires a postback to the current page. If IsPostBack is true, you should not redo all your page initialization to improve performance.|
|Validators||Groups together server controls that can validate themselves inside the Validators property of the Page. (In ASP.NET, a Web page usually consists of a number of server controls.) This is so that when the Page needs to validate itself, it can delegate the validation to all of these controls and then set the IsValid property to the appropriate value.|
|Trace||References a TraceContext object, through which you can issue warning error messages. Tracing can be switched on or off at anytime from the web.config setting. web.config is an XML-based text file that stores the runtime configuration for an ASP.NET application. Changes to this file take effect immediatly, unlike global.asa in ASP development. The main configuration file is at the root of your Web applications; however, you can have a configuration file for each subdirectory in your Web application. The closest configuration file overrides the settings of distant configuration files. Being able to switch off tracing in a configuration file like this is much better than doing so manually in ASP development, where you must go through all ASP files to remove all instances of Response. Write debugging messages when you are ready to deploy your application.|
|LoadControl||Loads server controls into the page programmatically. You can also have static server control declared on the page using the server-side object.|
|MapPath||Maps a virtual path to a physical path for file I/O. This should be familiar to ASP developers|
|Validate||Works with the Server Validation Controls on the page to validate data on the page. If any of the server controls fails to validate, this method returns false, and the failed-server-validation control renders the error message to the user.|
|CreateHtmlTextWriter||Produces an HtmlTextWriter object to write HTML to the response stream. This is similar to ASP's Response.Write method; however, the HtmlTextWriter object is much smarter than a raw Write method. It helps you write well-formed HTML.|
|By default, save and load view state for all controls as hidden fields on the page. If you don't want this setting, you can override the SavePageStateToPersistanceMedium method to save the view state anywhere other than hidden fields. You will also have to override the LoadPageStateFromPersistanceMedium method to have the saved view states loaded back onto the page prior to rendering.|
The UserControl class is similar to the Page class with the omission of page-specific methods such as ErrorPage, IsValid, User, Validators, MapPath, Validate, and CreateHtmlTextWriter.
The UserControl class is typically used as the base class for custom controls. We can also build custom controls by inheriting directly from the Control class; however, it's better to start from UserControl because it is not as raw as the Control class. If you find that UserControl supports a number of properties and methods that you don't really want in your custom control, you might choose to inherit the raw Control class instead.
About the Author
This Article is provided by Sonu Kapoor and is associated with Codefinger (www.codefinger.de), a company specializing in Windows Application Development.