Do a Web program, can modify very little program code in the case, easy to develop skin and switch skin, should be needed, who do not want to, in the website interface want to change the time, to be changed a large number of logical code.
The realization of a qualified skin mechanism system should do the following:
The-> page template has very little logical code (if the template has a large number of logical code, it is not known as a template).
-> can easily change the layout of the page without affecting the program code (. cs).
The customization of the new-> template can be done by the skin creator with reference to the old template, without the need for developers to intervene too much.
-> maintain performance.
Then, take a look at all the methods that are used to implement the so-called skin mechanism, while making some personal explanations for each method.
1. Change the page call CSS file to change skin.
This one, strictly speaking, should not be counted as a skin mechanism. Although the CSS is very powerful, can also through it to arbitrarily change the layout of the page elements, but its HTML is always the same, so the limitations are very large.
Advantages: Completely does not affect the performance, even can completely not by the service side code to manage its transformation, may use the JS to switch the skin (thus, in our set of perfect skin mechanism case, this method, can completely not with this mechanism conflict, lets the user make more personalization in the client).
Disadvantage: If as the core skin mechanism, very limited.
Examples: such as qq.com, 114LA. COM above some clickable small color block, is to change the call of the CSS file to achieve skin change.
2. Read the template file, replace the identifier for the content to display and data output.
The flexibility of this method is relatively high, each skin can have its own layout, has its own personality.
Implementation: For example, there is an identity $subject in the template, and the program code replaces it with the title of the article, and then there is an identity block <!-Loop[ArticleList]-->
Usually, we cache the content of the read template, but the replacement of the string is always unavoidable, or the replacement of the content is also cached, but this is tantamount to caching the template content and replaced the content, occupy two of seemingly repetitive content of memory (why?) Otherwise, it's not always necessary to do the IO operation every time the data changes. Read the template file, which seems to be worse than string substitution performance.
Advantages: The flexibility of the template is very high, you can arbitrarily change the layout of the page.
Disadvantages: Impact performance, developer maintenance difficult, must have a specific identifier to represent page variables, later maintenance may cause a lot of problems.
3. Use of ASP.net app_themes.
This method, should be a very poor method, simply asp.net a small head, chicken ribs, basically not practical.
Implementation: For example, the style of customizing a button is like this, <asp:buttonrunat= "server" backcolor= "LightBlue" forecolor= "Black"/> code like this, exists in the. skin file. Then its skin-changing mechanism is as follows, <%@ Page language= "C #" theme= "Default"%>. In the App_Themes directory, is a separate set of skin folders, each folder contains skin styles and picture files, etc., can also contain. skin files.
Advantages: Only asp.net
Disadvantage: Contains the disadvantages of the first method,. Skin's style customization also relies heavily on the use of ASP.net server-side controls, as well as performance and very low flexibility.
4. Dynamic loading. The ascx file (asp.net user control) uses. master (Master).
This approach, which should also be used by many people using asp.net, is sometimes used in conjunction with a third method. Small and medium sized projects can be used if the performance requirements are not very stringent.
Implementation: Dynamically load using LoadControl (). ascx files or (with) the MasterPageFile of the specified page (the target Skin folder) implementation (usually. ascx and. Master are also used in combination).
Advantage: The flexibility is extremely high, each skin has the independent layout, uses directly. CS file variables and methods etc ... Even each skin has its own independent code file.
Disadvantages: Impact performance. Interested in being able to decompile LoadControl methods. At the same time, in the page to use <%%> this code block, sometimes feel a bit indecent.
5.XML + XSLT
Legend has it that XML replaces HTML as a trend?? Not clear, do not understand. It should be impossible. I didn't get a thorough understanding of this approach, but probably it was supposed to happen? 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 famous Belgian waffles with plenty to 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"?>
<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>
|
What is the benefit of doing this, I have not experienced.
6. Read the template file, generate the. aspx file into a separate folder for each set of skins, and specify these folders through address rewriting.
The final effect of this method for the user, and the second method should be similar, the advantage is that the performance is relatively high, but also can be used directly. CS code inside the variable method etc ... In addition, there can be no <%%> code blocks exist, can exist in their own template language, as the second method of $subject, <!-Loop--> identifiers in general.
Advantages: Almost no performance impact, only the first read build. aspx files require loss of performance. Flexibility is extremely high. Template code readability can also be achieved very high.
Disadvantage: When starting to read the analysis time (however, this should be a small problem), in addition, a set of skin, it will generate a corresponding one. aspx file (this can be solved, of course).
7. Use the VirtualPathProvider that asp.net2.0 started to achieve.
Virtual file mechanism. This, should be considered as the sixth method of the enhanced version. The final effect is almost the same as the sixth, but it does not generate those. aspx file, and instead, it's long in memory.
Implementation: Implements two classes, one inherits to VirtualPathProvider, and one inherits to Skinfile. VirtualPathProvider There is a fileexists method, rewritten to determine whether the path of the request is the skin file path, if it is, getfile on the instance of a skinfile (this skinfile, we will deal with the template, You can have your own template language. There is also a getcachedependency method that can be used as a cache-dependent file for the virtual file mechanism, and it will then reparse the template file once the template file has been modified. Let's not go into the details here, but check out the MSDN documentation for more information.
Advantages: Same as 6.
Disadvantage: The first start requires loss of performance (but it is unavoidable).
8. There are more methods of implementation, but also used, the individual does not publish the opinion, such as: the use of buildprovider, but this one, need to have a strong lexical analysis and grammar analysis capabilities.