corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <>
Subject Re: [dfwebserver] API
Date Fri, 13 Mar 2015 01:02:48 GMT
> On 13 Mar 2015, at 1:17 am, jan i <> wrote:
> On 12 March 2015 at 18:52, Franz de Copenhague <
>> wrote:
>> I am thinking about what server features are required by the editor.
>> 1. Upload a document
>> 2. Get the HTML abstract of the document
>> 3. Push the edited HTML representation in the document
>> 4. Upload new images and other embbed objects in the edited HTML
>> 5. Download the document
> These are the very basic features, but I think you also need:
>    6. Get a list of all styles (so the user can add styles)
>    7. Generate new table of index, subject index etc.
> Peter published a list of functions that the current JS needs:
> I would expect we need to have all of them implemented (hopefully a bit
> more generic).

Actually these are all the functions the current JS code *provides*. What it does need are
the following callbacks:













All of these are called asynchronously, and actually the calls aren’t made by the library
themselves, but are added to an array of “messages” - see Editor/src/Editor.js for details.
The reason I implemented callbacks in this way was (at least at the time) the UIWebView class
in iOS did not provide any way for JS code to invoke Objective C code, which is what needed
to happen in all of the above cases. So after every call to one of the API methods listed
on the wiki, you’re supposed to call Editor_getBackMessages(), and you get an array of arrays,
each indicating the function name and parameters.

As you can see, the set of callbacks is very small; the majority of work is in implementing
all the logic that invokes the already-provided APIs from the wiki. Also the outline methods
above are optional, and only necessary if you wish to provide a real-time document map (see
the first screenshot at The same goes for autocorrect.

For the web-based editor, I suggest we implement a wrapper class for the API which, for each
function, calls the real implementation version and then invokes Editor_getBackMessages()
to invoke registered callbacks. Otherwise the UI code is going to be really awkward and we’ll
likely forget to do it in some places. I can help get this going and will try to find some
time to do so soon.

Dr Peter M. Kelly

PGP key: <>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message