now that the discussion about improved editor UX is gaining momentum, I’d like to draft out an idea of mine on how to deal with content on document nodes.
The reasoning in a nutshell: a single content node on a document does not make sense on its own but only as part of the document and in combination with its siblings.
Inline Nodes
The idea would be to store content not as separate descendant nodes of a document, but basically as a JSON blob in the document. This way it keeps being structured as in the content “nodes” still have node types, hierarchy, properties and even references, the latter albeit indirectly. They just don’t have their own database record anymore. Editing would basically stay the same as before, only the UI endpoints would need to be adjusted.
Restructuring content
The actual reason for this approach - besides potential performance gains due to drastically reducing the amount of nodes - is that restructuring content in the UI could be simplified because it could operate on a JSON structure.
Handling variation
This is a trickier one; Content nodes must keep some kind of identity (they still might need a node aggregate ID) to be varied and so that variants can be grouped to an inline node aggregate. Resolving one of such might impact performance.
Handling references
The content nodes’ references would actually be stored on the document node with the information on the actually referencing content node stored as a property on the reference relation. Thus, references can still be resolved in both directions.
Maybe we could start by improving the value-object/nested-property handling in node properties and allow this to grow over time. In the end this would also lead to content beeing stored as json on document nodes but allow a more gradual implementation.
Downside would be that the handling of variations would not be that sophisticated when all content is a single property. At least at first.
While this may converge over time to your suggestion it could imho be split up into multiple steps more easily.
Hi, good to start the discussion somewhere in text
Im all in for having a concept to allow faster simpler content editing and eventually real prototyping making word or markdown writing obsolete. I wrote down a few thoughts myself and i think down the road my thoughts went more into the direction of this being impossible. Let not get discouraged by that … we’ll find a way right?
Implications on caching and cache-invalidation
While implementing caching for the component engine I noticed how thought out the current structure is after all. Currently the document node has a root cache entry which is flushed if the node or any of its parents change. This covers changes to the title for example. But the content in form of the content nodes is by convention cached via its content collection. Each content collection e.g. “main” is flushed for all descendant node changes. In this regard it’s important that the document has a content collection node where the actual child-nodes live as if they are directly on the document level the cache flushing would not work the way it does.
I assume that content nodes as json blob will directly be cached with the document and thus always invalidated if title changes or content. That is greatly simplified and with less nodes being used we probably wont need fine grained cache handling for content nodes after all?
Working multi dimensional content
Neos offers with Neos 9.0 a well distilled variation concept. Most used are either fallback dimensions or real separated (peer) dimensions.
I believe we still have to solve keeping content in sync for peer dimensions. Because i wouldn’t want to make german a fallback of english, just to have the same content. Instead i would seek to create a page first in any of the peer languages and have it translated to all other parts. Now editing the content in any of the peer variants might lead to the content from going out of sync. To avoid this each new content node would need to be translated as well into the other languages as well as changes to the text. → This is not solved but the ui could provide tooling to translate new content nodes individually and also retranslate them.
The actual problem is when the content differs greatly in structure over the peer document variant. This can have various reasons. And the sole reason is that redactors don’t mind the IDENTITY of a node but only see it for which content it has. So the structure can greatly vary but the actual content might be closely the same. When we think about editing we want to work with nodes on the page as easily as possible.
Editors might copy a node and experiment with the content and properties and later remove the original one. Intentionally or not but this changes identities.
Editors might want to split text nodes to insert a node in between. The structure greatly differs and a new node with new identity was added while the content is roughly the same. Worse deleting the node in the middle will lead to the same content with a different structure / identities.
Editors might need to remove duplicate content after collaboration and merging workspaces, possibly removing a node which exists in another language but not the duplicate that only resides in the one language
These cases are just from the top of my head. And they are a problem today and prevent us from working more loosely with nodes as we do care about the identity after all? Or dont we? As a technical person i can see to edit my own side in a “correct” manner regarding identities of content nodes.
If the json blobs of document content nodes also require an identity i don’t think this improve our situation. Worse without the separate node and identity handling we loose working collaboration:
Reviewing content / Working with multiple workspaces
Storing the content in form of separate nodes allows for publication of individual changes. And a similar well working merge when changes are performed across multiple workspaces on the same page. This is handled by the content repository core and well tested. Even with Neos 9 we only started to make collaboration really work on the same node. Working with nested content (see accordion or columns) under these condition with json blobs will be super complex to solve properly - if not exactly as complex as how the whole content repository is already. Just imagine content deletions in one part where elsewhere new content is just being created inside a content element.
