corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <pmke...@apache.org>
Subject Re: Initial questions about web-based application
Date Sun, 08 Mar 2015 09:18:07 GMT
> On 8 Mar 2015, at 3:37 am, Juande Manjon <juande.manjon@outlook.com> wrote:
> 
> Hi folks,
> 
> 
> 
> I have a few questions about the project
> 
> 
> 
> What is the stage of the web-based application? What technologies? Is it
> only done in a front-end? Is there a back-end that interfaces with
> DocFormats API?

Currently we don’t have a web application, though I’ve done some experiments with this
(which I need to dig up the code for). There are two parts to the existing codebase:

1. DocFormats - A native code library (implemented in C) that converts between HTML5 and various
file formats (so far .docx is the only properly supported format). This is what virtually
all of the activity on the project has focused on to date, since the code became open source.

2. Editor library - Implemented in javascript, designed to be used in either a web browser
or embedded web view (e.g. UIWebView on iOS or QWebView in Qt).

These two libraries are 100% independent of each other; there is no function call relationship
or shared API usage whatsoever. Each can be used independently (e.g. DocFormats for a batch
conversion tool, or the Editor library for a content management system if HTML5 is the only
required format). Alternatively, as in UX Write and the desktop and web apps we plan to write,
they can both be used by the app for importing/exporting files to HTML5 format and then editing
the document.

The next two things we have planned are:

3. A native desktop app, implemented in Qt, which uses both DocFormats and the Editor library.
The latter will run in the context of an embedded QWebView.

4. A web app, implemented in Javascript. This will consist of both a client side and server
side component. The client side component will contain an iframe, to provide the context in
which the Editor library executes. It will also provide a user interface (either implemented
using some existing Javascript UI toolkit, our a custom solution) that interacts with the
editing library to manipulate the document as HTML within the iframe. The server-side component
will need to some way to browse/open/save files, and call out to DocFormats to do conversion
where necessary. We haven’t yet decided on an implementation language/framework for the
server side, but in principle pretty much anything could be used.

> Is there any Document model defined? I mean for Document model an abstract
> model that's defined the structure of the document like sections,
> paragraphs, lists, text, fields, tables, images and styles.

The document model is HTML5 - that is, it’s identical to what the browser uses.

This gives us the vast majority of what we need for an editor “for free”, in that it is
provided by the web browser or embedded web view.

The editing library consists of JS code that conducts all editing operations using W3C DOM
APIs. It’s basically the same sort of thing as CKEditor and various other similar web-based
rich text editors commonly used on wikis/content management systems/blogging engines.

—
Dr Peter M. Kelly
pmkelly@apache.org

PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)


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