Shulou(Shulou.com)06/02 Report--

This article will explain in detail how to understand ASP.NET Page. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Page, which I think every ASP.NET developer should be familiar with.

I'm going to talk about it in this blog. However, I'm not going to talk about using controls in Page, nor will I talk about the lifecycle of Page, because I think these topics have been talked about too many times, especially in ASP.NET books on the market.

I don't like repetition, so today I just want to talk about some things that people don't talk about, but I think they are still very important.

Some important Page instructions

Although Page exposes many properties that allow us to adjust its state and behavior at run time, there are some important parameters that are provided as "instructions" that need to be specified at design time.

Here are some of the instructions I think are important and often need to be used:

Global settings for web.config

I introduced some commonly used Page instructions earlier, and for convenience, ASP.NET also allows us to configure default values for some commonly used instructions in web.config. Here are some common scenarios to illustrate the convenience of these global configurations.

1. Usually, when I create a website project, I definitely decide not to use ViewState and Session. So if you set the EnableViewState,EnableSessionState directive attribute for each page, it would be too troublesome and easy to miss. At this point, we can specify a global default value for these parameters directly in web.config:

One additional note: the complete way to disable Session globally is to remove the HttpModule corresponding to Session from the httpModules list.

The specific configuration section that web.config allows us to set Page default parameters is as follows:

.........

two。 Designing user controls is also a common method for code reuse.

We can use the @ Register directive to register the UserControl or WebControl we need to use on the page. However, some controls are more generic and are used by many pages, so instead of using the @ Register directive, you can register uniformly in web.config. For example:

With this definition, I can use it directly on any page:

3. For people who like to use inline code on the page, they may often need to use their own defined types. If these types are defined in a namespace, you need to write the full namespace in your inline code. Although there is no problem with this, it is troublesome, so we can use the @ Import directive in the page to import the namespaces we need to use, but this directive can only import one namespace at a time, and each page has to be imported repeatedly, which is obviously not convenient.

To facilitate the use of some commonly used namespaces, we can specify them uniformly in web.config, such as:

Once this is set up, all pages can use the types under these namespaces directly.

I don't know some people have thought: why do you not need to import namespaces if you use some Microsoft-provided types in your pages?

The answer is: in fact, ASP.NET has already configured some namespaces that Microsoft thinks are commonly used in web.config:

4. Nowadays, more and more people are using extension methods for convenience. The advantage of using extension methods is that we don't care which class these extension methods are defined in, but just call them on objects that support extension methods, like the following code:

The current user is logged in, login name:

However, when you use an extension method in a page, you must also import the namespace of the definition class of the extension method.

So, for convenience, we can import the appropriate namespaces for the extension methods we define in web.config:

Use Page in a different way

In the traditional WEB development mode, we usually design some pages (Page) to respond to requests from the user's browser. In this mode, Page sends the full-page HTML code generated by * * directly to the user's browser. At some point, however, we just need to generate a HTML fragment:

1. In the AJAX request, the client only requires the server to return a HTML fragment for local refresh.

2. In BigPipe mode, you only need to output one HTML fragment at a time in order to output parts.

If you just want to get a simple piece of HTML code, some people may choose to use code to concatenate it, but what if that piece of HTML is a little complicated? Obviously, the splicing method must not work.

For * questions, someone may say: I can create a page and put only part of the code on the page. Indeed, this method can barely solve * problems, but it is quite possible that that part of the code will also be used for full-page output, so what should I do?

Make a UserControl and put it on a separate page! In fact, this practice is very helpless, because the meaning of that container page is not much (just a container), * get a lot of page files in the project! In fact, this approach is only suitable for situations where simple server-side controls are used, but not at all if you want to use some advanced server-side controls.

In order to meet the two requirements mentioned earlier, we can no longer use Page in the traditional way. Because we want to get (return) a HTML.

There are two ways to continue generating HTML code using page template code:

1. The Server.Execute () method.

2. Page.RenderControl () method.

The following code comes from the MyMVC framework, which gets the output of the control (a piece of HTML code) based on the specified user control and the data the control needs to display.

/ / renders the result with the specified user control and view data, and * returns the generated HTML code. / the user control should inherit the virtual path of the user control from MyUserControlView / View data / the generated HTML code public static string Render (string ucVirtualPath, object model) {if (string.IsNullOrEmpty (ucVirtualPath) throw new ArgumentNullException ("ucVirtualPath"); Page page = new Page (); Control ctl = page.LoadControl (ucVirtualPath) If (ctl = = null) throw new InvalidOperationException (string.Format ("specified user control {0} not found." , ucVirtualPath); if (model! = null) {MyBaseUserControl myctl = ctl as MyBaseUserControl; if (myctl! = null) myctl.SetModel (model);} / / place the user control in the Page container. Page.Controls.Add (ctl); StringWriter output = new StringWriter (); HtmlTextWriter write = new HtmlTextWriter (output, string.Empty); page.RenderControl (write); / / you can also use the following methods. / HttpContext.Current.Server.Execute (page, output, false); return output.ToString ();}

The whole code is divided into the following steps (I have separated it with a blank line):

1. Check the parameters.

two。 Create a page container and load user controls.

3. Set up the display data required for the page (view).

4. Add a user control to the Controls collection of Page.

5. Call RenderControl or Execute to let Page output the HTML code.

6. Returns the result.

This code is simple, and the only thing worth introducing is step 5, which can be called to get the HTML code for the control's output.

The difference between RenderControl or Execute is:

RenderControl does not support server controls because it takes advantage of a unique way of compiling pages, which I have analyzed in previous blogs.

Execute can support server controls because it executes a complete page life cycle.

Note: even if you use Execute, the above code can only support some simple server controls, because some complex server controls need to be run in HtmlForm. Therefore, if you need to support all the server controls, you must also create a HtmlForm object, adjust the inclusion relationship, and remove the resulting extra HTML code.

If you need to generate the HTML code generated by the entire page, you can refer to the MyMVC framework, where there is complete code to implement this function.

A new understanding of the Eval () method

I think a lot of people have written code like this:

What I'm talking about here is the call to Eval (), not the Repeater control.

Eval () can read not only the properties of a bound data item, but also a data column in DataTable. It can also perform more complex binding calculations:

* items in the order:

Of course, for data binding on the page, using Eval () is not a performance method, but it is recommended to use strongly typed conversion.

Sometimes, especially when writing reflection applications, there is often a need to parse from strings and implement evaluation calculations. So, in the previous example, is the function of Eval () worth digging? I think the answer is yes.

By analyzing the binding code of ASP.NET, I found that Eval internally calls the static method DataBinder.Eval, which is signed as follows:

/ / evaluate data binding expressions at run time. / / Parameter: / / container: / / the object reference against which the expression is evaluated. This identifier must be a valid object identifier in the specified language of the page. / expression: / / Navigation path from container to the public property value to be placed in the bound control property. / / this path must be a string of property or field names separated by dots, such as "Tables [0] .DefaultView. [0] .Price" in C# or "Tables (0) .DefaultView. (0) .Price" in Visual Basic. / returns the result: / / System.Object, which is the result of the evaluation of the data binding expression. Public static object Eval (object container, string expression)

Through this signed comment, we can easily see its usage.

Let me give you an example of applying it to unbound applications:

I have a class:

The definitions of public class TestEvalClass {public List Orders {get; set;} / / Order and OrderDetail are omitted, which I think you can imagine. }

Then the following code can be run:

Static void Main () {TestEvalClass testObject = GetTestEvalClassInstance (); string productName = (string) System.Web.UI.DataBinder.Eval (testObject, "Orders [0] .detail [0] .ProductName"); Console.WriteLine (productName);}

For this example, it doesn't matter what I want to output.

I just want to say: if you are asked to parse that expression, will it be more troublesome? now there is a ready-made one, is it very convenient to use?

Can be extended without a base class

In an ASP.NET site, if we want to add a function to all the pages, we usually think of using the base class to do it. This is indeed a very effective way, but not the only way, there is also a way to easily implement this requirement, and that is to use PageAdapter.

In the course of writing my blog, I wrote a lot of sample pages that included some submit buttons. However, in order to make the sample code look primitive (simple), I tried not to use server controls. Therefore, we are faced with the event handling problem of the submit button. In the sample code in the blog [elaborate on ASP.NET Cache and its advanced usage], I began to use PageAdapter, which makes the code simple and easy to reuse later (just a few files need to be copied).

Some people may think that it is better to use a base class to extend the functionality of all pages.

I have no objection to this view at all.

However, the advantage of PageAdapter is its pluggability (similar to the advantages of HttpModule). However, I designed this extension just to try another way.

In fact, Microsoft designed PageAdapter to deal with the compatibility of various browsers, but I applied this feature to extend the functionality of Page. HttpModule can enter any stage of the ASP.NET request pipeline, but it just can't enter the life cycle of the page. With this method, we can use the [plug-in] method of HttpModule to enter the life cycle of the page, which I think is very meaningful.

There are so many ways, I don't think it's a bad thing. Each method has its own application situation. If you know more methods, you will be able to make a better design in the future.

This time I came up with this topic because of the sample code in the previous blog [more on ASP.NET Forms authentication]. Some people look at the code and find that it works in a special way, so today I'm going to focus on this approach.

Let's review the sample code from previous blogs, starting with the page code:

Normal login: a custom login containing [user information]: UserId: GroupId: 1 indicates the full name of the administrator user:

In this page code, I define two forms that contain their own submit buttons (which is only part of the code).

Let's take a look at how the background processing code responds to submission requests:

Public partial class _ Default: System.Web.UI.Page {[SubmitMethod (AutoRedirect = true)] public void NormalLogin () {/ / omit the login processing code. / / if you need to know this code, you can browse to the following URL: / / http://www.cnblogs.com/fish-li/archive/2012/04/15/2450571.html} [SubmitMethod (AutoRedirect = true)] public void CustomizeLogin () {/ / omit the login processing code. / / if you need to know this code, you can browse to the following URL: / / http://www.cnblogs.com/fish-li/archive/2012/04/15/2450571.html}

Notice that the names of these two C # methods are the same as the name properties of the two submit buttons on the page, so you can guess that these two C # methods can handle the submit requests of those two submit buttons. So how does these two pieces of code work? Some people may see the use of [SubmitMethod] and think it has something to do with them. In fact, this statement is not true, I can not use them at all. Remember: Attribute is always just a tag, and it can't make the code run automatically.

The previous code works, related to the Page.browser file in the App_Browsers directory, which has the following code:

A MyPageAdapter is defined here, which is used for the request process of the Page control. RefID= "Default" means to add some configuration to the Default.browser file defined by ASP.NET, which will match requests from all browsers.

Let me take a look at the MyPageAdapter code again:

[AttributeUsage (AttributeTargets.Method, AllowMultiple = false)] public class SubmitMethodAttribute: Attribute {public bool AutoRedirect {get; set;} internal sealed class MethodInvokeInfo {public MethodInfo MethodInfo; public SubmitMethodAttribute MethodAttribute;} public class MyPageAdapter: System.Web.UI.Adapters.PageAdapter {private static readonly Hashtable s_table = Hashtable.Synchronized (new Hashtable ()) Private static MethodInvokeInfo [] GetMethodInfo (Type type) {MethodInvokeInfo [] array = s _ table [type. AssemblyQualifiedName] as MethodInvokeInfo [] If (array = = null) {array = (from m in type.GetMethods (BindingFlags.Instance | BindingFlags.Public) let a = m.GetCustomAttributes (typeof (SubmitMethodAttribute)) False) as SubmitMethodAttribute [] where a.Length > 0 select new MethodInvokeInfo {MethodInfo = m, MethodAttribute = a [0]}) .ToArray () S_table [type.ToString ()] = array;} return array;} protected override void OnLoad (EventArgs e) {base.OnLoad (e); if (Page.Request.Form.AllKeys.Length = = 0) return; / / did not submit the form MethodInvokeInfo [] array = GetMethodInfo (Page.GetType () .BaseType) If (array.Length = = 0) return; foreach (MethodInvokeInfo m in array) {if (string.IsNullOrEmpty (page. Request. Form [m.MethodInfo.Name]) = = false) {m.MethodInfo.Invoke (Page, null) If (m.MethodAttribute.AutoRedirect & & Page.Response.IsRequestBeingRedirected = = false) Page.Response.Redirect (Page.Request.RawUrl); return;}

This code is not long, and the core code is even less.

The most important piece of code is the implementation of MyPageAdapter, which inherits System.Web.UI.Adapters.PageAdapter and rewrites the OnLoad method (which is equivalent to overriding Page's OnLoad method), and it is because of this rewriting that the code has a chance to be executed in the life cycle of the page, which HttpModule cannot do.

The following things are done in the OnLoad method:

1. Check to see if a form submission has occurred.

two。 Gets all [SubmitMethod] decorated methods for the current page type.

3. Check to see if there is a C# method name corresponding to name in the submitted form data.

4. Called if a matching method name is found.

5. If AutoRedirect=true is set in [SubmitMethod], a redirection is raised.

Note: if base.OnLoad (e) is not called, the Load event for the page will not occur at all. In other words, PageAdapter.OnLoad is called before the Page.Onload method.

Because this code is only for me to use when writing the sample code, I don't check whether the parameters of the method to be called meet the conditions, nor do I optimize it deliberately to optimize its performance. In my design, the called method should have no parameters, so it is easy to judge, and you can use a fixed signature delegate to optimize it. Save these details to improve it later!

On how to understand ASP.NET Page to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.