[annotator-dev] Annotator and Meteor

Wed Sep 10 18:34:42 UTC 2014

You could grab the all the highlights and sort them using
document.compareDocumentPosition.

Annotator stores the annotations using jQuery.fn.data on the highlight
nodes. If you need help with that let me know.
On Sep 9, 2014 11:24 AM, "Ari Entlich" <atrigent at gmail.com> wrote:

> Actually, I just had another idea. The actual reason we want access to
> xpath-range is so that we can consume the ranges that are stored in
> annotation objects (SerializedRanges, if I understand correctly) and
> compare two of them to determine their relative position in the annotated
> document. We would like to display a list of annotations in the order that
> they appear in the document. Perhaps it would make sense to simply add such
> a comparison function to annotator? Or maybe there's a better way of
> accomplishing the desired sorting that I'm unaware of?
>
> Thanks.
>
> Ari
>
> On Tue, Sep 9, 2014 at 1:24 PM, Ari Entlich <atrigent at gmail.com> wrote:
>
>> On Sat, Sep 6, 2014 at 9:58 PM, Randall Leeds <tilgovi at hypothes.is>
>> wrote:
>>
>>> I think whatever you do is a stopgap for now.
>>>
>>> If it helps we can push (I think we already have?) a dev tag to npm.
>>>
>>> Build a separate repo for the meteor package that depends on annotator
>>> and you should hopefully get the built files if we're doing our part to
>>> upload the build.
>>>
>> On Sun, Sep 7, 2014 at 12:34 AM, Randall Leeds <tilgovi at hypothes.is>
>> wrote:
>>
>>> npm dependency for the meteor build. Then npm has the built sources.
>>> Meteor package doesn't know or care about browserify.
>>>
>>> If any downstream consumer has to care that we use browserify we're
>>> doing it wrong.
>>>
>>> The output is JavaScript.
>>>
>> Ah ok, I do see that the annotator stuff uploaded to npm is just the
>> generated js files. That's probably good enough for most use cases, but
>> we've been thinking of customizing the browserify build to give us access
>> to the bundle's internal copy of xpath-range. To do this, I believe we
>> would need to care about the use of browserify. We could potentially create
>> meteor packages for both annotator and xpath-range and use both of them,
>> but it looks to me like the xpath-range in npm is NOT fully preprocessed -
>> the coffeescript step has been run, but the browserify step has not. In
>> general though, I do think it makes sense for us to just use the copy
>> inside the annotator bundle, since it's already there.
>>
>> Ari
>>
>>
>>> On Sep 6, 2014 11:47 AM, "Ari Entlich" <atrigent at gmail.com> wrote:
>>>
>>>> Hey all. Sorry for not jumping in sooner.
>>>>
>>>> Mitar, I did discover your annotator package in peerlibrary while
>>>> looking through your work. However, Andrew and Bryan are correct that
>>>> you're using an older version than we are and that your approach
>>>> unfortunately will not work for us. I don't believe it is possible to just
>>>> "ignore browserify", because the most recent annotator code is making
>>>> extensive use of the CommonJS-like module system that browserify provides.
>>>> As far as I know, meteor would not serve as an adequate replacement for
>>>> browserify in this respect.
>>>>
>>>> Essentially what needs to happen is that we need to have meteor call
>>>> browserify during its build process. I've found
>>>> Plugin.registerSourceHandler, which allows you to make build plugins that
>>>> say "I can handle files with filenames matching some pattern". However,
>>>> this seems to be aimed primarily at registering generic handlers for file
>>>> types - coffescript, less, sass, etc files. What we need is a way to
>>>> specify how to build a specific package and to add the build artifacts from
>>>> that build process to the meteor app. I'm currently investigating whether
>>>> it would be possible to do it in the package definition section of the
>>>> package.js file (http://docs.meteor.com/#pack_onUse).
>>>>
>>>> If the above winds up working, we can easily tell browserify to expose
>>>> the annotator bundle's copy of xpath-range. I'd rather not make changes to
>>>> annotator itself in order to get this working.
>>>>
>>>> A possible alternative to using git submodules is to simply declare
>>>> annotator as an npm dependency of the meteor package. If that winds up
>>>> working, I think it would be the preferable approach.
>>>>
>>>> Ari
>>>>
>>>>
>>>> On Fri, Sep 5, 2014 at 9:13 PM, Mitar <mmitar at gmail.com> wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> You can package xpath-range as additional package as well, if you want.
>>>>>
>>>>> If you want to add xpath-range, you can always just add it inside the
>>>>> Meteor package for Annotator as a field of top-level object. So you
>>>>> create one more file which you add at the end of all files from
>>>>> Annotator and do something like:
>>>>>
>>>>> Annotator['xpath-range'] = xpath-range;
>>>>>
>>>>> Please start a repository and then we can look into the real code you
>>>>> have. Now it is a bit too abstract which issues you and how to advise
>>>>> you.
>>>>>
>>>>>
>>>>> Mitar
>>>>>
>>>>> On Fri, Sep 5, 2014 at 12:24 PM, Bryan <btbonval at gmail.com> wrote:
>>>>> > Thanks Mitar, a git submodule might be a good approach for us.
>>>>> >
>>>>> > One of our issues is with respect to the encoding of Annotator xpath
>>>>> > offsets. We would rather not duplicate this code, but we do need
>>>>> access to
>>>>> > xpath-range. As Annotator works now, it appears to include
>>>>> xpath-range via
>>>>> > browserify, but browserify does not expose xpath-range to the
>>>>> greater Meteor
>>>>> > application.
>>>>> > -Bryan
>>>>> >
>>>>> >
>>>>> > On Fri, Sep 5, 2014 at 3:13 PM, Mitar <mmitar at gmail.com> wrote:
>>>>> >>
>>>>> >> Hi!
>>>>> >>
>>>>> >> Yes, we are still using the old version, but I am not sure it
>>>>> matters.
>>>>> >> You can package it in the same way, I believe. So you add Annotator
>>>>> as
>>>>> >> a git submodule, you ignore browserify, and just add all
>>>>> CoffeeScript
>>>>> >> files to the package. Meteor will then convert them into JavaScript
>>>>> >> files and package them into one namespace automatically. Sometimes
>>>>> you
>>>>> >> have just to add one more file which exposes globally the symbols
>>>>> you
>>>>> >> want to have globally.
>>>>> >>
>>>>> >> I don't have time to do it myself now, but you can start with a
>>>>> GitHub
>>>>> >> repository for it now and let's see where you get stuck.
>>>>> >>
>>>>> >>
>>>>> >> Mitar
>>>>> >>
>>>>> >> On Fri, Sep 5, 2014 at 5:16 AM, Andrew - FinalsClub
>>>>> >> <andrew at finalsclub.org> wrote:
>>>>> >> > Thanks Mitar,
>>>>> >> >
>>>>> >> > I notice you are using an older version of Annotator (before
>>>>> browserify
>>>>> >> > was added). Would the same thing be possible with Annotator 2.0?
>>>>> We are
>>>>> >> > currently a bit stumped. Ari can share more details on our
>>>>> efforts if you're
>>>>> >> > curious.
>>>>> >> >
>>>>> >> > Eventually, it would be useful to make a Meteor package so others
>>>>> can
>>>>> >> > easily use Annotator in their meteor projects. If you have any
>>>>> suggestions,
>>>>> >> > we would love guidance / help.
>>>>> >> >
>>>>> >> > Warmly,
>>>>> >> > Andrew
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >> On Sep 5, 2014, at 3:39 AM, Mitar <mmitar at gmail.com> wrote:
>>>>> >> >>
>>>>> >> >> Hi!
>>>>> >> >>
>>>>> >> >> You can see here how we are bundling Annotator for Meteor:
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> https://github.com/peerlibrary/peerlibrary/tree/development/packages/annotator
>>>>> >> >>
>>>>> >> >> And here how we are using it:
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> https://github.com/peerlibrary/peerlibrary/tree/development/client/lib/annotator
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> Mitar
>>>>> >> >>
>>>>> >> >> On Wed, Sep 3, 2014 at 7:04 AM, Andrew - FinalsClub
>>>>> >> >> <andrew at finalsclub.org> wrote:
>>>>> >> >>> Hey All,
>>>>> >> >>>
>>>>> >> >>> Especially @Mitar. At FinalsClub, we have been working on a new
>>>>> social
>>>>> >> >>> reading site built using Meteor (a newfangled JavaScript
>>>>> framework). Meteor
>>>>> >> >>> is nice, because it offers isomorphic JavaScript - that is, the
>>>>> same code to
>>>>> >> >>> run on the client and server. It also provides the magic of
>>>>> reactive data
>>>>> >> >>> binding between clients and server.
>>>>> >> >>>
>>>>> >> >>> We have gotten a basic working version of Annotator with a
>>>>> >> >>> meteor-specific store plugin. (I can share the code if anyone
>>>>> is curious.).
>>>>> >> >>> However, there are some aspects of Annotator that we are
>>>>> grappling with.
>>>>> >> >>>
>>>>> >> >>> For instance, we were wondering how the XPath-Range plugin is
>>>>> >> >>> currently being used. Also, we want to include the coffeescript
>>>>> (not
>>>>> >> >>> compiled JS) of Annotator in our project, but aren't sure how
>>>>> to accomplish
>>>>> >> >>> that using Meteor's custom package system.
>>>>> >> >>>
>>>>> >> >>> @Mitar, I've seen your handle on a few meteor github issues and
>>>>> wonder
>>>>> >> >>> if could help us. I've cc'd Bryan and Ari from our team if they
>>>>> have
>>>>> >> >>> anything to add.
>>>>> >> >>>
>>>>> >> >>> Also, if anyone else is interested in helping, just say so.
>>>>> We'd be
>>>>> >> >>> glad to put our work on the OpenAnnotation organization if
>>>>> you'd like as
>>>>> >> >>> well.
>>>>> >> >>>
>>>>> >> >>> Best,
>>>>> >> >>> Andrew
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> --
>>>>> >> >> http://mitar.tnode.com/
>>>>> >> >> https://twitter.com/mitar_m
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> http://mitar.tnode.com/
>>>>> >> https://twitter.com/mitar_m
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://mitar.tnode.com/
>>>>> https://twitter.com/mitar_m
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20140910/adb3cb3a/attachment-0004.html>