Go Back

Making Sitefinity Control Templates Exportable

Sitefinity ASP.NET CMS can be extended using traditional ASP.NET Custom Controls.  These controls, once compiled, can be distributed and shared between Sitefinity web sites.

Support for templates can be added to Custom Controls by inheriting from the SimpleControl class.  These templates allow the control to be customized on a per web site basis by replacing the default template.

Replacing Control Templates

The original control relies on specific controls found in the template.  If a custom template is used and these controls are missing, the control will crash.  Consequently, it’s useful to have the original template to get information about the template requirements.

Unfortunately, this might be impossible.  The original template will be contained in a DLL file and the source-code unavailable.  Consequently, retrieving the original template becomes difficult.

As of this writing, the only way to retrieve the original template is to ask the programmer for it.  In the case of the Sitefinity controls, the Sitefinity team has already made all of the templates available

However, Sitefinity 4.0 (not yet released) will introduce a web-based tool that can be used to export embedded templates.  Making use of this features requires some extra code.

Adding Support for Sitefinity 4.0’s Template Export Tool

To add support for Sitefinity 4.0’s export tool the following class must be added to each assembly that contains exportable templates

This code is boiler-plate.  It can be copied & pasted without any modification.  The reason this class needs reproduced is because this is an internal class. 

/WebSysTemplate.cs

using System;
using Telerik.Web;

namespace SitefinityWatch.WebControls
{
    /// <summary>
    /// This class defines the attribute for specifying embedded templates
    /// </summary>
    [AttributeUsage(AttributeTargets.Property)]
    internal class WebSysTemplate : EmbeddedTemplateAttribute
    {
        public WebSysTemplate(string resourceName, string description, string defaultExtPaht, bool isFrontEnd, string lastModified)
            : base(resourceName, description, defaultExtPaht, isFrontEnd, lastModified)
        {
        }

        /// <summary>
        /// Gets the description.
        /// </summary>
        /// <value>The description.</value>
        public override string Description
        {
            get
            {
                return base.Description;
            }
        }

        /// <summary>
        /// When implemented in a derived class, gets a unique identifier for this <see cref="T:System.Attribute"/>.
        /// </summary>
        /// <value></value>
        /// <returns>An <see cref="T:System.Object"/> that is a unique identifier for the attribute.</returns>
        public override object TypeId
        {
            get
            {
                return typeof(EmbeddedTemplateAttribute);
            }
        }
    }
}

Once the WebSysTemplate class is in place, the following [WebSysTemplate] design-time attribute must be added to the LayoutTemplatePath property of the custom control.

[WebSysTemplate(MadLibs.MadLibsTemplateName, "This is a description", "/SitefinityWatch/MadLibs.ascx", true, "2009-08-06")]
public override string LayoutTemplatePath
{
    get
    {
        return base.LayoutTemplatePath;
    }
    set
    {
        base.LayoutTemplatePath = value;
    }
}

The [WebSysTemplate] attribute tells Sitefinity:

  • The name of the Tempate
  • A description for the template
  • The path to export the template
  • If this is a frontend template
  • The data associated with this version of the template

Conclusion

As mentioned, the template export feature does not yet exist.  This feature will be introduced with Sitefinity 4.0.  This feature will eventually make it much easier to provide customizations to controls included with Sitefinity, as well as custom controls.

Comments  4

  • Brook 09 Aug

    Very cool feature, thanks for the details.
  • Lino Tadros 09 Aug

    Great addition Gabe, thanks!
    I am still very concerned about producing Sitefinity controls in DLLs that will work in different versions of Sitefinity.  Everytime Sitefinity releases a patch or a new release, these DLLs will have to be RECOMPILED because they are referencing specific versions of the core DLLS.  There has to be a better way to do this otherwise it will be a total mess for opening the platform to 3rd party module developers.
    Can you imagine if Telerik had to recompile and redistribute their radcontrols to all their customers everytime Microsoft released an update to their core DLLs?

    Cheers
    Lino
  • Michael 09 Aug

    thanks for another great post Gabe
  • Bob 12 Aug

    Hi Lino,

    This an interesting subject that you are bringing up.

    Actually we had this discussion a few times internally, and I still think the current approach is the best. The standard approach to workaround recompiling is to add binding redirects in the configuration file. Another approach is to reference assemblies by partial names instead fully qualified in you projects.

    Isn't that how .Net framework core assemblies work also? I think this is precisely the reason we provide separate builds against .Net 2.0 and 3.5.

    We are open to any suggestions though, so please guys speak out. Now is the right time to include such improvements for 4.0.

Post a comment!
  1. Formatting options
       
     
     
     
     
       
  2. I'm sorry for the CAPTCHA. You have spammers to thank for this: