From the inheritance relationship, the category of the ASP.NET server control is roughly divided into 4 categories:
1, user control
Similar to Page, it is basically no need to program, and an ASPX page can be used as multiplexed components.
2, LiteralControl
ASP.NET compiles all HTML elements and readable text that do not require server-side to compile them into this class. For example, an HTML element that does not contain the runat = "server" attribute / value to the start mark is compiled into the LiteralControl object.
The behavior of the text control is the same as the text holder, which means that the text can be extracted from the text control and remove the text control from the parent server control through the Controls property of the parent server control. Therefore, when developing custom controls exported from the LiteralControl class, make sure they perform any desired preprocessing steps themselves instead of using the call to the LiteralControl.Render method to implement them. It is generally doing this to improve the response time of the web application.
LiteralControl generally does not trigger a server-side event.
The text control can be added or removed from the page or server control in programming how the ControlColLethtic.Add or ControlColLethtic.remove method is used.
3, HTMLControl
The ASP.NET model server side of the HTML element corresponds to components. Each HTMLControl directly corresponds to a particular HTML element (not necessarily an input element).
4, WebControl
Usually web controls. It can be understood as a complex HTML element and server-side processing logic.
Inheritance diagram:
System.Object
System.Web.ui.Control
System.web.ui.templateControl
System.Web.ui.page
System.Web.ui.userControl
System.Web.ui.literalControl
System.Web.ui.htmlControl
System.Web.ui.WebControl
User controls, web controls are usually required for programmers. xxx
WEB server components inherited from WebControl often inherit the rich UI elements and control capabilities.
User control
1, why is user control
Modern people are lazy, like "what you get" and "drag and drop". In a ASP.NET Web project, there is often a shared UI in multiple pages, such as Header Footer, etc. If all pages are consistent, it is often implemented with a specific JS file, but if these multiple pages The needed UI part will be different from different user status, etc., which must be dynamic logic processing, and ordinary JS / HTML cannot meet the requirements. The incrude ASP file is used in the ASP to implement, and the ASP.NET has changed in the ASP.NET to resolve all kinds of defers that contain the ASP files.
User control is essentially a separate ASP.NET file with ASCX. User controls typically depend on a specific ASP.NET Web project. When using the user control, the ASP.NET page parser dynamically generates a class from the ASPX file, compiles it to a specific assembly (hosted in the temporary cache), and reference such instance according to the .NET method, and perform deal with.
2, how to get user controls
Get user controls, actually only need:
Add-> User Controls -> Enter User Control Names -> Info.
When using, drag and drop the user control on a web form to use the user control. At this time, VS replaces us to do it:
Add a Register directive to the page using the user control. Specifically: <% @ register tagprefix = "uc1" tagname = "WebUserControl1" src = "WebUserControl1.ascx"%> The page interpreter can be interpreted as: "UC1: WebUserControl1 is explained as user controls, UC1 is the label prefix ( Similar to the ASP tag prefix for standard web controls), WebUserControl1 as the label of this user control, interpreted this combination to interpret the user control instance. The SRC value is the virtual path where the user control source file is located, but it is not an absolute path.
3, the essence of the user control (the background of the user control of the ASP.NET)
ASP.NET is compiled, processing user controls are similar to handling pages, all elements in the page are compiled into specific classes called by ASP.NET page class, trigger events. User controls are also reused by this path. When processed user controls, the page framework performs the following steps:
Explain the ASCX file, the corresponding interpretation becomes a managed class derived from System.Web.ui.userControl
Dynamically compile into an automatically generated assembly.
The above process occurs only when using the user control for the first time, and later multiplexing this user control will omit this step. This page will be referenced using the Register directive. The user control in the page becomes such an instance. In fact, user controls are also written asp.net classes, derived at System.Web.ui.userControl classes, page uses these classes like using ASP.NET standard classes, in different than standard control classes, can be directly instantiated, The user control needs to perform compilation of the similar page before use, and can be instantiated after compiling and assembled and assembled to the assembly.
4, user control programming considerations
User components cannot be instantiated by a New way because the user control class is dynamically generated, and when the user (this time should be page compile time, the user control has not been running), the user control class does not exist. However, it can be loaded by page.loadControl (String ControlName). At this time, the user control can be found for LoadControl, you need to use the Refence instruction: <% @ refnce control = "xxx / userControlsamples.ascx"%>.
User controls can be used nested in addition to user controls, but must ensure that the user control reference location is correct.
User control itself belongs to
UI
It can be cached, determined by OutputCache instructions at the top of the ASCX file. The URL arriving in the user control code refers to the path exists in the user control, not the path to the page code of the user control, and needs to be correctly parsed by Page.Resolveurl.
