Nested nodes, Headings hierarchy

Hi, I’m trying to design a nested node schema that can have a hierarchy based on headings like this:

<div class="heading wrapper">
  <h1>Heading 1</h1>
  <p>Line 1: Contents for Heading 1</p>
  <div class="heading wrapper">
    <h2>Heading 2</h2>
    <p>Line 1: Contents for Heading 2</p>
    <div class="heading wrapper">
      <h3>Heading 3</h3>
      <p>Line 1: Contents for Heading 3</p>
    </div>
  </div>
  <div class="heading wrapper">
    <h2>Heading 2</h2>
    <p>Line 1: Contents for Heading 2</p>
  </div>
</div>

<div class="heading wrapper">
  <h3>Heading 3</h3>
  <p>Line 1: Contents for Heading 3</p>
  <div class="heading wrapper">
    <h4>Heading 4</h4>
    <p>Line 1: Contents for Heading 4</p>
    <ol>
      <li>1</li>
      <li>2</li>
      <li>3</li>
    </ol>
  </div>
</div>

How does it work? When a new Heading creates, all contents that will create next must be inside a wrapper, including and underneath that heading.

The heading number determines where the next nested section should be located.

If the heading level is less than the parent heading, the new heading and its wrapper will attach to the current heading section; otherwise, if the heading level is greater than the parent heading, the new heading will be created outside the existing wrapper.

Questions:

1/ How can I create a new Shchma with proper “Content Expressions” that cover the heading hierarchy (nested)?

2/ I think the schema doesn’t do all the hard work. I must listen to an incoming Heading Node and decide where to put the new content. How can I do this correctly?

Alternative Way:

Most common schemas create nodes in flat mode, meaning that nodes are not nested and are all independent of each other.

So, in order to have nested nodes, I append to all nodes’ a unique id and the parent id based on the heading level number. In this solution, when a new heading is going to append to the document, the function should rerender all nodes based on the new heading level(update the parent id). This solution has an expensive process cost for the client, mostly when gets long and more extended.

Modeling your schema like this is possible (the content expressions for the nodes are straightforward), but not recommended, since you’ll need a lot of custom user controls to make this kind of rigid editing halfway workable, and even then, the user will often need to think about intermediate states they have to go through to get to the document shape they want, when reorganizing things. People have built editors like this in the past, but moved to a flat schema (possibly with linting warning about odd structure) later.

I appreciate for quick answer. You are right about the flat and nested ones.

But this is the feature that the employer wants from me, and then we want to have each heading section as a toggle(the easy part).

Would you give me an example (plugin) with a similar schema for reviewing the code and functionality?

No, that’s not something I happen to have lying around. What I remember from a client that was doing this is that they had a bunch of specialized commands for lifting and splitting sections, but you’re going to have to do the implementation work on this yourself.

I see, thank you. When I reach a clean solution, I’ll share my work with you and the community.