phiggins42
commented
8 years ago my implementation isn't really standalone, and [sadly] is too tightly coupled with other behaviors and extensions that it isn't really presentable to "break out" into a purely standalone extension base. it also is part of "proprietary work stuff" that I'd have to get explicit permission to copypasta out into something usable.
there aren't any specific mediumeditor hooks outside of of the overridden paste handler (which could be fixed with a post-paste hook or such to allow an external extension to have a say in the paste processing), and we use a custom serialize function because we only really use the one element/instance of the editor.
it is two (or more) extensions really. One is called "ActionBar", which is a flyout menu allowing you to inject these raw "blocks" by type from a + icon next to an empty paragraph. the actionbar also has key handling code which detects manual entry of the block type names. eg, typing:
<p>$image cows</p>and pressing enter will trigger the $image extension with a seed word of cows (which in turn runs a getty search etc, and then when given an image url is calls the $image extension render factory). the other is a "base block" defining the api, and providing an .extend function like stock Extensions do. The base block is actually a Button extension, so these extensions could be toolbar buttons (but we don't do that, preferring the "actionbar" method of creation over having to select some text and click a toolbar button) ...
also my implementation uses some jquery for easyish dom traversal, and does some insanity with whitespace because we also used actionbar's keyhandling code paths for markdown detection, so even decoupling those two would be some effort.
there also is no hook in mediumeditor to do the initial instantiation from raw html. we do that manually by searching for the block identifier and redrawing right after we instantiate the editor, and then use custom event (pubsub actually) to trigger a shim around editor to do the actual block management. it was all very pragmatic, and never intended to be released really, but I'm happy to work with you do isolate the parts you'd need to get something similar going ...
Followup of https://github.com/yabwe/medium-editor/pull/1108#issuecomment-223032317
A new extensibility layer is needed for component extensions for the Medium-Editor that require specific locked area display during editing, but a different content when saved.
Some use cases:
static image placeholder A component inserts a jquery based gallery. The gallery is rendered as static image in the editing content. When clicked on it a special toolbar appears that allows you to edit the gallery. When done there is still static image as preview but on the final save the full html gallery code is generated.
When the area is again in editing mode - the gallery code translates back to the images placeholder preview.
richer component placeholder For example an spreadsheet alike grid - that has full editing capabilities and display.
mixed locked with editable preview For example a slider with images and text as title. During the editing the user clicks on it and can replace the image and directly edit the text.
So basically we need to have "design-time" html view just for the preview and activation within the editor - and "run-time" html that will be the final html that is saved in the content.
This will allow "run-time" html to get "translated" to "design-time" for display in editor and back on save
More description is available at: https://github.com/yabwe/medium-editor/pull/1108#issuecomment-223032317
@phiggins42 - would you care to provide a sample of your system implementation? Is it a stand alone version or needs deeper integration in Medium-Editor? Sounds exactly what we need.