i am using c# as programming language.i wish to inlude page to the main page. such as footer and header are common pages to all the pages.
please anybody can solve this problem.
Rahul
You want to do some research into ‘Master Pages’.
yes thanks, i was thinking about master pages. but still i am new and unfamilier about it. so plz if u have any supportive article u suggest me
You also want to look up web user controls. Just go to msdn and look it up
masterpages overview: http://msdn2.microsoft.com/en-us/library/wtxbf3hh.aspx
user controls: http://msdn2.microsoft.com/en-us/library/y6wb1a0e(VS.71).aspx
I’ve been dealing with the same issues on my site. SSI, Master Pages, etc. There are three ways I’ve been looking at.
1) Use Master Pages: The master page contains as much structure for your webpages as you want. Then you can isolate content on a separate page which references the master page. The server adds the master page structure in when the page is requested.
Pros: Not too hard to use. Easy way to get consistent layout across a site. Sort of structural equivalent to what CSS does for appearance.
Cons: It’s your straight jacket. The whole point of master pages is to provide structure so it inherently forces you to abide by it. This can get really dicy when you need to make changes that require you to move anything from the master page to the content pages or vice versa. So you pretty much DON’T want to do that.
2) Use SSI: The server grabs the relevant file and throws the code into your page. Pretty simple.
Pros:Really easy to do.
Cons: SSI is your slowest option. Thanks to CSS, you can pretty much dump the whole thing in as one chunk and position it where you want, but still.
3) Integrated Pages: This is really simple, you don’t import any XHTML or .NET code into the file. Your webpage code stands by itself. (assuming you don’t count the code behind, the DB, the style sheet, the external javascript…).
Pros: Reduced server load and faster downloads. All page structure is contained in one file.
Cons: Consistency is harder to maintain, you can’t wing your site, you actually have to plan. (Master pages shield you from your own stupidity - a bit). Updating the site requires a lot of find and replace. (That’s actually good and bad. The bad is that it takes more time than updating one master page. The good is you can do ANYTHING. Master pages don’t give you that kind of flexibility)
I’d incorporated SSI in my pages, and I’m in the process of going back to take it out. I’m not using master pages either. They’re very similar to the Dreamweaver Template technique and some of the guys I’ve talked to have seen that go wrong… badly, when you update the site later. I’m just going to have all the code incorporated and use the Replace tools to handle site maintenance later.
Also, I’m confused. I appreciate the power of customized user controls, but I don’t understand how it applies to appending material from an outside file to your webpage? How is this used?
use master link
or use <iframe>tag
To chroniclemaster1,
Master pages are really the standard in ASP.NET for setting a layout now, and I really dont’ see how there could be any cons at all. They’re easy to update and you can pretty much do anything with them, even nesting them if required.
Also with your third point, how does that allow for faster downloads or less server loads?
Anyway I’d highly discourage #3, and also #2. Master pages are working just fine for me.
When I need to set something in the master page from the child page, I use an idea wwb_99 gave a while back and have the parent page type of each page implement some interfaces, which then the pages can set and the masterpage can read from. It’s been working great.
^^^What devbannana said. And IFRAMES are not a valid option either, unless you like bad SEO.
As 'banna points out, the biggest trick is creating effective communication channels between your page classes and your master pages without tying your pages to a specific master page implementation. I wrote a little article on the subject, which you can find here.
Off Topic:
Jesus, has it been 11 months since I wrote that?
Hi!
I use CSS for layout. I avoid most of the presentational properties of the .NET controls unless I’m building a winform. I don’t think there’s really any alternative in that case, and I use them freely.
Wyatt’s webpage is literally the most I’ve ever looked into master pages, so please correct any blunders. A master page is still ultimately delivering XTHML in response to a vistor’s http request. You’re breaking up the structure and possibly some of the content (like the command strip in your example). That sounds essentially the same as Dreamweaver templates which my Dreamweaver teachers swore me off of when I was using DW. It’s catch 22, either 1) your master pages are very basic and you still have a lot of repetitive code on your pages, or 2) your master pages are very detailed and structured creating a fairly comprehensive straight jacket. You get to build the straightjacket, and you can create multiple implementations with nested master pages, but still. Either way, your XHTML is being split up, it’s just a matter of how much. When I was working in DW, there were a couple different instructors who’d had to throw out template based websites (and/or knew friends who had) because clients wanted changes that were not capable of being implemented. They had to go back and rebuild the websites from scratch. I never understood the particulars, but it seems like site maintenance should be an important part of website design. And you can bet that if there’s a design change that can’t be made in your website, that’s the first change your client will ask for.
On point 3, my assumption (and this may be one of those ***.u.me cases[:D]) is that the page would require more server resources than if it didn’t have to go grab the master page. It’s still the same basic process as a SSI, correct? Grabbing information from an external file? I’m sure the master page is tuned for much better performance than SSI; it’s all part of the .NET framework after all. But doesn’t it still require the extra processing.
Any details would be most greedily read.
The master page is very flexible, more so than a template. You can change anything in them easily, as shown in wwb_99’s link-to blog post. Maintenance is a lot easier than if you included the layout in every page. 
You can still use CSS; I don’t know where you got the idea that you could not.
Also, you really are misunderstanding how ASP.NET works. It is not a parsed language like PHP or the like. It doesn’t go and "fetch"the master page. It is all compiled in, at worst on the first request. Don’t try to shave off milliseconds and compromise maintainability.
In programming you should never repeat yourself. master pages allow you to prevent doing this to the greatest extent, and is about the best method available for such. A similar concept is used in several frameworks in other languages, but IMO none of those are nearly as flexible as master pages in ASP.NET.
[edit]Can you give an example of where you think master pages would be limiting? i’ve not found them to be such at all. When I needed something to be set per-page, I used wwb_99’s method or a variant of the same. For instance when I wanted to set the meta description on each page, I created an IMetaHolder interface implemented by the base page class. Each page does something like:
((IMetaHolder)this).Description = "description";
Then the master page does:
IMetaHolder metaHolder = Page as IMetaHolder;
if (metaHolder != null)
{
DescriptionMeta.Attributes["content"] = metaHolder.Description;
}
I used a similar method when setting the content of the h1 tag on each page (sometimes it can be text, by default the title of the page, or an image, or an image link).[/edit]
First, to get you up to speed on MasterPages, there is no better place to start than this article by K. Scott Allen. It should help demystify things for you.
Now, the best thing to do here is forget Dreamweaver templates. I am not particularly familiar with them, but they are essentially tools that let you “compile” a web page within a given html container to make it easy to maintain similar look & feel across a website. All fine and good so long as things are static and you don’t anger the compiler.
The other thing to remember is, as devbanna points out, ASP.NET does not work in a streaming fashion like PHP or SSI. Rather, it works by composing objects which do eventually get turned into a stream and sent back to the browser.
Finally, MasterPages are far from straightjacketing. First, you can have multiple content zones. And those can even have default content so you don’t have to worry about them on every page. Furthermore, because they are full-bodied controls with codebehind, you can manipulate them programmatically if necessary. For example, the current app I am working on will have as many masterpage templates as the users desire, and one can switch any page between the templates allowing for a centrally managed website with easily brandable sections and even individual pages.
Interesting, so the master page really is completely different from SSI. When you say that they’re compiled in at first request, it sounds like you’re not even talking about the user’s first request, but the first request of the very first user. Something like server caching of database, so that once it’s been read by the server, it’s resident and can be fed back in response to any http requests?
OK, well at worst, I’ve got a couple guys who told me I’d hate myself if I didn’t use Search and Replace, and a couple guys telling me it’s all about the master pages. So I guess I’ll just have to try it and see for myself. We’ll see if I can break something, and then I’ll be back to see if you can help me fix it!
Regarding your question about caching, what I mean is that ASP.NET is compiled. You can precompile it so that the web server never has to do it on any request, or you can allow ASP.NET to compile the web site in place when a page is changed. Both really result in the same thing in the end; the code is compiled and so is much faster than any parsed/interpreted language.
I don’t know what languages you have experience with, but it seems you really have some getting used to of the ASP.NET paradigm.
Anyway, as wwb_99 said, the page is just a hierarchy of objects that are rendered as the page. It’s not going and fetching any external resources or anything. If I remember correctly, the master page is actualy implemented as a child of the page object. There’s a Master property of the page class that contains the master page object if one exists.
The performance overhead of master pages is absolutely minimal. Pulling the performance argument on master pages shows complete lack of understanding how ASP.NET works.
Indeed, ASP.NET executes fully compiled. And fully compiled means that the pages are actually compiled all the way to native machine code.
NERD ALERT: The following is rather technical and understanding it is not required to use Master Pages
What can be confusing is that there’s actually several compilations and intermediate code levels on the way down to machine instructions:
ASP.NET parses the .aspx file and produces a (partial) class which is compiled combined with whatever codebeside is associated with the page (the .aspx.cs or .aspx.vb file). The result of this compilation is a class represented in IL code. IL is Intermediate Language, sometimes also called CIL or MSIL.
The IL code is then compiled into machine code. And finally the code executes. This compiled code is also kept in a secured cache which is managed by the .NET runtime. If a request comes in for the same .aspx file (need not be the same user), the .NET runtime simply fetches the code from the cache and thus bypasses the compilation steps. The cache has cache dependencies which ensure that if you touch any of the files the compiled code will be evicted from the cache. Upon next request for the page this will guarantee a new compilation.
As wwb said, an ASP.NET page is not merely script, like e.g. PHP or classic ASP. Rather, a page in ASP.NET is compiled into a class with initialization code which (once it is executed) builds the control tree of the page. Your code then manipulates this control tree (follows the Composite GoF design pattern), and finally the tree is traversed and each node is asked to “render” itself in a depth-first fashion.
The control tree is where ASP.NET gets its strength, especially its composability. If you are curious about it you can switch on tracing (Trace=“true” in the @Page directive). This will document the exact control tree for the page as it looked at rendering time.
Back to the Master Pages. A master page is compiled as a separate unit (as is user controls). It is not compiled in with the content page. Curiously, a master page is actually more a control than it is a page - but that’s for another day. All it need to is to hook into the initialization of the control tree.
The content page is the one handling the request. When a master page is in play the content page initializes its content regions, but delegates the initialization of the control tree to the master page. The master page then goes back to the content page to look up the content (sub trees) for the individual regions. The result is a control tree in which the controls of the master page and of the content page are neatly combined.
As you see, even though the master page is compiled into a separate unit, there is a protocol/contract which allows it to play efficiently with the content pages. Indeed it is so decoupled that if you edit a master page, only the master page will be recompiled. Although the content pages are going to run with a changed control tree, it doesn’t affect their code at all.
As wwb said, the Master Page is incredibly versatile. You can even have code in the content pages which during the pre-init phase dynamically sets which master page they should be rendered with.
A master pages also has its own, dedicated controller. It can be used to implement e.g. login functionality and will then work on every content page. It will not interfere with the content page controller.
If content regions are too coarse for your particular requirement, you can expose properties and/or methods from the master page. These methods can be called by the content pages to manipulate the control tree or do other stuff. It can be that from some pages you want to “hint” the adrotator to rotate another set of ads.
Master Pages are one of the most compelling features of ASP.NET. Once you get to know them you will never look back. Promise.
one question about master pages… is there anyway to reference two separate content pages within one master?
in other words, you have a master page that has a mainContent placeholder and a subContent place holder. your user navigates to the mainContent page and the master is applied BUT is there anyway to call or relate a second content page into the subContent placeholder at the same time?
I don’t think you are quite getting master pages–the user actually navigates to a page that has stuff to populate the ContentPlaceHolder controls.
Now, one could dynamically populate any or all of the placeholders rather than writing ASPX code directly into the PlaceHolder by adding items to the various PlaceHolders Controls collections.
the user actually navigates to a page that has stuff to populate the ContentPlaceHolder controls
sorry, that is what i meant, only badly worded…
not sure i understand how you would dynamically populate the second placeholder though…
I’d say that’s accurate.
My dad was an old time programmer, Pascal, FORTRAN, that kind of stuff. So I’m familiar with compiling code down to Assembly and assembling that down to Machine Language. But that’s all stuff inside the box. I’m still trying to wrap my head around how servers chew up the webpages. Let’s see how well I can butcher what you’re saying.
I upload my webpage, .aspx, to the server. This trips an alert on the server that information in the cache of machine language:confused: has changed, and it needs to be updated. Whether it’s a normal webpage as in this example, a master page, or whatever, the next visitor to hit the server triggers a recompile of that page (and ONLY that page, even if it’s a master).
The page is complied into it’s partial class. The codebeside (if any) is compiled in as well to create a full class. The webpage now exists as a class that’s in MSIL (the first time I’ve understood an explanation of where THAT comes from by the way, Thanks) Then the .NET runtime (is this what’s also referred to as the CLR?) compiles the MSIL down into machine language. The machine language is then cached and as the final step, the server sends out the http response to the first visitor’s request. The second visitor simply gets the compiled machine language that’s been cached, QED. Until of course, a new page is uploaded triggering the process all over again.
OK, how’d I do?
I’ll save my comments on control trees and gardening and the importance of forestry to the environment for the next time.
Pretty impressing. You are a fast learner!
Yeah - as a rule only the page/usercontrol that was changed is compiled. Exceptions to the rule is when another page somehow references the changed page. This is obviously very common for user controls because you must @Register them before use. But other directives also has the effect of setting up dependencies which can cause the dependant pages to recompile as well.
And any change to files in the App_Code folder triggers not only a “build”; it also causes the hosting process to recycle. See if you can figure out why.
If more than one page needs (re)compilation, ASP.NET by default tries to recompile all of them upon the first request by any user. It does so in “batches”. Through configuration you can tweak the maximum number of files, batch size etc.
Also, there’s more deployment options with ASP.NET. What we’ve talked about here is the simple copy model. It is as simple to deploy using this model as with any scripted language. The compilation is performed completely transparent by the web server. You can literally develop ASP.NET websites with no other tools than notepad.
Another model is to compile the entire site and deploy the site as one or more compiled assemblies. Because of some IIS strangeness the site still needs some pseudo .aspx files, however.
A hybrid model called “updateable” allows you to change the templates (.aspx) files, but the codebehind and App_Code is deployed as assemblies.
Note that compiled here means IL. The final compilation (from IL to machine code) always take place on the target machine. This is a security measure as this compilation also checks if your code tries to break out of the sandbox and injects code to validate at runtime. Also, the final compilation may take the target architecture into consideration when performing optimizations.
Thanks for bringing the thread on-topic again.
What you need to understand here is that the actual content page references the master page, not the other way around.
A master page is simply like an (advanced) template; it doesn’t “know” who references it.
It may define multiple content regions, identified by their IDs. Other master pages may define content regions using the same IDs. If so, the master pages are interchangeable. One may put the navigational panel on the left, the other may render it at the right.
A content page may reference the master page in its @Page directive (or set it up in code). Then it may specify content for the content regions defined by the master page. It is actually very much like virtual method overrides.