Scrivito.ContentTag

Renders a CMS object’s or a widget’s attribute value and makes it editable.

Renders an attribute value of a CMS object to a DOM element. The content can be edited by a logged-in Scrivito user.

Props

  • attribute (String) – the name of the attribute to be rendered.
  • content (Obj, Widget) – the page or widget holding the attribute.
  • tag (String) (optional) – tag name of the DOM element. Default: div
  • [New in 1.34.0 (BETA)]dataContext (Obj, DataItem) – a CMS object or a DataItem to be used as a data context for all child components of this ContentTag. The corresponding DataItem can be obtained in any of the child components via Scrivito.useDataItem. If a child components itself uses a ContentTag with the dataContext property, it will override any previously specified data contexts.
  • [New in 1.49.0]renderEmptyAttribute (Boolean) – if set to false, Scrivito.ContentTag components with an empty attribute value are not rendered on the live site and in “Preview” mode. This prop has priority over contentTagsForEmptyAttributes. Default: undefined.

Other props are rendered as HTML attributes of the resulting tag.

Props for widgetlist attributes

  • widgetProps (Object) (legacy) – props to be passed individually to every widget contained in the widgetlist attribute. A property named widget will be ignored and cause an error to be logged.
    New code should use the more versatile React Context instead of widgetProps. For further details, please see Passing additional data to widgets below.


Example: Basic usage

Example: Specifying a CSS class name

Example: Making a date attribute editable using a placeholder

Note that the InPlaceEditingPlaceholder component is not part of the Scrivito JS SDK but of the Scrivito Example App.

Passing additional data to widgets

Usually, a widgetlist attribute contains several widgets of different types, each based on an individual class with its set of attributes, rendered by an individual component. In general, widgets are independent of the container widget they live in (the widgetlist attribute) and vice versa. This reduces coupling, which is good.

However, sometimes there’s business logic requiring a container widget and the widgets it contains to be coupled more tightly, making it necessary to pass data from the container down to the widgets inside. If, for example, an EmployeeListWidget allowed to contain only instances of the EmployeeListItemWidget type acts as the data source of the latter widgets, it can communicate this piece of information to them via a React Context. The context is passed individually to the contained widgets. Here’s an example of how the “employee list” use case could be implemented: