Archives for the month of: July, 2010

Wow, less than a week since it’s release, and the Editors Manual, co written by David Conlisk and myself, has managed to take the number 1 slot as our.umbraco.org’s best rated project, beating off some major contenders including Doug Robar’s ImageGen and Warren Buckley’s CWS.

Having been sat on my laptop for the past six months or more half-finished, a chance discussion with David, who had also started a manual of his own, pushed us to work together to get something out there. The goal itself was pretty simple, keep it generic, and keep it focused purely on your bog standard editor, and I think the end result was pretty awesome, if I do say so myself (and it seems the community thinks so too).

Personally, I am so proud to have been able to contribute something that the community values so highly, and I hope it stands as a good example of how anybody can contribute, even if you can’t yet code those killer extensions.

So what’s next?

Myself and David are working hard to get the content into the wiki which is now tied in to the context sensitive help in Umbraco v4.5.

We are also looking for people to translate the Editors Manual into other languages to make it available to an even bigger audience, so if you’d like to help, just hit the project page and make a request to contribute.

Finally got round to cleaning up my AutoExport2DotNet package, which I entered in the CodeGarden10 package competition.

For anybody who wasn’t there, this package allows you to automatically export your Linq to Umbraco classes in Umbraco v4.5 every time you make a change to your doc types. Classes can be exported as either .cs class files, or a compiled .dll, and are also machine name dependant so that the output directory can be configured differently per developer, and so that exports don’t occur on your production servers.

For more information on the different configuration options, checkout the AutoExport2DotNet our.umbraco.org project page.

As with any other ASP.NET application, sometimes you have actions that only need to occur once at application startup. The standard .NET way to do this would be to modify the global.asax file and add your logic in the Application_Start event handler

public class Global : System.Web.HttpApplication
{
    protected void Application_Start(object sender, EventArgs e)
    {
        // Insert your startup logic here
    }
}

Unfortunately in Umbraco, all sites are required to use the built-in umbraco.Global class.

So how DO you register an Application_Start event handler in Umbraco?

The trick is to create a class that inherits from umbraco.BusinessLogic.ApplicationBase, wich is a special base class  built-in to Umbraco.

So what make ApplicationBase so Special?

Well, when Umbraco first starts up, it will search the bin directory for any class that inherits from ApplicationBase and automatically instantiate that class.

The main purpose of ApplicationBase is generally for hooking into all of the Umbraco events, but as classes are only instantiated at the time of startup,  it’s also a great alternative to the Application_Start event handler.

public class MyApplicationBase : umbraco.BusinessLogic.ApplicationBase
{
    public MyApplicationBase()
    {
        // Insert your startup logic here
    }
}

So there you have it. Registering an Application_Start event handler in Umbraco.

UPDATE – July 11, 2010 19:59

Thanks to a tip off by Ismail, it turns out that in Umbraco v4.1 upwards, you can now simply inherit the umbraco.Global class and override the Application_Start event handler (and any other global.asax event handler for that matter).

public class MyGlobal : umbraco.Global
{
    protected override void Application_Start(object sender, EventArgs e)
    {
        base.Application_Start(sender, e);

        // Insert your startup logic here
    }
}

Knowing this, I would probably now say, if you are working on Umbraco sites in version v4.1 or greater, to go with Ismails suggestion, but if you are working on older versions, or want to maintain backwards compatability, then I’d stick with the ApplicationBase method.

UPDATE – July 12, 2010 22:12

Thanks to another tip off, this time by Aaron Powel (aka Slace), it seems there is a way in versions prior to 4.1, to inherit from umbraco.Global. All you need to do is create your own global.asax file, inheriting from umbraco.Global, and delete the App_global.asax.dll from within your bin folder (if it exists). I can’t say I’ve tested this myself, but definitely another one to try, especially if you need to hook in to other global.asax event handlers.

One thing I would bear in mind though with this method, is if you were to upgrade from one version to another, you may get a new App_global.asax.dll file in you bin folder, so don’t forget to delete it (unless you upgrade to v4.5, in which case I’d just use Ismails method).

Well there you have it, we started off with no standard way to hook into the Application_Start event handler, and have ended up with 3. So, depending on your circumstances, there should be at least one method that suites your needs.

Follow

Get every new post delivered to your Inbox.