Meta tabs and siteprofile.yaml

"Meta tabs" is a new feature where the RTD (and other 'Edit Documents') will add standard and custom file properties (contenttypes) to a panel next to the rich content. These properties are then managed together with the standard "Save and Publish" workflows (ie changes to eg. a header image won't go live before the whole file is published).

YAML siteprofiles are a reformulation of siteprofiles as YAML with a focus on reducing redundant syntax (DRY - Don't Repeat Yourself) and reducing the effort it takes to add metadata fields to the CMS. The WHFS type members defined in YAML siteprofiles support richer metadata (eg. title, maxValue) which allow WebHare to build the user interface to enter this metadata by itself. You will only need to override WebHare's choice where the defaults are insufficient.

In YAML, contenttypes and their fields will now always have titles so WebHare has a way to refer to these fields in its UI.

YAML based site profiles separate the components used to edit content type data from their layout. When setting up a type:

• the title/tid for a WHFS type can be explicitly set
• the title/tid for a member is set in its type member definition
• a field has a type which sets its initial value constraints (eg a string field has a maxBytes: 4096 constraint)
• the type member can define additional value constraints
• the type member can explicitly set a component to use

When building field editors (ie. tab extensions) YAML siteprofiles only need to 'apply' a type to edit. Optionally they can:

• specify a layout (the fields to show and their order)
• override fields, where they can
  • override the title
  • add further value constraints
  • set the component to use (and its properties)
  • override the properties of the component defined by the field or implied by the constraints

Contrast this with XML siteprofiles where:

• fields only have a name and a type - no further metadata, titles or constraints
• a tabsextension must be fully defined before any field will be visible or editable
• a tabsextension must be fully redefined if you want to change a component property.

Our goal is to be able to auto-configure components such as textedit and imgedit purely based on the field type and any value constraints. eg. setting a 'maxLength: 15' constraint should create a properly sized textedits. Explicitly overriding the properties of such a component should hopefully be rare

Defining a type

Setup a xxxxx.siteprl.yml file. Preferably xxxxx should match the typeGroup used below if your siteprofile actually defines types and doesn't just set Apply rules

Types are defined under the types: key in YAML. A siteprofile should also set a typeGroup which is used to derive the full scoped name of a type

typeGroup: global
types:
  page: # the full scoped type name will then be `mymodule:global.page`
    members:
      myFirstMember:
        type: string

Setting up a field editor

apply:
  - to:
      type: http://www.webhare.net/xmlns/publisher/richdocumentfile
    editProps:
      - type: page # or: `mymodule:global.page`

The name editProps will probably change during WH5.6 develompent

Using custom components

Type fields that cannot use an existing component can set a custom tollium component. This component:

• must accept and deliver the field value through the components value property. (ie: not through composition/cellname)
• will receive properties from the siteprofile through the SetYamlProps method.
  • YAML properties are converted to snake case (eg. maxValue becomes max_value) before being sent to HareScript
• implement the dirtylistener interface as the document editor will not enable the Save button without a Dirty event.
  • Add EXTEND this BY TolliumIsDirtyable in NEW()
  • Invoke ->SetDirty() whenever the value is changed by the user (and not by receiving a value in the value property)
  • Pass this->dirtylistener to all subcomponents if needed

Good to know

• This blog item will be regularly updated
• editProps requires a layout to be set before it shows anything, even if only layout: all. We need this because otherwise any use of editProps to eg. override a property without having an editProps intended to actually properly render the fields, will cause all fields to appear anyway
• Feedback on this document or the syntax is welcome on https://groups.google.com/a/webhare.dev/g/developers
• We're also working on improving consistency and clarity in the technical terms surrounding WebHare. See https://www.webhare.dev/reference-next/glossary/
• YAML syntax will still change in this and later versions, eg. to improve (internal) consistency and reduce repetition. It's not a stable interface yet!