Structured Editing within CKE5


(Dmitri Pisarev) #1

While preparing for their talk, Piotrek Koszuliński and @sebastian have created a mind-blowing prototype that shows how to edit structured data within CKE5: https://github.com/Reinmar/ckeditor5-structured-editing

I must say I’m completely stunned by what Piotrek managed to do for us in such short amount of time (thank you!!!) and I’m super excited about our collaboration!
I can’t wait to start integrating this prototype into Neos, but for that I need some brainpower.

What we want to achieve: edit whole content collections within CKE5, and not just individual nodes. It would solve our long-standing UX issues like the pain of inserting images in between existing text etc. See the talk for more details: https://youtu.be/HtZcqtTFXRg?t=3667
Prior context: Structured editing and tighter integration with CKE5

Now let’s go through the integration challenges:

  1. to co-exist with traditional content collections, we can have some helper Fusion object that would initialize an editable content collection, similar to the way we init editables now. Everything inside it would be rendered inside one CKE5 instance.
  2. to get data into CKE now we need structured data instead of pre-rendered editables like before. That information is already available in our redux store, as it’s loaded from inline script tags when the page loads. So far so good.
  3. CKE5 has to know how to render nodes from their properties. I think there should be two modes for rendering:
    a) synchronous, where we define a JS function that takes node’s properties and returns a DOM node. Or maybe even a string with placeholders that could be statically generated from Fusion on the server-side. Dunno. The obvious limitation for such client-side rendered nodes, is that they should not have some kind of server-side processing, so it would be possible to create them optimistically. Probably we should also disallow childNodes for them.
    Also we’d generate uuid’s client side, and it should be possible to persist the nodes under these pre-generated identifiers. Is it already possible with our current API?
    b) async, by making an ajax request to our out-of-band rendering endpoint. That’s needed for nodetypes that require some server-side processing (e.g. images). Piotrek, do you think it would be hard to add this possibility to your prototype? I guess we can just make a generic API for the render function to always return a promise, but for synchronous content it would resolve right away.
  4. I have no idea if it’s possible to implement nested ContentCollections with this approach (Piotrek, any ideas?). We can start without them. But it would actually be cool to support things like grids.
  5. To get data out of CKE5, we have a number of events (update, remove, create, select) that map to our API pretty well. The only thing is that we need to convert them from being index-based to being identifier-based. (Piotrek, is it possible to adjust your prototype to use identifiers and fire multiple remove events instead of one event with a range?)

Ideas? Feedback? Anyone wants to join the efforts?


Structured editing and tighter integration with CKE5
(Viktor Isaak) #2

I like the “ideal world” thought of @christianm
The result will eventually be visual and tangible.

I propose: let’s do a couple of use cases or visual examples of structured content and layouts, so we get and idea of what we’re dealing with, what the solution should enable an editor or designer to do, the ramifications and which approach would satisfy the requirements for that in terms of
a) strategy / user experience
b) implementation in code.


(Viktor Isaak) #3

First ideas