Nibble

Xslt and RestExtensions in Umbraco 4.6 (Juno)

Umbraco 4.6 Beta (Juno) went out a couple of days ago, this is just a quick post highlighting one of the improvements.

As you may know if you want to register an xslt or rest extension you’ll need to do this in a config file (config/xsltextensions.config and /config/restextensions.config) but now with umbraco 4.6 you’ll be able to do this with some attributes instead.

So no more messing around with the config files(although they still work) but simply add a reference to the umbraco assembly and then you’ll be able to use the XsltExtension, RestExtension and RestExtensionMethod attributes to mark your extensions.

using System;
using umbraco;
using umbraco.presentation.umbracobase;
 
namespace UmbracoJunoTest
{
    [RestExtension("TestAlias")]
    [XsltExtension]
    public class Test
    {
        [RestExtensionMethod]
        public static string HelloWorld()
        {
            return "Hello World";
        }
    }
}

 

You can either place the .cs file in the App_Code folder of your umbraco installation or build the solution and place the assembly in the bin directory.

Want to give it a try ? Download Umbraco 4.6 Beta

11 Comments so far

  1. tarekahf on December 28th, 2010

    Just to make sure I understand this.

    So, now you can extend the Umbraco functinoality to be accessed from the outside world using REST APIs ?

    Or,

    You will be able to use REST APIs in Umbraco to access the the functions which are hosted in the outside world ?

    Tarek.

  2. Tim Geyssens on December 28th, 2010

    @Tarek,

    The RestExtensions are used by /base http://our.umbraco.org/wiki/reference/umbraco-base

  3. Niels Henriksen on December 28th, 2010

    Now thats cool. Instead of need to mess with the .config the code can do it by itself.

  4. Morten Bock Sørensen on December 28th, 2010

    I am wondering if there will be any option to disable this sort of extensions? The scenario I am thinking of is this:

    I install a package A, which contains lots of functionality, including some xslt extensions. I am not using the extensions in my xslt’s, and they are causing some sort of problems when being loaded on xslt renderings.

    Now I want to remove the extension, without uninstalling the entire package. Since it would not be in any config files, would it maybe be nice to have the option of choosing to “do not load” on certain extension classes?

  5. Hartvig on December 28th, 2010

    @Morten: What problems could loading a class cause to your XSLT renderings?

  6. Morten Bock Sørensen on December 28th, 2010

    @Niels: I was mainly thinking of cases where the class constructor would throw exceptions, but I see that they are in a try/catch block. (Might be nice to log if it fails at adding the extension). Another reason could be if the extensions constructor has some sort of performance hit, or otherwise does something that I would prefer that it didn’t.

    Might be the responsibility of the author of the extension, to not do anything like that in the constructor?

  7. Tim Geyssens on December 28th, 2010

    @Morten, it’s static methods so no constructor… But we should indeed log the failing ones (will be updated for the final release).

  8. Morten Bock Sørensen on December 28th, 2010

    The Activator.CreateInstance(xsltType) method will call the default/parameterless constructor of the xsltType class, so the methods would not have to be static, making it possible to load for example dependencies only once for each macro rendering, instead of doing it on each method call.

    But it might not be standard practice to do so.

  9. Julius Bartkus on January 14th, 2011

    hey :)
    how using this example to turn off returnXml ?

    Cheers,
    Julius Bartkus

  10. Ben on January 25th, 2011

    Julius,

    You can use [RestExtensionMethod(returnXml=false)] you can also set permissions in a similar way.

    Ben

  11. Can on May 13th, 2011

    @Morten & @Tim, even in 4.5.2 I have been able to create an xslt extension without using any static methods. This has made me wonder: how did we originally come to the static methods only conclusion? Is this perhaps a legacy issue?

    Can

Leave a Reply