Thanks Randall, Good to know it was an accident. I've got a working implementation now by subscribing to the 'annotationEditorSubmit' event instead and then firing my own 'annotationCreated' event from there. It works, but I think the core really should fire that event.
It occurred to me last night that perhaps the answer is to move the the 'save'/'cancel'/'cleanup' functions and the event bindings (lines 644-663) into showEditor(). That way there would be no way to have a 'shown' editor with non-functional buttons. Having said all that, we don't use ranges, so I can't test whether my proposal screws with whatever prompted this change. Ta, Greg On 27 March 2015 at 08:19, Randall Leeds <[email protected]> wrote: > The effect this change has had on your code was unintentional. > > Thanks for getting onto the list to bring it up, that's the only way we > can know about needs like this. > > The original motivation for the change is here: > https://github.com/openannotation/annotator/commit/f4e0b5d4 > > The problem at the time was that the presence or absence of a `ranges` > property was used to determine whether the annotation was new or updated. > That caused problems when ranges failed to anchor, IIRC. > > If you need to upgrade you can either use onAdderClick, which should be > safe, or we can add the onEditorSubmit callback again for you. > > > On Wed, Mar 25, 2015 at 8:45 PM, Greg Pendlebury < > [email protected]> wrote: > >> Heyo, >> >> I'm struggling to upgrade our plugins to work against v1.2.10 and I think >> that I've tracked the problem back to the changes made to how >> 'annotationCreated' events are generated. >> >> Using v1.2.6 we called showEditor() to give users a form to provide us >> content. All of the downstream events just worked, including integration >> with the 'Store' plugin. The 'annotationCreated' event, which the 'Store' >> plugin is waiting to hear, is thrown by the core library from within the >> onEditorSubmit() handler... fairly simple and straight forward. >> >> Under v1.2.10 the user clicks 'Save' and the form just hides with no >> action taken at all. I can see that the 'annotationEditorSubmit' event does >> indeed fire, but the core annotator code doesn't seem to action anything in >> that case. >> >> It looks like the changes center on the functionality of onAdderClick() >> which is now expected to be the only way to throw an 'annotationCreated' >> event from he core (it has been removed from onEditorSubmit()). >> >> onAdderClick() is throwing the the event from inside a closed over 'save' >> function (ie. I can't 'reach' it as an API) that that is not even bound >> unless the stock adder is clicked. We don't even use the stock adder so it >> seems like a strange way to plumb things up. >> >> showEditor() allows us to inject our base annotation (with extra metadata >> fields) but onAdderClick() does not, so this seems like a backwards step >> and a fairly non-intuitive way of expecting plugins to integrate. >> >> My workaround for now seems to be capturing the 'annotationEditorSubmit' >> event and then immediately firing off my own 'annotationCreated' event to >> tell the 'Store' plugin what has happened, but I feel like that is a fairly >> fragile way to integrate if later versions of the core are going to go back >> to firing their own 'annotationCreated' event. >> >> Any thoughts on whether this was an intentional change? Or just and >> oversight? I don't follow the core development very much so I apologise if >> I missed some discussion on this change. >> >> Ta, >> Greg >> >> _______________________________________________ >> annotator-dev mailing list >> [email protected] >> https://lists.okfn.org/mailman/listinfo/annotator-dev >> Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev >> >> >
_______________________________________________ annotator-dev mailing list [email protected] https://lists.okfn.org/mailman/listinfo/annotator-dev Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
