Hi mate

I think you're on the right track with your thinking. I'm no expert but the way I tend to do it is have a SiteSettings.cs document type which contains the properties that are to be on the home page, and then have a GeneralPage.cs document type which caters for the main internal pages.

The GeneralPage.cs does NOT inherit from the SiteSettings.cs file (SiteSettings could be called HomePage.cs)

Within my General.master I have a SiteHeader.ascx user control which contains all of the references to css files and js files. There is a PageHeader.ascx file which generally contains top menu.

I then build user controls for elements such as footer, calls to action etc.

After this, if I have a requirement for another template, I have a nested masterpage, inheriting from General.master which means that everything in the General.master will be included on my new template, including all server controls, but only need to be called once.

Another useful tip is to say use the same codebehind in user control to do different things, depending which page.

So for example you have a menu on "About.aspx" and on "Qualifications.aspx" you have the the same menu, but with a further dropdown menu, I'd use the same pages and controls, and in the code say if(currentPage.name == "Qualifications") { and build the additional menu in here}

This saves from having to build a new user control just for the sake of that one additional menu.

Hope this helps, but feel free to come back to me if you don't think it will and I'll be glad to help where I can - You can catch me anytime on Twitter.

Thanks Richard,

You have raised some interesting points there that are in many ways similar to the approach I have been taking. With regard to getting Settings node content in any page / User control I have come up with the following approach:

I have a standard settings class based on uSiteBuilder:

namespace MyProject.DocumentTypes
{
    [DocumentType(Name = "Settings",
        IconUrl = "cog.png"]
    public class Settings : Vega.USiteBuilder.DocumentTypeBase
    {

...

    }
}

I then have a Settings helper class:

using Vega.USiteBuilder;
using uComponents.Core;

namespace MyProject.Helpers
{
    public static class Settings
    {
        private static int _settingsNodeID;

        static Settings()
        {
            _settingsNodeID = 0;
            foreach (DocumentTypeBase child in ContentHelper.GetChildren(uQuery.GetRootNode().Id,true))
            {
                if (child.NodeTypeAlias == "Settings")
                {
                    _settingsNodeID = child.Id;
                    break;
                }
            }
        }

        public static bool Located
        {
            get { return _settingsNodeID != 0; }
        }

        public static DocumentTypes.Settings Content
        {
            get 
            {
                if (_settingsNodeID != 0)
                    return (DocumentTypes.Settings)ContentHelper.GetByNodeId(_settingsNodeID);
                else
                    return new DocumentTypes.Settings();
            }
        }
    }
}

I can then get any value from the Settings node using the following syntax:

value = Helpers.Settings.Content.propertyName;

I've yet to check perfomance with this approach but it is working well in a simple test.

Once again any comments welcome.

Hi Matthew

Sounds like we're talking about pretty much the same thing.

I'd be interested to see what the difference in page loads would be compared to my way.

The only thing I'd say is that this way is always going to return an object of DocumentTypeBase, so how would you deal with pages that have a different document type? Would you require another helper file, or another method within that helper file? With the above you would likely get an error if the nodes you're trying to access are of a different document type.

This is why I tend to separate these out into codebehind in the user controls, but your way may well turn out to be better - like I said, I'd be interested to see.

Let me know how you get on please.

Hi Richard,

I would only take this approach for document types that should only have a single instance like the settings node. (If the user creates more than one then the first match will be used)

The 'Content' function within the helper returns my specific settings document type by casting the DocumentTypeBase object returned by ContentHelper.GetByNodeId function. The helper class knows that it is the correct type to support the casting beacuse it has already macthed the doctype Alias. You are right though that this means if I wanted to repeat this process for another doctype then another helper class would be needed, but I think for me this would be infrequent so I'm happy with that.

The advantage to me is that I only need a single line of code in my usercontrols codebehind to grab a settings node value.

Hopefully I've minimised the peformance hit by putting the node search logic in a static class static constuctor so it only happens once with the first request (again this would not work so well if I thought the location of the settings node might change between calls to the 'Content' method, but in this case once the node is there it will probably never be deleted or a new one be created, so this should be safe too)

Feel free to grab the code an compare performance, it would be interesting to see a comparison.

I may well take a look at this in one of my freelance apps, just to see if there's a benefit.

I still think though with regards to reusing elements, it's easier to use nested master pages and user controls; All content nodes using that template will automatically have all of these elements included without having to repeat calls (even if it is just one line of code) to have them included on the page.

Of course if you have a new page which has elements which appear only on that page, AND had the elements from another template, then a new template created as a nested masterpage will again mean not having to repeat any code, just the new code for those elements not appearing elsewhere.

You might be making it more complicated than it needs to be :) But I am definitely interested in seeing if the performance improves.

Hi Richard,

It sounds like either I am missing something obvious here (quite possible and the reason why I posted in the first place!) or perhaps we are talking at cross purposes. Perhaps I could use a simple example:

• In the content there is a page of the "Settings" doc type immediately below the Home Page node.
• In the settings doc type there is a property that holds the Google Analystics code ie "UA-XXXXX-X"
• In the main masterpage (ie on every page on the site) we want to include the Google Analytics script block with the GA code if the field has been populated.

Ah I see,

Ok well what I do there is have GoogleAC as a textString property in siteSettings.cs doctype.

In the siteHeader.ascx control I have links to stylesheets etc, and in the codbehind I get the actual analytics code from the GoogleAC property

this way, whenever siteHeader is used, it looks up that property and displays the code on every page it's on

does that make sense?

It does make sense and it sounds like we are doing exactly the same thing, but probably just using different methods to get the value from the property from the settings node in code behind for our controls.

Out of interest how do you grab values from your settings node in code behind?

Int32 RootNode = Convert.ToInt32(ConfigurationManager.AppSettings["Root"]);

Node RootPage = new Node(RootNode);

String TitleText = String.Empty;

TitleText = RootPage.GetProperty("siteName").Value.ToString();

Have to register "Root" inin web.config like;

where 1059 is the rood node ID

Hope this makes sense also - It's always good to see how other people do things, even if it just tells you there's nothing wrong with how you do it :)

Sorry, I don't know how to add code snippets on this forum :(

No worries, so long as it works :)

and thanks for teh tip about Preformatted - I've seen forums that actually have a button to "insert code snippet", thought maybe I'd missed something

Of course, all of this changes when we move to Umbraco 5 :D

Richard

is working on a reply...