Asp. NET Tip: Foreground page code binding daemon variables

ASP. NET programming often encounters the problem of using (or binding) the values of variables in the background program in the foreground page code. There are generally <%= str%> and <%# str%> two ways, here a short summary. If there is any mistake or objection, please advise.





on the one hand, The front desk that is spoken here is usually. aspx file, which refers to the codebehind associated with ASPX, and the file suffix named. aspx.cs; On the other hand, the binding here refers to the user to send access to a page instruction, the server side in the execution of the foreground code has been assigned, and then generate HTML format return The client displays, rather than having been shown to the client, and then goes to the server side to get the corresponding variable through other methods, such as Ajax.





Note: The two files mentioned above are common code-behind (Code-behind) patterns, and there is a code embedding (code-beside, inline) pattern where only aspx files exist and the latter code writes to the file's <script Type= "Text/javascript" runat= "Server" ></script> (there are some grammatical differences), which has a slight impact on the issues discussed in this article, because code embedding is declarative code and C#/VB. NET code is compiled into a class together, and code-behind is the declarative code with C#/VB. NET code is translated/compiled several times, so the former is a local and local (partial) relationship between the base class and the derived class, but this only affects the scope of the variable that can be bound (related to modifiers), as mentioned below. The following are examples of code-behind patterns.





in general, you might use (BIND) background variables in three locations in the foreground code:





server-side control properties or HTML tag properties





JavaScript code in





The position of the HTML display content (that is, the content between the start tag and the end tag, such as <div> here </div> (HTML tags) or <asp:label id= "Label2" runat= "Server" text= " Label "> Here </asp:Label> (server-side control), which displays the variable as a placeholder where the symbol appears)





for the first position, there are some constraints:





(1) The General property requirements are either string or numeric (some server-side attributes that support the data collection are mentioned below);





(2) Not all properties can be bound to variables, some properties such as the Runat property must be a "server" constant, even if the bound string is a server, will cause parser parsing error;





(3) has a property that requires a constraint on the value of the attribute (type constraints, such as server-side controls requiring the TabIndex attribute to be of type short, or the string content has constraints), should also be satisfied at the time of binding, otherwise it may still compile the times wrong;





(4) is also a property, although the property itself is constrained, but even if the bound variable does not meet the constraint, it can be compiled, such as the checked property of input, it is only legitimate checked string, but if the string obtained through binding is not checked, Then these attributes will have their own internal processing mechanism to ensure that they can be used normally;





(5) Also note that even for the same class of properties, the server-side and HTML properties of the processing mechanism is also different, the same is TabIndex (TabIndex), if the former is not satisfied, the parser error, the latter ignores the problem.





for the second location, it is generally as long as the binding background variable is compatible with the data type in JavaScript.





For the third location, if the binding appears in a location that is not inside the server-side control, there is no constraint, as long as the constant string can appear in a position that can be bound. However, there are constraints to the way that is placed inside the server-side control, which is the <asp:label id= "Label2" runat= "Server" text= "Label" > here </asp:Label>. By summarizing, it concludes four Class server-side control, if the bound code appears between the opening and closing tags of these controls (the controls described here refer to the most inner control enclosing the bound code if there are multiple nested controls outside the binding code), with different display results:





(1) Constrained controls: This type of control requires that its start and end tags contain only the specified child controls, so if a code block appears here, the error is compiled. For example:





<asp:datalist runat= "Server" ></asp:datalist&gt, in which the requirement must be nested <itemtemplate></itemtemplate >.





(2) non-nested class controls: Such controls, which do not allow internal nesting of other controls or labels, can only be constant strings, which take the contents of the constant string in the start and end tags as his properties. For example, the textbox mentioned above will use the contents of the label as its Text property value.





(3) nested class controls: Such controls can nest any other control or contain strings, so the string content represented by a bound code block can be displayed normally. such as label controls, panel, and so on.





(4) data-binding class controls: This type of control is a server-side control provided by ASP.net, and can be bound to a data collection (only the second way it can be done), in addition to the normal variable type.





about quotes: should <%= str%> or <%# str%> be placed in single or double quotes when used in the above three locations? For different locations, the way of handling is different: (specifically please in the following two ways of specific introduction, to be experienced)





(1) for the first position, because JavaScript is a weak type, it is always correct to think of it as a string if you enclose it in quotation marks, and it will be considered a numeric type if the binding is not quoted, so if you get a real number, you can, of course, If non-numeric, a script error is generated, which is the same even for JavaScript assignment constants:





The following are the referenced content:





var test1 = 123b;//run times wrong


var test2=123;//is correct, is a numeric type


var test3= "123b";/correct, String type


 


(2) for the second position, it is tested that the quotation marks are always correct for either server-side control properties or HTML tag properties, and if no quotes are used, the two properties are handled differently:





for server-side control properties, if the bound block of code is not quoted, the compile-time warning message "Verify (asp.net): The attribute value must be quoted before and after" is created, but the corresponding generated HTML attribute has been quoted and the correct binding result is obtained. Therefore, the addition of quotes does not affect the use of, but the recommended code for the specification, or add to the good;





For HTML tag Properties, if you do not enclose quotes, you are prompted at compile time to verify (XHTML 1.0 Transitional): a warning that must be enclosed in quotes before and after the attribute value, and that the HTML attribute is not actually quoted. Then, although the attributes do not have the correct binding value behind the quotes, they do not necessarily show the results you want to see. For example, for the value attribute of the input tag, if the bound string is "Hello World", the content displayed in the client's input is actually just a "hello" string, and the property value in effect is a truncated string, the variable It starts with the first non-null character of a string of strings after the attribute (if not quoted), up to the previous character of the next null character (for example, "Hello World", the result will be "good"), so it is necessary to enclose the quotation marks.





(3) with or without quotes for the third position, the obtained value and its display are unaffected.





Therefore, it is recommended that all binding expressions be quoted as strings and then converted with the corresponding function to get the desired type, depending on the actual requirements.





In addition, the background variables described here are generic, including the following:





member Variable





The return value of a method or property





expression, that is, all the background can execute code, the resulting value after the run (that is, the background code is written directly in the foreground code, remember to use the fully qualified name or in the background using related namespace)


Data Collection





background variables have some constraints that need to be met:





(1) variable modifier requirements. The variable is either static or an instance field. For the asp.net of the code-behind pattern, the variable described above must be either public or protected type (because it is the relationship between the base class and the derived class), private or internal, and code embedding mode can be accessed by any modifier variables (relationships within a class).





(2) variable type requirements. Because foreground properties are typically string types, and JavaScript basic types are string, numeric, and Boolean, the corresponding variables should be the same, and if the remaining types are not supported (such as complex types, arrays, reference types, and so on), The foreground gets the string that the ToString () method of the variable was called. Therefore, in the binding time, depending on the situation to see whether the implicit type conversion, if necessary, with the relevant function to cast, to ensure that the foreground can get the correct value. Of course, for a data-bound class control, some of its properties can be data collections, but the binding can only be supported by the following second method.





above is a number of concepts and basic constraints, these are both ways should be met, the following specific two ways to implement the foreground Code (hereinafter referred to as the Code block) binding background variables function.