We have moved to GitHub Issues
Created by Jacob Midtgaard-Olesen 05 Feb 2018, 10:34:10 Updated by Sebastiaan Janssen 13 Feb 2018, 08:41:52
Subtask of: U4-10747
I have made a proof of concept of how I think the infinite editing workflow could be solved. The main thought behind the change is when infinite editing is fully implemented “everything will be an editor”. All pickers (content picker, media picker etc) and editors (content, media, doc types, templates etc) will be built with the same concepts in mind (layout, components, etc).
The proof of concept shows how a media picker will work with infinite editing (see attached video). To add a media item you click the “add”-icon to open up the media picker. Inside the picker, all media items have been added the option to edit the media item (design is WIP). When clicking the edit button we open up the media editor where you can easily update the media item.
Branch: I have made a separate branch for infinite editing so it is easier to see the changes. Sorry for the many file changes. I went down the route of renaming a CSS class which was used a lot □□ https://github.com/umbraco/Umbraco-CMS/compare/temp-v8-UI...temp-v8-UI-infinite-editing
Today all editors are made with routes as the way to get ids and other states from params (“create”, “subviews" etc). All of this will still be the same and navigating the back office from the tree will work exactly the same as today.
On top of this, we will add a layer which is close to how the overlays component/dialogService works today. We will have a global "editor service" which will provide helpers to easily open and close new editors/pickers in “infinite mode”. The service will also be responsible for keeping track of all open editors/pickers. The service should include helpers to open all supported editors easily and the most common pickers (content picker, media picker etc.) The service will communicate with events to a global “umb-editor” component added to the dom root.
For this to be able to work we will have to make sure all supported editors have an “infinite mode”. When in “infinite mode” the editors need to get their data from the component instead of the route params. They will also need a “close”-button and to extend the save/submit/done with an easy way to “save and close”. We will also need to make sure these editors open new editors in “infinite mode” or disable “broken” functionality (links etc. which changes the route).
Currently all “regular editors" are made with the correct editor components so they will look the “right way” but all pickers/dialogs need to get an update to the markup/logic to use the same components as the “regular editors”.
What we need to figure out is: Is this the right approach to solving infinite editing?
Known challenges which aren’t solved in this proof of concept:
I'm moving this to fixed as investigation is done and we can build on that later. Objective of the spike reached I'd say.
Backwards Compatible: True
Due in version:
Sprint: Sprint 78
Story Points: 5