No worries. I've added that issue here: https://github.com/openannotation/annotator/issues/499
On 27 March 2015 at 08:42, Randall Leeds <[email protected]> wrote: > I was trying not to assume the presence of an editor in the sense that > Annotator was originally design with. > > Similar to how you've made your own adder, someone might wish to not be > bound by the assumptions of the built-in editor and the flows it > participates in. > > Putting these in showEditor assumes that the editor is shown and hidden > exactly once with a complete annotation cycle. That's still sort of the > case now, but only if you are using onAdderClick. > > It's tough to know exactly what to do here. This is why the master branch > has removed a lot of this in order to allow anyone to wire up the > components and events as needed for their use case. > > Could you open an issue on the openannotation/annotator github project and > just summarize and link to this thread: > http://permalink.gmane.org/gmane.comp.web.annotator/1379 > > Thanks! We'll come up with something. If you have more suggestions, spew > them here. > > On Thu, Mar 26, 2015 at 2:34 PM, Greg Pendlebury < > [email protected]> wrote: > >> 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
