[annotator-dev] Annotator and Meteor

• Previous message: [annotator-dev] Annotator and Meteor
• Next message: [annotator-dev] Annotator and Meteor
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi!

One thing I noticed some project have is a GitHub hook which
automatically compiles master branch into dist branch where you can
then make a submodule and have files. I thing this would be very
useful to have. Example:

https://github.com/guardian/scribe/tree/dist

And Annotator could also use Browserify, but not require it, wrapping
the result in something like:

 // AMD / RequireJS
    if (typeof define !== 'undefined' && define.amd) {
        define([], function () {
            return Annotator;
        });
    }
    // Node.js
    else if (typeof module !== 'undefined' && module.exports) {
        module.exports = Annotator;
    }
    // included directly via <script> tag
    else {
        root.Annotator = Annotator;
    }


Mitar

On Wed, Sep 10, 2014 at 11:34 AM, Randall Leeds <tilgovi at hypothes.is> wrote:
> 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
>>>>>
>>>
>>
>
> _______________________________________________
> 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
>



-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

• Previous message: [annotator-dev] Annotator and Meteor
• Next message: [annotator-dev] Annotator and Meteor
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]