Fwd: Thoughts about our editor in a new environment.

[jan i]

Ups had a small mail address mistake here.

rgds

jan i.

---------- Forwarded message ----------
From: jan i <ja...@apache.org>
Date: 10 September 2015 at 10:26
Subject: Thoughts about our editor in a new environment.
To: "d...@corinthia.incubator.apache.org" <d...@corinthia.incubator.apache.org>

Hi

I have been thinking how we can make 1 editor, available where we want it to be available, and how we can structure the software so we maximize reuse.

My thoughts are surely not a golden egg, but hopefully enough to start the discussion.

Centering our editor around the existing JS seems logical.

The JS scripts should be our one and only, editor FUNCTIONALITY (meaning how to insert/delete etc, but not the activators like buttons).

In order to make the JS script useable as a library, we need to add (at least) 1 JS file that contains:

- The list of actions that can be called, with explanation (e.g. "insert style at position")

- The list of callbacks that must be supplied with explanation (e.g. "save this HTML5 document")

With that library it becomes easy to add different editor frameworks, which seems to have very little in common.

I suggest 2 frameworks

- Qt, for all standalone based editors for all platforms

- A web based editor using node.js and python binding.

Thoughts ?

rgds

jan i.

[Peter Kelly]

On 10 Sep 2015, at 5:25 pm, jan i <ja...@apache.org> wrote:

Hi

I have been thinking how we can make 1 editor, available where we want it to be available, and how we can structure the software so we maximize reuse.

My thoughts are surely not a golden egg, but hopefully enough to start the discussion.

Centering our editor around the existing JS seems logical.

The JS scripts should be our one and only, editor FUNCTIONALITY (meaning how to insert/delete etc, but not the activators like buttons).

In order to make the JS script useable as a library, we need to add (at least) 1 JS file that contains:

- The list of actions that can be called, with explanation (e.g. "insert style at position")

- The list of callbacks that must be supplied with explanation (e.g. "save this HTML5 document”)

There’s already an API defined, but it has zero documentation, and isn’t exposed in the way that most JS libraries these days expose APIs. I’m a bit out of touch with what the standard practice is for JS module systems like npm/browserify/requirejs but i think these would be worth looking at to determine the best approach.

Currently the closest thing to a formal API definition is in the following file:

experiments/sample/code/objc_bindings/EDJSInterface.h

or it’s C++ equivalent:

experiments/corinthia/src/JSInterface.h

This defines a set of modules, and indicates the methods/parameters/return types. Within the JS code, these are all global variables (e.g. Selection_selectAll in the file Selection.js). In node.js for example, I think you have a module object implicitly defined, and you say module.exports = { … }. So we need to work out a way of doing this that will avoid the need for global variables.

We’ll also need to consider the dependencies between modules, e.g. Selection.js uses DOM.js but not the other way round (to the best of my knowledge). Angular.js has quite a nice dependency injection technique which we could consider for this.

So I think the code should still remain in multiple files, but exposed using such a module system. Then the next main thing is documentation. I’ll make this my next main priority.

Also, I noticed you’d imported the editor files into corinthia-editorlib, but not the related tests. I suggest we keep the two together in the same repository, since they’re so closely tied together.

I actually have very extensive history for the editor library which was never present in the original Corinthia repository that I made publicly available last year, since it began with what at the time was simply a snapshot of the relative parts of the code from UX Write. However I’m now going through the UX Write repository and using some git gymnastics to try and extract the full history of *just* the JS editing code. Once I’ve done this I’ll put it in a new branch in corinthia-editorlib. I think history could be at least of some help for others trying to understand the library, but I agree that proper documentation is needed.

With that library it becomes easy to add different editor frameworks, which seems to have very little in common.

I suggest 2 frameworks

- Qt, for all standalone based editors for all platforms

Yes - I would describe this as an application though, rather than a framework.

One issue to think about is whether we want to have the “model” parts of the code independent of Qt or not. The advantage would be that it could be reused by other native apps, e.g. if someone wants to build a native OS X app using Objective C++ (or even Swift, with appropriate bindings). The disadvantage is it means we can’t take advantage of Qt’s nice facilities like shared pointers and collection classes. I’m included to go all-in with Qt, esp. now we are free of licensing issues.

- A web based editor using node.js and python binding.

I’d advise using either node.js or Python, not both - there’s no point in using to two different languages for the one server app. A python binding to DocFormats would be separate from this. The existing editing library would run on the client only, not the server - the server side is completely new (well, Franz and now Ian have already made a start on this).

Personally I’m partial to Python for the server-side, but that’s only because I’m familiar with I’ve been using it over the past year in my day job. node.js is perhaps a better choice given that it opens up the possibility of having some JS code that could be used on both the client and the server. But ultimately I’d say it would depend on the knowledge & preference of whoever is willing to write the server code. It could even be in another language.

I expect the server side will be fairly simple, since the main things it needs to do are load & save files from disk, and invoke a small number of API functions in DocFormats. I anticipate that for people who want to utilise Corinthia as a web app, they’ll often want to customise it e.g. to integrate into their existing web-based system. So I envisage our server side as basically a “reference implementation”, so to speak. Then if someone is using e.g. Java or Ruby or whatever in their existing webapp, they could reimplement those few bits of functionality in their chosen language. We could define a REST API that the client side expects to talk to.

For the client side, this will utilise the existing JS editing code as a library, but implement a HTML-based web interface, in a typical fashion to any other client-side UI logic - it could use a framework like angular perhaps with bootstrap, or alternatively we could do everything ourselves. The former is probably easier but I haven’t really formed an opinion on this yet. Keep in mind that this is very much a separate issue from the server side; the two would communicate via a REST API only, and do not necessarily need to share any code.

--
Dr. Peter M. Kelly
kell...@gmail.com

http://www.kellypmk.net/

PGP key: http://www.kellypmk.net/pgp-key

(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

[Franz de Copenhague]

Peter,

Have a look to this editor http://plnkr.co/edit/XxwMysyKAXo5VKbzDJwE?p=preview

-Franz

---

Subject: Re: Thoughts about our editor in a new environment.
From: kell...@gmail.com
Date: Fri, 11 Sep 2015 22:03:56 +0700
To: corint...@googlegroups.com

--
You received this message because you are subscribed to the Google Groups "CorinthiaTeam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to corinthiatea...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.