During Code Cabin 16 (woo #codecabin16!) @mattbrailsford asked us to remind him to add an empty constructor to DittoMultiProcessorAttribute. Instead I've added in the code myself (feature sniping! :/)
The reason for this was to allow more sophisticated parameter/property binding through the inherited DittoMultiProcessorAttribute.
Example of this would be the following.
public class TitleAttribute : DittoMultiProcessorAttribute
{
public string TitlePropertyAlias { get; set; }
public TitleAttribute()
{
base.Attributes.AddRange(new[]
{
new UmbracoPropertyAttribute(TitlePropertyAlias),
new AltUmbracoPropertyAttribute("Name")
});
}
}
Where as the traditional way to achieve a similar thing would be:
public class TitleAttribute : DittoMultiProcessorAttribute
{
public TitleAttribute(string titlePropertyAlias) : base(new[]
{
new UmbracoPropertyAttribute(titlePropertyAlias),
new AltUmbracoPropertyAttribute("Name")
})
{
}
}
This is a fairly simple example but there could be better uses with this new flexibility. I've also added in a unit test to prove out the results of a traditional DittoMultiProcessorAttribute is the same as the new empty constructor DittoMultiProcessorAttribute.
During Code Cabin 16 (woo #codecabin16!) @mattbrailsford asked us to remind him to add an empty constructor to DittoMultiProcessorAttribute. Instead I've added in the code myself (feature sniping! :/)
The reason for this was to allow more sophisticated parameter/property binding through the inherited DittoMultiProcessorAttribute.
Example of this would be the following.
Where as the traditional way to achieve a similar thing would be:
This is a fairly simple example but there could be better uses with this new flexibility. I've also added in a unit test to prove out the results of a traditional DittoMultiProcessorAttribute is the same as the new empty constructor DittoMultiProcessorAttribute.