You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by Juande Manjon <ju...@outlook.com> on 2015/03/07 21:37:55 UTC
Initial questions about web-based application
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?
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.
-Juande
RE: Initial questions about web-based application
Posted by Franz de Copenhague <fr...@outlook.com>.
>
> Note that “responsive design” in the context of the editor (or at least how
> I’ve always used the term) simply refers to the fact that you can resize your
> browser window, or view a document on a tablet/phone which you can
> rotate, and the text will automatically be reflowed. This has always been part
> of web browsers since the beginning (despite a huge army of print-oriented
> design people trying to fight it) - it does not require any special frameworks
> or libraries, as it’s inherent to the way that HTML layout works by default.
>
> —
> Dr Peter M. Kelly
This point is pretty clear, with HTML5/CSS and responsive frameworks, it is out of the box.
For Example:
* Standard CSS http://www.w3schools.com/html/tryrwd_simple.htm
* CSS Framework http://www.w3schools.com/html/tryrwd_bootstrap.htm
- Juande
Re: Initial questions about web-based application
Posted by Peter Kelly <pm...@apache.org>.
On 8 Mar 2015, at 8:07 pm, jan i <ja...@apache.org> wrote:
>
> On Sunday, March 8, 2015, Peter Kelly <pm...@apache.org> wrote:
>
>>> On 8 Mar 2015, at 3:10 pm, jan i <jani@apache.org <javascript:;>> wrote:
>>>
>>> Important is that the client is based on responsive design, using e.g.
>>> foundation.
>>
>> Note that “responsive design” in the context of the editor (or at least
>> how I’ve always used the term) simply refers to the fact that you can
>> resize your browser window, or view a document on a tablet/phone which you
>> can rotate, and the text will automatically be reflowed. This has always
>> been part of web browsers since the beginning (despite a huge army of
>> print-oriented design people trying to fight it) - it does not require any
>> special frameworks or libraries, as it’s inherent to the way that HTML
>> layout works by default.
>>
>> Ups I actually meant more...,.on a big screen you can have more gadgets
> visible in form of e.g. icons. You can have a topmrnu with sub menues
> etc...,..on a small screen som of this would be present and e.g, menus
> would typically fold differently.
>
> Our Homepage is an example of something that is more than changing the text
> fliw.
Are you referring to the need for responsiveness in the editing UI, or in the documents themselves?
I would argue that responsiveness in the documents themselves is not realistically achievable, because although we could certainly achieve it in HTML, formats like docx and odf do not cater for this at all, and since that’s what a large proportion of users are going to be saving their documents in, there’s little point in supporting it in the editor.
I agree however that a responsive design approach for the UI itself is both desirable and achievable.
—
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)
Re: Initial questions about web-based application
Posted by jan i <ja...@apache.org>.
On Sunday, March 8, 2015, Peter Kelly <pm...@apache.org> wrote:
> > On 8 Mar 2015, at 3:10 pm, jan i <jani@apache.org <javascript:;>> wrote:
> >
> > Important is that the client is based on responsive design, using e.g.
> > foundation.
>
> Note that “responsive design” in the context of the editor (or at least
> how I’ve always used the term) simply refers to the fact that you can
> resize your browser window, or view a document on a tablet/phone which you
> can rotate, and the text will automatically be reflowed. This has always
> been part of web browsers since the beginning (despite a huge army of
> print-oriented design people trying to fight it) - it does not require any
> special frameworks or libraries, as it’s inherent to the way that HTML
> layout works by default.
>
> Ups I actually meant more...,.on a big screen you can have more gadgets
visible in form of e.g. icons. You can have a topmrnu with sub menues
etc...,..on a small screen som of this would be present and e.g, menus
would typically fold differently.
Our Homepage is an example of something that is more than changing the text
fliw.
rgds
jan i
> —
> Dr Peter M. Kelly
> pmkelly@apache.org <javascript:;>
>
> 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)
>
>
--
Sent from My iPad, sorry for any misspellings.
Re: Initial questions about web-based application
Posted by Peter Kelly <pm...@apache.org>.
> On 8 Mar 2015, at 3:10 pm, jan i <ja...@apache.org> wrote:
>
> Important is that the client is based on responsive design, using e.g.
> foundation.
Note that “responsive design” in the context of the editor (or at least how I’ve always used the term) simply refers to the fact that you can resize your browser window, or view a document on a tablet/phone which you can rotate, and the text will automatically be reflowed. This has always been part of web browsers since the beginning (despite a huge army of print-oriented design people trying to fight it) - it does not require any special frameworks or libraries, as it’s inherent to the way that HTML layout works by default.
—
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)
Re: Initial questions about web-based application
Posted by jan i <ja...@apache.org>.
Hi.
On 7 March 2015 at 21:37, Juande Manjon <ju...@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?
>
Peter made a demo before the source became opensource, that merely showed
it could be done.
Let me short explain our current idea (remark, idea mean that it can be
changed):
Build a webclient in html5/css with the editor window as an iframe
(DocFormat delivers html5/css). The editor should use javascript (in repo)
for the edit operations, and callback subreq to "talk" with docFormats.
The subreq could e.g. be ajax based, but there are multiple possbilities.
Important is that the client is based on responsive design, using e.g.
foundation.
The backend, can be either a httpd module (long term) or a simply python.
The python will give the connection to docFormats. Remark the python should
have a possibility to work without the webclient, and simply do the convert
so that if you open .docx files, they are shown as html5 rendered correctly.
Currently we are tossing ideas, none of us is working very active on this
part.
>
> 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.
>
Yes and No, there are no defined model, but DocFormats delivers and accepts
html5/css so that gives you an implicit model.
I hope that gives you a starting point, feel free to ask/discuss ideas this
is how we get a better product.
For info, we are trying to make a release relative shortly, so most of us
are pretty busy, but if you would look at the web, that could really be
fantastic.
rgds
jan I.
>
>
>
>
>
> -Juande
>
>
>
>
Re: Initial questions about web-based application
Posted by Peter Kelly <pm...@apache.org>.
> On 8 Mar 2015, at 3:37 am, Juande Manjon <ju...@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)