provideEditingConfig(subject, editingConfig)

Using the class configuration options, title, thumbnail, and description, you can control how the Scrivito UI presents CMS object and widget classes, for example as an editor creates new pages and widgets. The following example provides a title, an icon and a description for a LandingPage class:

As an editor creates a page, the “LandingPage” type is offered nicely in the selection dialog:

The titleForContent and descriptionForContent functions define callbacks that determine the title of a CMS object or widget instance for display in the details view or the Content Browser. The instance concerned is passed to the function. In the following example, the headline and the description of an instance are derived from its equally named attributes.

If the headline attribute of the selected page reads “Why you should use our service”, the page will be presented in the Content Browser like shown above.

If no callback for titleForContent has been provided, the values of the contentTitle and title string attributes are used (in this order) if present. For descriptionForContent the object class name is used.

The Scrivito UI uses the text provided through descriptionForContent in places where a more verbose description of an item is appropriate.

The properties option lets you specify the list of attributes to be included on the “General” tab. If this configuration has not been provided, the tab will not be displayed for widgets, while for CMS objects the tab will only contain some pieces of system information. The order of the attribute names is acknowledged. If a title has been provided via attributes, it will be used. Otherwise, the title is derived from the attribute’s name; “backgroundColor” becomes “Background color”, for example.

Using the attributes definition, a title and a description can be provided for each attribute to specify how it should be displayed on the details view of a page or a widget. For an enum or multienum attribute, a values key can be provided to localize the available attribute values. Note that, for an attribute to show up on the “General” tab, it still needs to be included in the properties list.

Here’s an example of a LandingPage whose tags and backgroundColor attributes should be displayed on the “General” tab. The type of the backgroundColor attribute is enum, so we can also localize its values:

Attributes can depend on each other or become irrelevant if a specific option is chosen. To be able to handle this, you can specify a function for properties, which determines and returns the array of the properties to include. The SDK passes the Obj or Widget instance concerned to this function, allowing you to take account of this instance’s attribute values.

Here’s an example of a LandingPage whose backgroundImage or backgroundColor attribute is to be made available on the “General” tab, depending on the value of the pageStyle enum:

Instead of making attributes dynamically available, i.e. hiding them if they are irrelevant because of the current choices, you can disable them conditionally to avoid confusion.

In order disable or enable an attribute, specify a function for properties that returns the array of attributes to be displayed on the “General” tab. Each attribute can be enabled or disabled using the enabled key as an option as shown in the following example of a LandingPage whose backgroundImage or backgroundColor attribute is disabled depending on the value of pageStyle:

As with the properties option, if an attribute’s title has been specified in the attributes definition, it will be used in propertiesGroups. Otherwise, the title is derived from the attribute’s name; “backgroundColor” becomes “Background color”, for example.

In the following example, we want the facebookUrl and twitterUrl attributes to be made available on a dedicated “Social media” tab:

The initialContent option lets you specify the default initial content when creating new pages or widgets via the user interface.

Each key inside initialContent refers to an attribute in the Obj or Widget. Each value is either a value that fits the attribute’s type (compare Obj.create, for example), or a callback that returns such a value. If a callback is given, it is executed each time an Obj or Widget is initialized, and the returned value is used.

The provided initial content will be used:

• Whenever a new Widget or Obj is created using the UI (regardless of how this is done: menus, buttons, Content Browser – all apply the initialContent).
• Whenever a new Widget or Obj is created programmatically by the customer’s app using the Obj.create or new Widget API.
  

Initial content will not be applied if a new Widget or Obj is created by copying (or duplicating) an existing one.

When creating Objs or Widgets via the API, initialContent values are only given to attributes whose values aren’t set by the API call. In other words: If a Widget or Obj is created with an explicitly given value, the corresponding initialContent value is ignored.

Initial content may be provided for any custom attribute but not for system attributes.