The topic we're talking about this time is "how you output content on a Web form page." This is actually a very old topic, because the content of this article can even be applied to ASP.net 1.1.
However, this topic is widely available, because even the current ASP.net MVC framework, its default view engine is still based on ASP.net webform (such as Page,control,masterpage). Even, because of the nature of the ASP.net MVC framework, we are experiencing more "direct output" content on the page. Therefore, this topic may be important in the ASP.net MVC application.
So take asp.net mvc for example. If we generate a partial View on the page, we can do this:
<% html.renderpartial ("Mypartialview"); %> |
However, in the previous article we presented a new method partial, which returns a string that can be used on the page like this:
<%= html.partial ("Mypartialview")%> |
An ASPX page is compiled into a subclass of the page class, and the primary "function" of the subclass is the Render method that overrides the base class:
public class Mypage:page { protected override void Render (HtmlTextWriter writer) { ... } } |
The amount of content that we usually write in the ASPX page turns into code that operates writer. For example, use writer. The Write method outputs the content, or the Render method of handing writer to the child control is used to generate the content. So, the above two kinds of pages on the mark is how to operate writer?
The first is the <%=%> tag. The <%=%> tag contains an "expression", so it cannot end with a semicolon. The data inside the expression is written directly to the writer. For example, a tag like this:
After the compilation, it becomes:
Writer. Write (DateTime.Now) |
Unlike the <%=%> tag, the <%%> tag contains "statements" in the middle. Statement naturally can have more than one line, naturally each line finally need to have a semicolon, as we usually write C # code. In fact, the function of the statement is not to "output content", but to "control logic". For example, you wrote a code like this on a page:
<% Func<int, bool> odd = i => i% 2!= 0; %> |
This is equivalent to declaring a local variable odd within the Render method, which is of type Func<int, bool> delegate. And if you write code like this:
<% for (int i = 0; i < i++) {%> <span> <%= i + 1%> </span> <%}%> |
The resulting render method will include the following:
for (int i = 0; i < i++) { Writer. Write ("<span>"); Writer. Write (i + 1); Writer. Write ("</span>"); } |
If it is a plain HTML tag written on the page, it will be processed as a normal string when compiled. Some friends have been talking about "client control" and so on, in fact, if there is no runat= "server" tag on an element, ASP. NET only treats them as normal strings and does not have any notion of "HTML elements". Of course, the above code shows "intent," in fact, the characters in the ASPX page after compilation are also included in the output.
So, since <%%> contains statements that control logic and is not used to represent output, why does the Html.renderpartial method in the code generate the page content? That's because the RenderPartial method writes characters directly to the current HttpContext.Response.Output. Many friends often use Response.Write to output content, in fact, the inside of the Write method is output.
In fact, even though our page uses HtmlTextWriter to output content, it is internally encapsulated in the TextWriter of output exposure. To verify, you can set breakpoints in your code and observe the writer parameters of the Render method, and you can find writer under normal conditions. The Innerwriter property is a Httpwriter object, which is a TextWriter subclass and an internal type defined in asp.net.
This is the details of the asp.net page output. So what is the difference between the following two kinds of output modes?
<%= "Hello World"%> <% Response.Write ("Hello World")%> |
On the effect, there is no difference between the two. But in fact the former uses the HtmlTextWriter object output of the page, while the latter outputs the content directly to the response.output. This distinction may seem unimportant, but in fact it involves many of the practices that are available in our development process. In future articles, I will present some guidelines for generating page content, explain the reasons for these guidelines, and point out how asp.net mvc itself undermines these design guidelines.
Naturally, the modified version of ASP.net MVC will be published in the Mvcpatch project.