<%@ page language="c#" codebehind="default.aspx.cs" inherits="example._default" %><%@ register tagprefix="example" tagname="template" src="/includes/template.ascx"%><example:template title=”example of page templating” id="template" runat="server" > <body> here lies the page content. </body></example:template>this is about as simple as a templated page gets. you should have a vague idea what everything here means but i’ll explain everything starting at the top. the page directive isn’t specific to this project so we won’t detail it’s meaning. the register directive simply tells asp.net that we’re going to be using the template located as /includes/template.ascx. what’s that you say? user control? why yes it is. the thinking in making a template a user control is this: you write c# in a c# editor and html in an html editor. obvious? maybe. but i’ve seen templates proposed that are implemented as a custom control (written in a code editor, not an html editor). it’s just easier to write html in the vs .net html editor just as it’s easier to write c# in the c# .net editor and with user controls we’re allowed this luxury. intellisense anyone? you could say sure, you can design the template in the html editor the convert it to c# rendered output but then enters the question of maintainability. no designer i know wants to go in an edit a c# file and recompile the bloody web application. ok, now i’m hearing something about speed concerns? well granted compiled code custom control code is faster than the equivalent user control code but it is said that caching erases all your sins or was it cache is king, or maybe cache and thou shall be saved. whichever the case, by using simple native caching techniques in asp.net you can eliminate many of the slowdowns caused by dynamic pages. however, in the case where a page is generated uniquely for each view and also depending on the site load, speed may be the prevailing factor for which custom control page templates may be the answer. user control versus custom control concerns aside, let’s move on to the beginning of the template tags “<example:template>”. i should mention now that this example template was designed with simplicity in mind and customization should, nay, must be performed by you the reader in order to make this system truly useful. what do i mean by customization? well, take the title attribute for example. you don’t have to be a burt muston to realize the title attribute in the template tag corresponds to the title tag in the resulting html. using our imagination picture something else in addition to the title attribute, perhaps the path to a cascading style sheet, or maybe the keywords for the page that will end up in the meta tag. go nuts with it. use your imagination. i should say of course adding the type of customizations i just mentioned are as easy as proverbial pie and we’ll go over just such a change later. but moving on we see the body tag. body in this case is where the main content for the page goes. note: don’t confuse the body tag here with the body tag in “traditional” pages. in previous version of this system the body tag was called main until i realized that intellisense is fully functional when inside a body tag. at any rate, whatever you put in your body tags will show up in the template where you specify. in the spirit of customizations it should be said that having a body tag is simply a function of the needs of the page. so for example if each page needs a sidebar for navigation or whatnot you can add a sidebar tag that resides on the same level as the body tag in the templated page and likewise can put the contents of the sidebar where ever appropriate in the template. again, go nuts and use your imagination… more examples to come.
<%@ control language="c#" codebehind="template.ascx.cs" inherits="halloffame.includes.template" %><html> <head> <title> <%=this.title%> </title> <script runat="server"> /// <summary> /// insert the body the user provided in our body placeholder. /// </summary> protected override void createchildcontrols() { // insert the main content body if available if( null != body ) body.instantiatein( bodycontainer ); } </script> </head> <body> <table width="100%" height="100%" border="1"> <tr> <td colspan="2" height="80"><font size="1">header</font></td> </tr> <tr> <td width="100%" height="100%"></td> <td> <asp:placeholder id="bodycontainer" runat="server" /> </td> </tr> <tr> <td colspan="2" height="20"><font size="1">footer</font></td> </tr> </table> </body></html>the attentive reader will notice that there are only three things special to this page compared to any ordinary asp.net page. first, the <%=this.title%> which lies naturally in the title tag (and i’ll explain just how all this works later). second, the block of server code that contains the function createchildcontrols which basically takes the body content supplied by the templated page and drops it right where the asp:placeholder is waiting. which brings us to the third noteworthy bit of code and that’s the asp:placeholder which like we just mentioned is where the body content goes. using system;using system.data;using system.drawing;using system.web;using system.web.ui;using system.web.ui.webcontrols;using system.web.ui.htmlcontrols;namespace halloffame.includes{ /// <summary> /// the main template for this website. /// </summary> [parsechildren(true)] public abstract class template : usercontrol, inamingcontainer { /// <summary> /// the main content template. /// </summary> private itemplate main; /// <summary> /// the name of the page. /// </summary> private string title; /// <summary> /// the main content template. /// </summary> public itemplate body { get { return this.main; } set { this.main = value; } } /// <summary> /// the name of the page. /// </summary> public string title { get { return this.title; } set { this.title = value; } } web form designer generated code }}looking at this code we see a couple of familiar faces, namely the body and title properties. and in the world of user controls this is how you expose attributes. so remembering back to the example page we introduced near the beginning which looked something like this <%@ page language="c#" codebehind="default.aspx.cs" inherits="example._default" %><%@ register tagprefix="example" tagname="template" src="/template.ascx"%><example:template title=”example of page templating” id="template" runat="server" > <body> here lies the page content. </body></example:template>we see the title is set as a template attribute and the body is set as a sub-tag. and now referring back to the code behind the template the body is of type itemplate and the title is of type string bringing up some good questions. do attributes have to be strings? no, they can be integers any other type asp.net can parse from a string. and what is the itemplate type all about? it tells asp.net that the body property will contain children objects. what is parsechildren and why is it true? the parsechildren c# attribute tells asp.net that this class will be a container for child controls and those should be parsed as opposed to placing everything between the start and end tags in a literalcontrol object. how can i add more sections similar to the body section? simply and easily… by just declaring a member variable of the type itemplate and exposing it via a property. basically copy and paste the body blocks and rename accordingly. then in the template.ascx file place an asp:placeholder and in the createchildcontrols function instantiate the new section in the asp:placeholder. pretty easy, no?
新闻热点
疑难解答
图片精选
