[annotator-dev] Struggling to integrate plugin with v1.2.10

Thu Mar 26 22:33:43 UTC 2015

No worries. I've added that issue here:
https://github.com/openannotation/annotator/issues/499

On 27 March 2015 at 08:42, Randall Leeds <tilgovi at hypothes.is> 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 <
> greg.pendlebury at gmail.com> 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 <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:
>>> 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 <
>>> greg.pendlebury at gmail.com> 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
>>>> annotator-dev at lists.okfn.org
>>>> https://lists.okfn.org/mailman/listinfo/annotator-dev
>>>> Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20150327/60b698f4/attachment-0004.html>