[annotator-dev] Struggling to integrate plugin with v1.2.10
greg.pendlebury at gmail.com
Thu Mar 26 21:34:07 UTC 2015
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.
On 27 March 2015 at 08:19, Randall Leeds <tilgovi at hypothes.is> 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:
> 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 <
> greg.pendlebury at gmail.com> wrote:
>> 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.
>> annotator-dev mailing list
>> annotator-dev at lists.okfn.org
>> Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the annotator-dev