corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Franz de Copenhague <franzdecopenha...@outlook.com>
Subject RE: [Document Model] RE: Initial questions about web-based application
Date Sun, 08 Mar 2015 20:53:13 GMT


> From: franzdecopenhague@outlook.com
>  
> > > 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
> 
> I agree that HTML5 is a good model to feed into the editing library to support the edition
of paragraphs, lists, text, tables, images. But what about sections, headers, footers, fields
(author, date, etc ), styles and themes? All of them are document features implemented either
docx or odt and so far they are not supported by DocFormat API. 
> 
> For example, If the section feature is implemented in the web app and the user creates
a section with 3 columns. It can be rendered like this example http://www.w3schools.com/css/tryit.asp?filename=trycss3_column-count,
but somehow DocFormat needs to know that it is a section to translate to docx or odt. 
> 
> HTML5 is good to serialize from/to DocFormat api, and good to be edited by the editing
library but web app will need a model/controller on top of the HTML DOM to support same features.
Any thoughts?
> 
> -JD
> 

Considering that HTML5 is itself the model, the web-app can decorate the HTML tags with HTML
data- attributes to serialize the model. (See http://www.w3schools.com/tags/att_global_data.asp)

For example, a section with 3 columns can be define as:

<section data-web-app-column-count="3"><p>Lorem ipsum dolor sit amet, consectetuer
adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat
volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis
nisl ut aliquip ex ea commodo consequat.</p></section>

Now, I see that this approach can be extended to the HTML generated by DocFormats and instead
of using the HTML id attribute filled with "wordNN", we can use <p data-df-tag-index =
"2">. This is an little enhancement that breaks the constraint in the id attribute and
any web editor application will be free to use the id attribute on its own.

<body><p data-df-tag-index="2">Hello World!</p></body>


JD 


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