> On 8 Mar 2015, at 3:37 am, Juande Manjon <[email protected]> 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 [email protected] 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)
