[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 ]

We already build as a UMD in the output. One step ahead of you all :-D.

I'm not sure what the problem is in this thread anymore.

Is it that xpath-range isn't exported? We used to have Annotator.Range I
think, before we split it out into a separate package. We can definitely
assign it as a property of the Annotator global.
On Sep 11, 2014 6:05 AM, "Benjamin Young" <bigbluehat at hypothes.is> wrote:

> Looks a lot like UMD. :)
>
> Maybe give this post a look:
>
> http://dontkry.com/posts/code/browserify-and-the-universal-module-definition.html
>
> Apparently there are a good number of tools for browserify that can work
> with other module types.
>
> This may just serve as surrounding educational material and not the
> solution, but it looks promising all the same. :)
> On Sep 11, 2014 4:34 AM, "Mitar" <mmitar at gmail.com> wrote:
>
>> 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
>> _______________________________________________
>> 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/20140911/d16dcf57/attachment-0004.html>

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