p2p.wrox.com Forums

p2p.wrox.com Forums (http://p2p.wrox.com/index.php)
-   BOOK: Beginning ASP.NET 3.5 : in C# and VB BOOK ISBN: 978-0-470-18759-3 (http://p2p.wrox.com/forumdisplay.php?f=389)
-   -   Base Page and Master Pages (http://p2p.wrox.com/showthread.php?t=73103)

Will March 5th, 2009 10:10 AM

Base Page and Master Pages
 
In reading your book I have a question regarding Master Pages and Base Pages.

I read a thread in this forum where you describe Master Pages as defining the look and feel and the Base Page for the functionailty.

You then give an example of adding meta tags to the base page and then all the other pages inherit this functionality.

My question is can you not just do that in the Master Page?

I am working on a site at the moment and I have only used master pages as up until now I had overlooked the Base Page but the post has made me think about if there is a better way to go about it.

Basically in my master pages I have the basic structure for the website which I want all the other pages to inherit to keep the consistent look throughout. This is then linked to the a stylesheet which determines how the page should be styled. Great so now I have a nice styled consistent looking site.

Yesterday I created a google analytics account which requires you to put some javascript in your page so it can be tracked which is fine. Now I put it in my 2 master pages and it works no problem, but if I had set a base page for the project I could of just put it once in there and had the master pages inherit the functionality from the Base Page. I think in the book you have the Base page do that title tag empty check?

Is this the basic Idea of it?

Stylesheets for styling-widths, decoration etc?
Master Pages for structure-divs, content etc?
Base Pages for functionality-the title check thing you do, additional Javascript etc?

I only ask because up until now the point of a base page had eluded me because I was just updating my master pages and I just want to check that this understanding of it is correct?

And is this the best practice to seperate your styles, content and functionality this way?

Thanks in advance

Imar March 5th, 2009 05:47 PM

Quote:

Is this the basic Idea of it?
Not really; there are a few things wrong with your reasoning.

First of all, you can't have Master Pages inherit BasePage. BasePage (and all ASPX pages) ultimately inherit System.Web.UI.Page while a Master Page inherits
System.Web.UI.MasterPage. This means you cannot simply have the MasterPage inherit BasePage (although you could create a separate Master Page base page and inherit from that.

Secondly, a BasePage is mostly about logic, not presentation. I see a Google Analytics scripts more as presentation as it generate script that ends up in the browser. Although you could use code to create a new server control (like a Literal) and dynamically inject it in the page or head section, it doesn't feel right.

Personally, I don't mind duplicating a bit of static code like that in a few master pages. If you only want to add it once, you can always use a nested master page where the top most parent contains the Google tracking code.

YMMV of course. It's technically feasible to add this code to a BasePage, so you can always do it if you like the idea....

Cheers,

Imar

Will March 5th, 2009 06:21 PM

Ok your response has raised a few more questions with me-Lucky you!

All pages by default inherit the page class in the namespace system.web.ui This makes them act like web pages. Unless its a master page in which case it's a masterpage that it inherits instead of page.

The inheritance allows you to create multiple classes that inherit from each other and you can modfiy this inheritance to the BasePage instead of the page class? or do you inherit the page class and then the basepage class?

thinking about the logic that you would put in the base page could you give me an example? And you say the master page can't inherit from the Base Page but is that just me using the terms wrong? eg:

Could the masterpage.master file not have an inherits "namespacehere" ?

Or do you put that code in the codebehind files of the individual pages ?

In any case do you mean server side code runs on the basepage and client side code would be put in a master page or normal page?

I think thats it, my question might be abit jumbled there but I am trying to sort through it in my head aswell and keep thinking of things not necessarily in the most logical order.

Imar March 5th, 2009 06:39 PM

You don't inherit a "namespacehere", you inherit a "classnamehere" Although this sounds like nitpicking, it's an important difference.

Your ASPX pages have the behavior they have because they inherit from Page. The ASP.NET supplies a Page class with page-like behavior. As soon as you inherit from such a class, your page behaves like a Page as well.

Similarly, a MasterPage inherits from MasterPage which gives it MasterPage like behavior.

Consider a an example like Animal versus Cow. A Cow inherits from Animal which gives it animal like behavior. A Car inherits from Vehicle which gives it vehicle like behavior. You can't make a Cow inherit from Vehicle and give it wheels (although they seen to do that many years ago)

When you inherit from a BasePage, you introduce a new in-between later. So:

Code:


System.Web.UI.Page
  + YourPage

becomes:

Code:


System.Web.UI.Page
  + BasePage
    + YourPage

Likewise, you could have a new hierarchy for Master Pages:

Code:


System.Web.UI.MasterPage
  + BaseMasterPage
    + YourMasterPage

In order to do this, simple create a class similar to BasePage, call it BaseMasterPage (or whatever you see fit), let that class inherit MasterPage and make your master pages inherit your new BaseMasterPage class.

Quote:

thinking about the logic that you would put in the base page could you give me an example?
The BasePage in the Planet Wrox site has a good example: checking the title, although there are many more applications for a BasePage. Stuff like globally assigning titles, keywords, descriptions, security checks etc come to mind.

Quote:

And you say the master page can't inherit from the Base Page but is that just me using the terms wrong? eg:

Could the masterpage.master file not have an inherits "namespacehere" ?
No, it can't. MasterPage ultimately must inherit MasterPage, while pages must inherit Page somehow. An intermediate class (or more) is fine, as long as somehow some class inherits Page.
Quote:

Or do you put that code in the codebehind files of the individual pages ?

Not sure what you mean by this. Code can be put in code behind files of Pages and MasterPages and in "code classes" like BasePage.

Quote:

In any case do you mean server side code runs on the basepage and client side code would be put in a master page or normal page?
No, not at all. You can put server side code in Pages, MasterPages and in code classes. What I said was that stuff like Google tracking code is markup and as such belongs, IMO, in markup capable pages like those with an .ascx, aspx and .master extension. But again: it's a matter of preference. You could, as I said in my earlier post, generate client side code from server side code in a class Like BasePage. Not pretty, but it would work. If I weren't using MasterPages, I would put the Google code in all of my .aspx pages, or maybe I would create it programmatically in BasePage. However, since you're using MasterPages, they would be a perfect candidate for storing scripts like that.

Does this clarify things?

Imar

Will March 5th, 2009 07:08 PM

Yes and this is good because it is helping understand something that I obviously was abit confused about. Your analogy for cows a vehicles and cow vehicles (a hobby of yours?) is very helpful.

So to re-state:
you inherit something to make it behave a certain way. In my case like a page or a masterpage for pages and masterpages respectivly?

My next question is what is the namespace? Is that the system.web.ui and then the class file "page" gives it the specific behaviour of a page.

Is a namespace a collection of class files?

Sorry if this feels like you are going over the same point again.

So the BasePage is basically an extra class that you can add in that says "hey act like a page but a page that does this" ?

Quote:

No, it can't. MasterPage ultimately must inherit MasterPage, while pages must inherit Page somehow. An intermediate class (or more) is fine, as long as somehow some class inherits Page.
so you are saying

A page needs a page class but you can have an intermediate class called BasePage that inherits system.web.ui.page

Therefore you couldn't have a masterpage inherit it because it inherits a different class?

then to clarify (again) I would try to keep more of the markup code (html, javascript etc) in markup capable pages(.aspx etc) that is a better way of expressing what I was trying to say.

And stick more logic bits in the basepage that give it extra functionality than the normal class.

Which is what I mean't by server side code but that obviously that is wrong as you rightly state that can be put in other pages aswell.

Will March 6th, 2009 02:06 PM

did my post get through?

Imar March 6th, 2009 02:15 PM

Quote:

you inherit something to make it behave a certain way. In my case like a page or a masterpage for pages and masterpages respectivly?
Yes, correct. By inheriting a class, you actually *extend* it. So, you get everything your base class can do, and have the ability to add your own behavior. With the BasePage class, you get everything that System.Web.UI.Page can do, and the ability to check the Title propeprty (although that's just an example; you could do many more things of course).

Quote:

My next question is what is the namespace? Is that the system.web.ui and then the class file "page" gives it the specific behaviour of a page.
Is a namespace a collection of class files?

No, not really. Take another look at page 171 and onwards. Namespaces are just names you can make up to *uniquely identify) a class. The examples uses a (fictitious) Microsoft.Office.Word.Page class where Microsoft.Office.Word is used to avoid a name collision with the System.Web.UI.Page class.

They also allow you to easily group classes. In that respect your comment on a "collection of class files" is more or less correct. However, classes are compiled into DLL files (called Assemblies) which holds a collection of classes. These classes can be placed in many namespaces inside the same assembly. Also, a namespace can be spread out over multiple assemblies. So, the namespace are just used to group things logically, and are not really the "container of classes"....

Quote:

Therefore you couldn't have a masterpage inherit it because it inherits a different class?

Exactly. A MasterPage needs Master behavior; not Page behavior. Just as a Cow needs Animal behavior, and not Vehicle behavior.
Quote:

And stick more logic bits in the basepage that give it extra functionality than the normal class.
Exactly. By extending the base class, your class gets more behavior than its base class.

Hope this clarifies things further.

Cheers,

Imar

Imar March 6th, 2009 02:17 PM

Quote:

did my post get through?
If you can read it only here it did.... ;-)

I just don't have the time to watch there forums 24/7 ;-) I was typing a reply when I saw this post coming in....

Imar

Will March 6th, 2009 03:13 PM

lol sorry i dont mean to sound impatient i appreciate the help your provide.

Yup I re-read those couple of pages through today i liked the sentence

"Namespaces seem to cause alot of confusion with new developers" -didn't feel so stupid then lol.

So basically a namespace is a container used to sort of simplify/narrow down your search in the framework to add the specific functionality you are after. kind of.. can't think how to word it properly but I think I definatly understand it better now.

Imar March 7th, 2009 08:30 AM

Yes, more or less. But also to avoid name collisions, so you and I can both come up with a class with the same name, but each one placed in its own namespaces so the compiler understands which one you're referring to.

Imar

Will March 10th, 2009 12:15 PM

Ok thanks.

Sorry about delayed reply currently decorating and haven't had access to the internet for a couple of days.

Punikin January 22nd, 2010 03:53 PM

Master Pages vs Base Pages
 
I understand what you are saying here, but still am a bit confused.

master pages have code behind that allows them to execute functionality, and Content Pages also have code behind that executes functionality. Why can't functionality created on a master page not be called directly from the base page.

example. a master page that contains an ErrorSummary Control & a custom ErrorControl. The code behind has a virtual method to Show errors in the afore mentioned controls. My Content page doesn't see these methods and cannot ovverride them.

I can create a base page that can find the control then implement the method, but that seems so much more clunky and forced than to just keep things together. And doesn't Hierarchy imply inheritance?

Also what is the order that events/code is called if the master page isn't actually inherited?

Imar January 22nd, 2010 04:10 PM

Your page *can* see the master, but you need to cast it to an appropriate type.
For example, add this to your master"

public string GetStuff()
{
return "Hello World";
}

Then in your Page, add the following in Markup View:

<%@ MasterType VirtualPath="~/MasterPage.master" %>

where the VirtualPath attribute points to your master page. This causes the Master property to be strongly typed for the class defined in the master page's code behind.

Then in Code Behind, you can do this:

Label1.Text = this.Master.GetStuff();

The best way to answer the question about event order is to try it out. Wire up event handlers and set break points (or write to a Label), as explained in Chapter 14.

Cheers,

Imar

Punikin January 22nd, 2010 04:17 PM

Thanks, That really helps, i've been struggling with this for a few years now, and finally have the opportunuty to "re-design" our site in 3.5 and was hoping there was a fix to that problem. :-)

And i will try your suggestion about the events.

Imar January 22nd, 2010 05:04 PM

Tou're welcome. Glad I could help...

Cheers,

Imar


All times are GMT -4. The time now is 09:41 PM.

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.