About ASP. NET skin mechanism implementation

It is necessary to create a WEB program and easily develop skin and switch skin when few program codes are modified as much as possible. No one wants to change the skin, you need to change a large part of logic code.

The implementation of a qualified skin mechanism should be as follows:

-> The Page Template requires very little logical code. (If the template has a large number of logical code, this is not called a template ).

-> You can easily change the page layout without affecting the program code (. cs ).

-> The new template can be customized by the skin maker by referring to the old template, without the need for too many developers to intervene.

-> Maintain performance.

Next, let's take a look at the methods that everyone uses to implement the so-called skin mechanism and give some personal instructions on each method.

1. Change the CSS file called by the page for skin replacement.

Strictly speaking, this should not be regarded as a skin mechanism. Although CSS is very powerful, it can also be used to arbitrarily change the layout of page elements, its HTML remains unchanged, so the limitations are very large.

Advantages: it does not affect the performance at all, or even can be managed by the server code. JS can be used to switch the skin (as a result, when we have a set of perfect skin mechanism, this method does not conflict with this mechanism, so that users can be more personalized on the client ).

Disadvantage: as the core skin mechanism, it is very limited.

Example: some small color blocks that can be clicked on QQ. COM and 114LA. COM are used to change the called CSS file for skin replacement.

2. Read the template file and replace the identifier with the content and data output to be displayed.

This method is highly flexible. Each skin can have its own layout and personality.

Implementation: for example, if the template has an identifier $ Subject, the program code will replace it with the article title, and then there will be an identifier block <! -Loop [ArticleList] -->

Normally, the template content we read is cached, but replacement of strings is always inevitable, or the replaced content is also cached, it is equal to caching the template content and the replaced content, occupying two memories that seem to be quite repetitive (why? Otherwise, you should not read the template file for IO operations every time the data changes. This seems to be worse than string replacement ).

Advantage: The template is highly flexible and you can change the page layout at will.

Disadvantage: it affects the performance and is difficult for developers to maintain. A specific Identifier must be provided to represent the page variables. Later maintenance may cause many problems.

3. Use ASP. NET App_Themes.

This method should be a very poor method. It is basically a small plug-in ASP. NET and is not practical.

Implementation: for example, to customize a BUTTON style like this, <asp: buttonrunat = "server" BackColor = "lightblue" ForeColor = "black"/>, similar to this code, exist in. in the skin file. The skin replacement mechanism is as follows: <% @ Page Language = "C #" Theme = "default" %>. Under the App_Themes directory, it is an independent folder of various skins. Each folder contains skin styles, image files, and so on. skin files.

Advantage: Only ASP. NET has

Disadvantages: it includes the disadvantages of the first method. The style customization method of. skin also relies heavily on ASP. NET Server-side controls, and also affects performance and flexibility.

4. dynamically load the. ASCX file (ASP. NET user control) | use. master ).

This method should also be used by many people who use ASP. NET. Sometimes it will be used in combination with the third method. Small and medium projects can be used if the performance requirements are not strict.

Implementation: Use LoadControl () to dynamically load the. ASCX file or (and) the MasterPageFile of the specified page (the target skin folder) (usually. ascx and. master will be used together ).

Advantages: extremely flexible, each skin has an independent layout, directly using the. CS file variables and methods ETC... Even each skin has its own code file.

Disadvantage: performance is affected. If you are interested, you can decompile the LoadControl method yourself. At the same time, when you want to use the <%> code block on the page, sometimes it feels a bit indecent.

5. Xml + xslt

What is the trend when xml replaces html ?? I don't know. It should be impossible. I have never been familiar with this method, but should it be like this? Each XML (output data) has a corresponding XSL file (control style ). As follows:

Xml file:

<? Xml version = "1.0" encoding = "ISO-8859-1"?>

<Breakfast_menu>
<Food>
<Name> Belgian Waffles </name>
<Price> $5.95 </price>
<Description> two of our famous Belgian Waffles with plenty of real maplesyrup </description>
<Calories> 650 </calories>
</Food>

<Food>
<Name> Cakes </name>
<Price> $1.95 </price>
<Description> sweet cakes </description>
<Calories> 2650 </calories>
</Food>

</Breakfast_menu>
 

Xsl file:

<? Xmlversion = "1.0" encoding = "ISO-8859-1"?>

<Html xsl: version = "1.0" xmlns: xsl = "http://www.w3.org/1999/XSL/Transform" xmlns = "http://www.w3.org/1999/xhtml">
<Body style = "font-family: Arial, helvetica, sans-serif; font-size: 12pt; background-color: # EEEEEE">
<Xsl: for-each select = "breakfast_menu/food">
<Div style = "background-color: teal; color: white; padding: 4px">
<Span style = "font-weight: bold; color: white">
<Xsl: value-of select = "name"/>
</Span>
<Xsl: value-of select = "price"/>
</Div>
<Divstyle = "margin-left: 20px; margin-bottom: 1em; font-size: 10pt">
<Xsl: value-of select = "description"/>
<Span style = "font-style: italic">
<Xsl: value-of select = "calories"/>
</Span>
</Div>
</Xsl: for-each>
</Body>

</Html>
 

What are the advantages of doing so? I have not experienced it.

6. Read the template file, generate the. aspx file to the independent folder of each skin, and specify these folders through address rewriting.

The final effect of this method should be similar to that of the second method. The advantage is that the performance is relatively high and the variable method ETC in. CS code can be directly used... In addition, the <%> code block does not exist. You can use your own template language, just like the $ Subject in the second method. <! -Loop --> General identifier.

Advantage: performance is almost not affected. Performance Loss is required only when the. ASPX file is read for the first time. High flexibility. The template code can also be highly readable.

Disadvantage: The analysis time needs to be read at startup (however, this should be a small problem). In addition, if there is a set of skins, it must generate a corresponding set. ASPX file (of course this can be solved ).

7. Use VirtualPathProvider, which is only available in ASP. NET2.0.

Virtual File mechanism. This should be an enhanced version of the sixth method. The final result is similar to the sixth one, but it does not generate those. ASPX files. Instead, it is stuck in the memory.

Implementation: implements two classes, one inherited to VirtualPathProvider and the other inherited to SkinFile. In VirtualPathProvider, there is a FileExists method, which is rewritten to determine whether the request path is a skin file path. If yes, GetFile instances a SkinFile (this SkinFile, We will process the template, you can have your own template language ). In addition, there is a GetCacheDependency method that uses the template file as the cache dependent file of the Virtual File mechanism. Once the template file is modified, it will re-parse the template file. I will not go into details here. For details, refer to the relevant documentation of MSDN.

Advantages: Same as 6.

Disadvantage: performance loss is required for the first startup (but this is unavoidable ).

8. There are more implementation methods that have never been used. I will not express my opinion first, for example, using BuildProvider. However, this one requires strong lexical analysis and syntax analysis capabilities.