Custom Editor Settings for Editor Templates

when developing editor templates for your ViewModels, you may require customisation for your editor templates. for example, the PuckPicker editor template, which is used for content picking, has editor settings to determine things such as how many items a user is allowed to pick.

there are two ways to add editor settings.

1. settings are added/edited in the Settings section of the admin backoffice on the "Editor Parameters" page.
2. settings are added to properties of your ViewModel using attributes

in both cases, settings are regular classes. if you go with strategy 1 and you want them to be editable in the backoffice, your settings class needs to implement the I_Puck_Editor_Settings interface which is in the puck.core.Abstract namespace. these settings are then saved against a ViewModel type and optionally against a Property of that ViewModel.

if you want to add your settings via strategy 2 (via an attribute), your settings must inherit from Attribute.

let's use the PuckPicker editor template again as a reference, in the source code for this editor template, settings are retrieved at the top of the file with this code (which is found here - /areas/puck/views/shared/editortemplates/puckpicker.cshtml):

var settings = this.PuckEditorSettings<PuckPickerEditorSettings>()
        ??new PuckPickerEditorSettings(){
            AllowDuplicates=false,AllowUnpublished=true,MaxPick=2,SelectionType="both",StartPath=null
        };
    

as you can see, settings of type PuckPickerEditorSettings are requested and if they don't exist, defaults are set. your editor settings can be any regular class, it just needs to implement I_Puck_Editor_Settings for it to be editable in the backoffice or inherit from Attribute to decorate a ViewModel property with.

there are some important things to note about how these settings are retrieved. when this.PuckEditorSettings<T>() is called from within an editor template, it will first attempt to retrieve attribute settings of type T from the current property, if it's not present, it will attempt to retrieve the stored settings of type T from the database. so if the user is editing a Homepage ViewModel, it will try to find editor settings of type T stored against the ViewModel type Homepage. it will also take into account the current property being edited, so if the property being edited is called RelatedContent it will try to retrieve the settings of type T for the ViewModel Homepage and the property RelatedContent. it works recursively. if a setting is not found for the current ViewModel and Property being edited, it will look for just the ViewModel and if that returns nothing, it will look for the base type of the ViewModel until it gets all the way to BaseModel.

so a good way to save global settings for all ViewModels is to store the editor settings against the BaseModel type (in the backoffice). you can't do this with attribute based settings.