[annotator-dev] colored notes

[Randall Leeds]

Thanks.

I'm leaning toward extracting a base API for viewer and editor that
annotator calls.

Eventually the existing viewer/editor bundle might be a separate package.
Those who want a form-builder like API could help maintain this, or expand
its API.

In my own development, I've found it easier to replace the viewer and
editor wholesale, so I want to make that an easy option, too.

Really appreciate the detail. Thanks, Steph.
On Jan 14, 2014 6:25 AM, "Steph Skardal" <steph at endpoint.com> wrote:

>  Hi,
>
> For my project, I heavily modified the viewer and editor and the addField
> API did not have enough capabilities. I was able to completely override the
> viewer addField method (
> https://github.com/berkmancenter/h2o/blob/annotator/public/javascripts/h2o-annotator.js#L23-32)
> in my plugin to control the order of annotator fields, but I didn't want to
> override the editor addField because it's a lot more code that I would be
> copying over and having to maintain, so I edited the core there. My core
> edits there were to allow for special DOM elements that do special things
> (e.g. a button to add a new "colored" layer, a div to that displays data
> from the database for which the user can select a result to tie the
> annotation to). The code that handles the onclick event for the special
> button lives in my plugin.
>
> Attached are a few screenshots of the UI.
>
> Personally, I don't think more direct presentation management is needed
> but the option would be nice. I like the idea of continuing to use an API,
> I just think that it needs to be built out a bit to allow for more advanced
> DOM elements and events tied to them, as well as to allow more control over
> the order of the fields. I accomplished the reordering by directly
> manipulating annotator.editor.fields in my plugin. I see a need for
> breaking down the editor addField method into smaller components so that it
> is more easily overridden. For example, instead of using a switch / case
> block in the editor addField method, would it be more advantageous to
> "register" field types and then have methods that correspond to each field
> type (or simply have an object with the various methods per field type)?
>
> With any open source project, I think it's just a matter of seeing how a
> tool is used and overridden to understand what methods might be valuable in
> the core. In summary, my shortlist of API needs for the viewer & editor
> addField methods:
> - ability to control order of fields when adding or when adding a new field
> - ability to remove fields
> - ability to add more advanced DOM elements / divs with multiple elements
> in addition to those already included
>
> Steph
>
>
>
> On 01/07/2014 04:10 AM, Randall Leeds wrote:
>
> I am curious whether the viewer and editor, with its .addField API, is
> serving needs or if people would rather manage presentation more directly
> and work more with the raw annotation data.
> On Jan 7, 2014 12:39 AM, "Riccardo Tasso" <riccardo.tasso at gmail.com>
> wrote:
>
>> To be quick I had to use one of the solutions provided in this thread,
>> but it seems to me that each one provides a slightly modified version of
>> the core. Maybe Ewald', Albert', Georgios' and Steph' work could be merged
>> to a new version of Annotator which supports multi-colored highlights with
>> or without a plugin?
>>
>>  This would be great,
>>    Riccardo
>>
>>
>> 2014/1/6 Randall Leeds <tilgovi at hypothes.is>
>>
>>>   On Thu, Dec 5, 2013 at 1:29 PM, Riccardo Tasso <
>>> riccardo.tasso at gmail.com> wrote:
>>>
>>>> It seems there is no way to accomplish this task without touching the
>>>> core!
>>>>
>>>>
>>>  Please elaborate on deficiencies and let's fix them!
>>>
>>
>>
>
> _______________________________________________
> 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/20140114/245eaef7/attachment-0004.html>