These are chat archives for daviferreira/medium-editor

16th
Apr 2015
Peter E Higgins
@phiggins42
Apr 16 2015 13:45
moin.
Nate Mielnik
@nmielnik
Apr 16 2015 13:47
good morning
Peter E Higgins
@phiggins42
Apr 16 2015 13:47
neck deep in paste stuff over here, ties right in with wanting to expose as extensions ... but pragmatism says one little feature would be superduper handy, so mentioning here to gauge interest:
/* changed functionality: intercept paste event, defer to extensions should
       one provide a handlePaste */
    if(this.base.commands.some(function(command){
        return command && command.handlePaste && command.handlePaste(event, element);
    })){
        // at least one of the extensions said they want to handle this paste,
        // defer to them
        return;
    }
    /* end addition */
ugh that came out ugly
basically if an extension provides a handlePaste, it is given an opportunity to override the pastehandler behavior
(some of my extensions manage their own dom, and from an extension POV there is no "before paste" event available, only after the default pastehandler does it's thing)
extension.handlePaste can return 'true' to note it wants control, or false/nothing if it just wants to pass through
Peter E Higgins
@phiggins42
Apr 16 2015 13:52
the above is basically a monkeypatch over PasteHandler.prototype.handlePaste ... it runs that first, and then if nothing wants control calls the original Pastehandler.handlePaste
Nate Mielnik
@nmielnik
Apr 16 2015 13:52
I think the model where you override the paste handler would be a better way to handle this
Peter E Higgins
@phiggins42
Apr 16 2015 13:53
yah it could be accomplished that way too, just override the handlePaste and move on, which I could do without monkeypatch if was exposed easily
Nate Mielnik
@nmielnik
Apr 16 2015 13:53
if an extension which handles paste lived in the extensions, you'd have to worry about the order that the paste handlers get called
Peter E Higgins
@phiggins42
Apr 16 2015 13:54
well that's why they have to explicitly state. hmm some context maybe
i have extensions which do rich-dom stuffs
Nate Mielnik
@nmielnik
Apr 16 2015 13:54
it'd be better to just take that out of the equation, override the paste handler, and then the overrider can control exactly when and how it uses the existing pastehandler code
Peter E Higgins
@phiggins42
Apr 16 2015 13:54
html ends up like <div data-extension='foobar'><h3>not editable part</h3><p>can only edit content here</p></div>
the foobar extension has very precise rules about what can be pasted in
so encapsulation, I want the extension itself to do that work
so the extension says "oh i'm parented by a [data-extension='MINE'], I need to take control here"
Nate Mielnik
@nmielnik
Apr 16 2015 13:56
if pastehandler was an extension that lived in the commands array, and your extension also lived in the commands array, the order that their pastehandlers got called would matter
Peter E Higgins
@phiggins42
Apr 16 2015 13:56
sure, new Editor(..., { paste: PasteHandler.extend({ handlePaste: function(e, el){ if(some....){ }else{ PasteHandler.prototype.apply(this, arguments); } }
easy enough
just wondering philosophically if anyone else would be interested in per-extension paste control
Nate Mielnik
@nmielnik
Apr 16 2015 13:58
If in theory you had more than 1 extension that had paste handling code, and you wanted to leverage each of them, you'd definitely want control over the order of those
in which case, you'd probably want to create a single new extension, that handles pasting, and then calls those other extension's paste handlers in a specific way
Peter E Higgins
@phiggins42
Apr 16 2015 13:59
trying to think beyond my own usecase ...
no two extensions can be parented by the same sub-dom
so first-one-wins works in my case
Nate Mielnik
@nmielnik
Apr 16 2015 14:01
yeah, I'm trying to think beyond this use case as well, but I can't imagine a case when just overriding the pastehandler wouldn't just be sufficient, but almost required
Peter E Higgins
@phiggins42
Apr 16 2015 14:01
just doing the core pastehandler override is sufficent for my needs.
Nate Mielnik
@nmielnik
Apr 16 2015 14:01
what I could see is allowing the extensions to have control over the 'insertHTML' command
Peter E Higgins
@phiggins42
Apr 16 2015 14:02
yah i actually do that too already for other reasons
Nate Mielnik
@nmielnik
Apr 16 2015 14:02
so they can make any final changes to any html that's going to be inserted, there would still be order issues there, but then it goes beyond paste handling and event handling
Peter E Higgins
@phiggins42
Apr 16 2015 14:02
basically everything does getSelection() -> find closest "block parent"
to ensure the actions incoming are allowed/etc
also have a handy actionWhitelist / actionBlacklist pattern for dynamic buttons to control toolbar inside of different types of "block parents"
Nate Mielnik
@nmielnik
Apr 16 2015 14:03
are you talking about overriding document.execCommand altogether?
Peter E Higgins
@phiggins42
Apr 16 2015 14:03
no
overriding what is passed to execCommand
rather than do cleanup post-paste/insert
because the cleanup breaks undo
(unwrapping those nasty span[style] tags, etc)
Nate Mielnik
@nmielnik
Apr 16 2015 14:04
ah, so document.execCommand('insertHTML') specifically
Peter E Higgins
@phiggins42
Apr 16 2015 14:04
right
Nate Mielnik
@nmielnik
Apr 16 2015 14:05
yeah, I could see making that something extensions can control
Peter E Higgins
@phiggins42
Apr 16 2015 14:06
so just a smarter pastehandler than can say to the extensions "about to paste [this] into you, you cool with that? no, return me what you are cool with" somehow
Nate Mielnik
@nmielnik
Apr 16 2015 14:09
what I was suggesting was all calls to document.execCommand('insertHTML') get routed through all the extensions first
nothing calls Util.insertHTMLCommand directly, only after the extensions have had a chance to muck with the html would the internal code actually call the command
so it would go beyond even pasting
Peter E Higgins
@phiggins42
Apr 16 2015 14:13
ic