Implicit drafting support

Working on Mosaic made me to take another look into Martin's forgotten drafting framework Think it as a lightweight working copy support. The framework itself seems ready and still working, but it was missing usable Dexterity integration (and I haven't tested its Archetypes integration), which I managed to worked on for a little.

Use case:

  1. start add or editing a content
  2. distraction
  3. accidentally close the tab (or browser crashes)
  4. just repen the add or edit form to continue

Mosaic will probably need drafting to allow creation of so called persistent tiles (uploading attachment and images) on add and edit views, so that they are only finally persisted (or discarded) during save or cancel. Also building layouts with Mosaic Editor may take some time and there's danger of losing a lot of work.

Does this sound interesting? Anyone interest in joining to polish it? I'm working at

Currently drafting is tied to a browser cookie, so that whenever a browser with a correct drafting cookie returns to the form, the form will show the draft instead of the live content. Drafts are saved centrally within a new portal tool called "portal_drafts" with UI for deleting abandoned drafts. Drafts saved per user, which should reduce change for conflict errors when multiple users are drafting simultenously.

Server side drafting may sound outdated (when compared to modern frontend localstorage based solutions), but finishing feels like a low hanging fruit compared to alternatives.

1 Like

Maybe it'd be better or more simple to just provide a field that handles the potential orphaning? Data stored on the object but cleaned up in certain cases.

I was already sort of planning something like this with the file/image input widget I want to get around to doing...

How would that work on add forms? isn't that complex. As long as server side drafting is ok, would be already here.

FYI: 1.0b1 released with Plone Mosaic includes generic drafting support for Dexterity types via "Drafting support" behavior. When behavior is enabled, inline validation calls on add and edit form are used to update draft, which again is used to populate the from if the user returns to the same form without saving or canceling the add or edit (e.g. if browser has been accidentally closed). The logic is quite well explained in p.a.drafts README (DX logic is simlilar to old Archetypes integration, which is now disabled).

Not sure, though, how useful this is outside Mosaic.

Also, outside Mosaic, there's an issue with the inline validation pattern not sending the current value of TinyMCE 4 rich text fields.