Home
Github
Wiki
Videos
Contact
Sponsor
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`): ```cs 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.