Drawing children in a NodeView

Hi, I am trying to build a projectional editor (like Jetbrains MPS) using ProseMirror. I am creating a NodeView and I would like to be in control of where the different children are rendered inside the parent. Depending on their type I want to place it in different position. I understand that I should not set this.contentDOM in my NodeView, however I am not sure how I can:

  1. Get the children of the current node
  2. Create the correct NodeView for every node
  3. Invoke such NodeView, get the content and add it to the DOM I am building for the parent

This isn’t currently possible — a node view allows you to specify a container DOM node that its children should be put in. It can’t manually place individual children.

But the documentation for NodeView.contentDOM seems to state otherwise:

The DOM node that should hold the node’s content. Only meaningful if the node view also defines a dom property and if its node type is not a leaf node type. When this is present, ProseMirror will take care of rendering the node’s children into it. When it is not present, the node view itself is responsible for rendering (or deciding not to render) its child nodes.

in particular the last sentence the node view itself is responsible for rendering (or deciding not to render) its child nodes.

Is the documentation wrong? If not, how is it possible to fulfill the responsibility of rendering the child nodes?

I am experimenting with:

drawChildren(node) {
    let i;
    for (i = 0; i < node.childCount; i++) {
        let child = node.child(i);
        if (child.type.name == 'activityName') {
            let childView = window.nodeViews[child.type.name](child);
            console.log("draw child activityName");
        if (child.type.name == 'step') {
            let childView = window.nodeViews[child.type.name](child);
            console.log("draw child step");

Ah, no, the docs are not wrong, it’s just that if you don’t provide a contentDOM property, ProseMirror will leave the drawing, management, and editing of the node’s children completely to the node view. So either they’d have to be uneditable (possibly providing some other interface to manipulate them), or the node view has to manage their editable behavior entirely.