[annotator-dev] H2O Core Modifications on Annotator

Randall Leeds tilgovi at hypothes.is
Fri May 9 18:22:54 UTC 2014

On Fri, May 9, 2014 at 10:41 AM, steph <steph at endpoint.com> wrote:

> Hi,
> I've been working on upgrading from Annotator 1.2 to the 2.0 / master
> branch since the I Annotate Conferece. I was able to pull out many of my
> core hacks previously in place, thanks to getting clarification on
> available events from Randall, but I still needed a handful of core hacks.
> I did the upgrade on an mostly arbitrary master branch as I've been trying
> to keep things up to date, and I realize there's been a bit of movement
> since the various UI components have been broken down. Regardless, here are
> core modifications in place:
> * Appended to the Editor.hide method (https://github.com/
> openannotation/annotator/blob/master/src/plugin/editor.coffee#L131): For
> our use, I needed something custom to be executed when the Editor is
> hidden, both after an annotation is saved and when the cancel button is
> clicked. Perhaps this is one candidate that could be moved to an event, so
> please let me know if I'm missing an event here.

This one is easy. I've actually just been working to reduce some redundancy
around the widgets.
I'll add show/hide events to the base Widget.

> * Add to the Editor.submit method (https://github.com/
> openannotation/annotator/blob/master/src/plugin/editor.coffee#L164): For
> our use, I needed client-side error validation to happen on the content of
> the annotation form before anything else happened. IMO, from my
> understanding of the code, error validation of annotation submissions, both
> client-side and server-side, is not obvious to me.

The Editor has a simple _onFormSubmit callback. Maybe we should just make
it public.

It seems like there's a common pattern in some of the plugins where the
options hash includes callback functions. The Auth plugin's userAuthorize
callback, for instance.

Aron's not a big fan of .extend(), from what I can see, but I think it's
simple. I can see the objection to using it as a way to mix in lots of
different functionality to one object, but rather than an options hash
maybe this would do:

var H20Editor = Annotator.Editor.extend({
  onSubmit: function (event) {

    // do validation

> * Modifying the ignoreSelector behavior in NormalizeRange.serialize (
> https://github.com/openannotation/annotator/blob/
> master/src/range.coffee#L219): I had to make a couple of modifications
> here to ignore additional markup added to the text in the offset
> calculation. In our implementation, we have the ability to hide and show
> non-annotated text. A link with anchor "[...]" is shown in place of hidden
> non-annotated text, and I modified the serialize method to ignore this
> markup in the offset count.
> * Util.getTextNodes mods (https://github.com/
> openannotation/annotator/blob/master/src/util.coffee#L68): In addition to
> ignoring the "[...]" markup, our implementation also shows paragraph
> numbers for all the text, which needs to be ignored in calculating
> annotation Range/offset.

These I know less about.

> In other news, here's a list of all the events we are using in our plugin:
> annotationsLoaded
> annotationEditorSubmit
> beforeAnnotationCreated
> beforeAnnotationUpdated
> annotationCreated
> annotationUpdated
> beforeAnnotationDeleted
> annotationDeleted
> Most of those are all directly related to CRUD actions on a single
> annotation.

Great. I think we'll keep them all around for v2.

> I don't necessarily think the core needs to be modified to accommodate the
> customizations I mentioned, but hopefully this gives a bit of insight as to
> where our limitations are and how we are using Annotator

Very much so. Thanks, Steph!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20140509/d49955d2/attachment-0004.html>

More information about the annotator-dev mailing list