Singelton Nodes (rules for nodes)

[johannesmutter]

As a developer I may want endusers to use certain node types only once in a document. They can place it anywhere where the node type is allowed, copy/ extract and paste, reorder it, etc. But it should only exist once in the document.

Candidates of such node types are:

In case of a website builder: FooterNode, TopMenuNode, CookieBannerNode, Alert/NotificationbarNode
In case of a google doc style editor: TableOfContentsNode, EndnotesNode (for footnotes)
In case of a newsletter tool: EmailHeaderNode, EmailFooterNode, EmailPreviewLineNode, ManageSubscriptioNode

In the last example as a developer I may even want to make it a requirement that the "ManageSubscriptioNode" is present in the document, so deletion is not possible.

[michael]

What you can do already to express singletons is to use a 'node' property:

  nav: {
  	type: 'node',
  	node_types: ['nav'],
  	default_node_type: 'nav'
  },
  footer: {
  	type: 'node',
  	node_types: ['footer'],
  	default_node_type: 'footer'
  }

In editable website, I ensure that all node properties always have a valid value (so they can't be null), which

On node arrays i'm still hesitant to introduce any cardinality rules such as "at most one Hero" or "Optional Hero at position 0" or "Optional Footer at last position" as it gets quite complex fast, and drives edge cases, that could lead to rejected cut/copy/paste actions at best or inconsistent data at worst.

Maybe it's better to have such rules in app-land and provide hooks in places where you need to enforce them (e.g. for oncopy, onpaste). Then the app can make specific rules it can reason about, and we don't need to introduce a general rule-system, and bloat the node schema specifications.

[johannesmutter]

yes, also think this belongs to app land. But hooks would make it much easier, e.g. reject during onpaste if node of type X is already present; alert user; …