ASP. NET tips: bind background program variables to the front-end Page code

ASP. NET programming often encounters the problem of using (or binding) the variable value in the background program in the front-end Page code. Generally, there are two methods: <% = str %> and <% # str %>. Here is a brief summary. If you have any errors or objections, please kindly advise.

On the one hand, the front-end is common. aspx file. The background refers to the CodeBehind associated with aspx. The file suffix is. aspx. cs; on the other hand, binding here means that after a user sends a command to access a page, the server has assigned a value to the front-end code during execution, after the html format is generated, it is returned to the client for display, instead of being displayed to the client. Then, you can use other methods (such as ajax) to obtain the corresponding variables on the server.

Note: The two files mentioned above are in the code-behind mode and the code-beside (inline) mode, that is, only one aspx file exists, the background code is written into the <script type = "text/javascript" runat = "server"> </script> file (there are some syntax differences ), this has a slight impact on the issues discussed in this article, because code embedding is declarative code and C #/VB.. NET code is compiled together into a class, while the code is hidden, the declarative code and C #/VB.. NET code is separated several times for translation/compilation. Therefore, the former is the relationship between local and local (partial), and the latter is the relationship between the base class and the derived class, however, this only affects the range of variables that can be bound (related to modifiers. The following uses the code hiding mode as an example.

Generally, backend variables may be used (bound) in three front-end code locations:

Server-side control attributes or HTML tag attributes

JavaScript code

The location of the Html display content (that is, the content between the start tag and the end tag, for example, <div> here </div> (Html Tag) or <asp: label ID = "Label2" runat = "server" Text = "Label"> here </asp: Label> (server-side control ), it is used as a placeholder to display variables at the position where the symbols appear)

For the first position, there are some constraints:

(1) The general attribute requirements are string or numeric. (Some server attributes support data sets );

(2) Not all attributes can be bound to variables. For example, the runat attribute must be a constant of "server". Even if the bound string is a server, an error occurs during analyzer analysis;

(3) There is an attribute that requires the attribute value to be constrained (type constraints, for example, the server-side control requires that the TabIndex attribute be of the short type, or the string content is constrained ), it should also be met during binding; otherwise, an error may still be reported during compilation;

(4) another property. Although the property itself has constraints, it can be compiled even if the bound variable does not meet the constraints, such as the checked attribute of input, only the checked string is valid, but if the string obtained by binding is not checked, these attributes will have their own internal processing mechanism to ensure normal use;

(5) Pay attention to the fact that, even for the same class of attributes, the processing mechanisms of the server side and the HTML attributes are also different. The same is TabIndex (tabIndex). If the former does not meet the requirements, the analyzer is incorrect, the latter ignores this issue.

For the second position, it is generally only required that the bound background variable is compatible with the Data Type in JavaScript.

For the third position, if the binding position does not exist in the server-side control, there is no constraint. As long as it is a constant string that can appear, it can be bound. However, for the control placed inside the server, that is, the <asp: Label ID = "Label2" runat = "server" Text = "Label"> here </asp: label>, there are constraints. The summary is summarized into four types of server-side controls. If the bound code appears between the start and end labels of these controls (the control mentioned here, if the bound code is surrounded by multiple layers of nested controls, it refers to the inner control of the bound code), with different display results:

(1) Constrained controls: these controls require that their start and end labels only contain the specified child controls. Therefore, if a code block appears here, a compilation error occurs. For example:

<Asp: DataList runat = "server"> </asp: DataList>. The <ItemTemplate> </ItemTemplate> must be nested between them.

(2) Non-nested controls: such controls cannot be embedded with other controls or labels, but can only be constant strings, it uses the constant string content in the start tag and end tag as its attribute. For example, the TextBox mentioned above uses the content between tags as its Text attribute value.

(3) nested controls: these controls can be nested with any other controls or contain strings. Therefore, the string content represented by the bound code block can be displayed normally. Such as Label control and Panel.

(4) data binding controls: these controls are ASP. the server-side controls provided by. NET can be bound to either a common variable type or a data set (only implemented in the second method below ).

Quotation marks: Should <% = str %> or <% # str %> be placed in single or double quotation marks when using the preceding three positions? For different locations, the processing method is different: (Please refer to the following two methods for details)

(1) For the first position, because JavaScript is weak, it is always correct to treat it as a string if quotation marks are added during binding; if no quotation marks are added during binding, it will be considered as a numerical value. If the obtained value is a real value, of course, if it is not a numeric value, a script error will be generated, this is the same even when a constant is assigned to JavaScript:

Reference content is as follows:

Var test1 = 123b; // an error is reported during running.
Var test2 = 123; // correct, which is a numeric value
Var test3 = "123b"; // correct, string type

(2) For the second position, the quotation marks are always correct for both the server-side control attributes and the HTML tag attributes. If no quotation marks are added, the two attributes are processed in different ways:

For server-side control attributes, if the bound code block is not enclosed by quotation marks, the system prompts "authentication (ASP. NET): The warning information must be enclosed by quotation marks before and after the feature value. However, after being generated as HTML, the corresponding HTML attribute has been enclosed by quotation marks and the correct binding result is obtained, therefore, adding quotation marks does not affect the use of the Code. However, it is recommended that you add the standard code as well;

For HTML tag attributes, if no quotation marks are added, the warning message "verification (XHTML 1.0 Transitional): must be enclosed by quotation marks" is displayed during compilation, in addition, HTML attributes are not enclosed by quotation marks. Although the correct binding value is not followed by quotation marks, the expected results may not be displayed. For example, for the value Attribute of the input tag, if the bound string is "hello world from variable", the content displayed in the client's input is actually a "hello" string, the valid property value is a truncated string. It starts from the first non-null character of a string (if no quotation marks are added) after the attribute, as of the first character of the next null character (for example, for "hello world", the result will be "hello"), so quotation marks are required.

(3) For the third position, adding and without quotation marks will not affect the obtained value and display.

Therefore, it is recommended that all binding expressions be enclosed in quotation marks and obtained as strings. Then, convert the expressions based on actual needs and use the corresponding functions to obtain the desired type.

In addition, the background variables mentioned here are generic, including:

Member variables

Return Value of a method or attribute

Expression, that is, the value obtained after running all the code that can be executed in the background (that is, the background code is directly written in the foreground code, remember to use a fully qualified name or using-related namespace in the background)
Data Set

Background variables have some constraints that must meet:

(1) variable modifier requirements. The variables are static or instance fields. For ASP. NET, the variables described above must be of the public or protected type (because it is the relationship between the base class and the derived class), neither private nor internal can, in the Code embedding mode, any modifier variables can be accessed (the internal relationship of a class ).

(2) variable type requirements. Because the foreground attribute is generally a string type, and the basic JavaScript type is string type, number type, and boolean type, the corresponding variables should also be in these ways, if other types are not supported (such as complex types, arrays, and reference types), the front-end obtains the string obtained by calling the ToString () method of the variable. Therefore, when binding, check whether implicit type conversion can be performed based on the situation. If necessary, use related functions to force conversion to ensure that the foreground can obtain the correct value. Of course, for data binding controls, some of its attributes can be data sets, but the binding can only be supported in the second way below.

The above are some concepts and basic constraints that should be met in both ways. The following describes two methods to implement the front-end code (called code block) bind background variables.