[Neos] Neos JavaScript Refactoring Work RFC

[Dominique Feyer]

HI, just my two cents on conflict and merging during the publishing process.

We use Prismic IO for different projects where we need a Content Repository as a Service (yes I promise that when TYPO3CR have a proper rest api to come back home).

Prismic IO has really nice editor interface, with history, rollback,  team workspace (they call it content release), … But when you publish … you trash everything, not merging, no warning, no conflict management. So having that in Neos can be awesome, But this is a hugely complex task I think. First having a proper CQRS based versioning, undoing, ... and in a second step working on some merging or more advanced tools for helping the editor case.

Based on our current projects, except the stability, one feature that we need is shared workspace. Many client can work on their personal workspace, but many time they need a peer review before publishing. So publishing directly to Live is not an option. They need a « Boss/Reviewer Worspace » to push to at let the boss validated the content. That’s nasty because writing content in neos is so cool, but team review is so … impossible before pushing to live. So people are back to Word for writing and validating content. 

++

Dominique Feyer

Le 16 août 2014 à 11:37:00, Aske Ertmann (aske at moc.net) a écrit:

Technically I’d like to see it implemented by getting rid of proxy nodes and only having nodes being snapshots of the events in the node database. All events are of course stored in a table with different kind of events. These events would match actual node migrations, e.g. MoveEvent/MoveMigration or PropertyChangeEvent/PropertyChangeEvent. This would make it possible to have a solid API for working with nodes. For workspaces the snapshot node is used as the base and then the additional events are applied runtime, but the output is cached in the content cache. This does have one major drawback that I know of, which is if the live snapshot is updated by someone else there can be conflicts. Currently we just overwrite those conflicts and ignore them completely, but having to actually have the editor decide on the conflict makes sense. In the case that the editor wants the original content he started editing, taking the snapshot and reversing the events could work or otherwise create a custom snapshot from the beginning. Then the difference between the two can be made into a merge event so that can be applied when publishing again.