[annotator-dev] Refining sub-component flexibility

[Aron Carroll]

On 14 Oct 2014, at 09:01, Randall Leeds <tilgovi at hypothes.is> wrote:

> In reviewing the current master branch today I came upon two simple refinements I will try to make this week, but feel free to jump in and do so yourselves. I hope by laying out the motivation and the philosophy here it helps us see more places for improvement.
> 
> I hacked up an open annotation storage adapter today. It wraps any other storage implementation to translate annotations to JSON that maps to open annotation through a JSON LD context.

Awesome.

> However, it became clear that there's very little need for such an adapter if an annotator instance itself can work with the right "shape" directly (targets, selectors and bodies as resources). With that scenario, all that's needed is a context and no further transformations are necessary.

+1

> An example is the text highlighter. Can we, instead of passing it annotations to its API, pass ranges?

I don’t see why not. Ideally we should only be passing only what’s is necessary for the component to function. In this case it looks like we could move the jQuery.data() part out into the Default.UI or a separate cache/lookup component.

> I did also notice that the adder needlessly deals with the annotation directly, when it has no real business knowing the purpose it serves in being a button. That could similar be lifted to the application.

Agreed, I think this can be improved by creating a new Adder element inside onSelection[1] each time the method is called, this keeps the annotation within the closure. When deselected, the current adder can just be destroyed. As you say this keeps the adder purely as a button.  

[1]: https://github.com/openannotation/annotator/blob/master/src/plugin/defaultui.js#L208-L214