SitePoint Sponsor

User Tag List

Results 1 to 4 of 4
  1. #1
    SitePoint Guru Chroniclemaster1's Avatar
    Join Date
    Jun 2007
    Location
    San Diego, CA
    Posts
    784
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    my first base page class

    I've worked with some websites like this, but I've never formally tried it with any understanding that this was in fact what I was doing. I want to make sure I understand conceptually what I'm doing. You know, before I do anything stupid.

    A base page class seems to make sense to me because it's a more object oriented approach. You build the base class so that you can call it one time and not have to write the same code page after page after page, right?

    This involves resetting the partial class of every .aspx page from the default name (whatever the webpage name is). And renaming it to whatever the name of your base class is, and for consistency you probably name the one code behind file with that name. e.g.

    page1.aspx
    page2.aspx
    page3.aspx
    .
    .
    .

    All list a partial class of BasePageClass. This partial class is also written into the code behind file, and for ease of reference name the code behind something like BasePageClass.aspx.cs; how does that sound? OK?

    Next, for the functionality, the base page class is going to allow me to condense C# code, not interface elements, correct? If I want a navbar on every webpage, I would write that into the master page, not the base page class. (At least not unless I want to generate the whole navbar on the fly using C# code, probably not the best idea). The base page class holds all the C# code for sending email or accessing the database, etc. provided those functions are needed on every page.

    Finally a flat out question. When I build a javascript, I call my main file, sitewide.js and then if necessary I call a special file to handle javascript functions specific to that page, so page1.aspx calls page1.js in addition to the sitewide file, page2.aspx calls page2.js, etc. I've never seen a .aspx page call two classes. If I'm using a base page class to encapsulate the functionality that all pages need, how do I include the functionality specific to that one page? Include EVERYTHING in the base page class? I'm just and idiot and you call two partial classes (like I call two javascript files)? Include page specific code directly in the .aspx page and damn code separation? What's best practices?
    Whatever you can do or dream you can, begin it.
    Boldness has genius, power and magic in it. Begin it now.

    Chroniclemaster1, Founder of Earth Chronicle
    A Growing History of our Planet, by our Planet, for our Planet.

  2. #2
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,633
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    You've got alot of things "backwards" there.

    First, you don't change the partial class in every page. Rather, you inherit from a class you create. It should be a .cs file without an .aspx element.

    Now, this base page class' point in life is to be little more than glue. One thing I often use it for is to provide a communications channel out to master page elements, for example. It definitely should not contain any code for emailing or accessing the database--that is what normal classes are for.

  3. #3
    SitePoint Guru Chroniclemaster1's Avatar
    Join Date
    Jun 2007
    Location
    San Diego, CA
    Posts
    784
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So best practices would be to make each of these classes, including the base page class, a .cs file (e.g. myEmailClass.cs and myBasePageClass.cs). And these would be stored in App_Code?
    Whatever you can do or dream you can, begin it.
    Boldness has genius, power and magic in it. Begin it now.

    Chroniclemaster1, Founder of Earth Chronicle
    A Growing History of our Planet, by our Planet, for our Planet.

  4. #4
    SitePoint Wizard
    Join Date
    Feb 2007
    Posts
    1,274
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No, best practice would be to avoid using the base page until nessecary. In your case you could just implement a EmailHelper class. In your page code simply create an object of this type and call its methods.

    In some cases such "helper" classes can be defined static and thus only contain static methods.

    Only use the base page approach when you really need to modify what a page "is", not what functionality it should be capable of. The difference is subtle, but it is there.

    As I explained elsewhere the base page approach is a one-shot solution. You could imagine a EmailPage (which can send emails using member methods). You can also imagine a PdfPage (which has methods for generating pdf's). Now, when you need a page which can send a pdf in an email, what do you do? Yes, you could create an EmailPdfPage which holds methods for both pdf and email handling. But you cannot inherit both sets of methods from the the respective page types. Because .NET only supports single inheritance you will have to implement either the Email methods or the Pdf methods all over again.

    Instead define an EmailHelper class and a PdfHelper class. Use these classes on your pages. If you pull in instances of both classes you can let your page code interweave calls to product a pdf email.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •