[annotator-dev] issues working against master
Steph Skardal
steph at endpoint.com
Fri Apr 11 18:29:25 UTC 2014
Hi,
On 04/11/2014 02:15 PM, Randall Leeds wrote:
>
>
> How many representations are needed?
>
> The way you've described it almost sounds like three:
> 1) Stored
> 2) In memory, for annotator
> 3) In memory, for your UI
>
> How often do you have to go back and forth between 2 and 3?
> Whenever the edit button is clicked, the editor is saved, etc?
> Before or after the annotation is shown in a viewer?
>
> Does annotator.editor.subscribe('save') help?
>
Reading this out loud, I have the reaction that I should simplify my
implementation. I'd like to have one array of hashes, which is the
format that annotator stores in memory and the backend server receives.
The editor is modified to reflect the array of hashes. When the "save"
button is clicked, the user interface is then translated to the array of
hashes.
I think there are 2 states. I think this sort of relates to the bigger
picture challenging of decoupling the UI, where I have an advanced UI
that can't use simple serialization for form submission, but I just am
in need of a way to convert back and forth between states.
>
> Actually, annotator.subscribe('annotationEditorSubmit', callback) is
> better. The callback will receive the editor and the annotation as
> arguments.
>
> I say this is better because subscribing to the save event doesn't
> guarantee that your handler will be called before the other save
> handler set up by annotator (which triggers annotationEditorSubmit and
> the storage cycle). annotationEditorSubmit is probably the way to go.
I'll revisit the "save" and "annotationEditorSubmit" events... I thought
I had looked at them before, but now I can't remember.
Thanks for your help.
Steph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20140411/7313eadf/attachment-0004.html>
More information about the annotator-dev
mailing list