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

[Randall Leeds]

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/20150326/88987fcc/attachment-0004.html>