[WebODF] On architecture/layers of WebODF

[Friedrich W. H. Kossebau]

Hi,

((disclaimer: most of the following was done before Jos took back project-
lead, so he might have different opinions on some things :) ))

so here some notes from the last months regarding parts of the architecture of 
WebODF: one is a chart showing the MVC-alike structure, to separate the 
(extended) ODF model things as mapped into the DOM from those which deal with 
proper display in the rendered html page and those which deal with turning any 
input into operations on the (extended) ODF model. The other are about plans 
how to reorganize the classes fo the (extended) ODF model.


The attached image is a quick sketch showing the MVC related 
classes/architecture of WebODF as drafted in November (things have slightly 
changed since then, but in general still valid). Please ignore UML-mistakes ;)

As said before, the idea is to separate display (so showing things to the 
user) related stuff from pure document model stuff. So the latter can be used 
independently in some future, e.g. with another XML/DOM-based system, like a 
node.js server. There was work started on this, working title "xmlodf", but 
then the stream of patches from Down-Under :) and OT-work stalled things.
Which also means the (extended) ODF model classes should have no clue about 
the display related classes. Instead the latter should connect to signals and 
other means of the first ones to get any data (updates) they need.


The planned structuring/layering of the WebODF module was already partially 
integrated in master, so the classes of WebODF could be grouped into ...
... model oriented classes/layers
  G1: loading/saving of pure odf doc
  G2: changing of pure odf doc
  G3: cursor extended odf doc
  G4: changing of cursor extended odf doc 
... and display oriented classes/layers
  G5: displaying of pure odf doc
  G6: displaying of cursor extended odf doc
where dependencies are a DAG and basically Gn+1 depends on Gn...G1, except
that G5 only needs G2+G1 ("G" as in "Group").

These days G3 and G4 also includes the EditInfo, while G6 got the 
EditInfoHandle/EditInfoMarker.

The current namespaces (core, gui, odf, ops, xmldom) are not really ideal 
IMHO. So the proposal from that work branch was like this for the (extended) 
ODF model classes:

xmlodf.utils : (all utility classes)
  Base64, ByteArray, ByteArrayWriter, RawInflate, Zip, xmldom.LSSerializer, 
xmldom.LSSerializerFilter
  EventNotifier, LoopWatchDog
  xmldom.XPath
  PositionIterator, PositionFilter, Selection, Cursor, SelectionManager, 
SelectionMover (create own (sub-)submodule for them?)

xmlodf.core : (the project core type classes)
  StyleInfo (detail of OdfContainer, Formatting)
  OdfContainer, Formatting
  OdtDocument, OdtCursor

xmlodf.ops : (could possibly moved to xmlodf.core)
 Operation

xmlodf.ops.redset : (our current operation set, "red" pointing to bloody 
beginners ;) )
  OpInsertText, OpRemoveText, OpSplitParagraph, OpSetParagraphStyle, 
OpUpdateParagraphStyle, OpCloneParagraphStyle, OpDeleteParagraphStyle, 
OpInsertTable, OpAddCursor, OpRemoveCursor, OpMoveCursor


Hopefully this sheeds some lights into things. I hope we soon have some break 
from the feature rush and can do some more documentation and (complete the) 
redesign, to make the architecture more obvious and also have everyone in the 
same boat.

Possibly I should do a patch to properly order and group with comments at 
least all files in the manifest.js/CMakeLists.txt, to help remembering the 
layers.

Cheers
Friedrich
-- 
Friedrich W. H. Kossebau // KO GmbH
http://kogmbh.com/legal/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WebODF after ROSA-Demo sprint.png
Type: image/png
Size: 58150 bytes
Desc: not available
URL: <http://open.nlnet.nl/pipermail/webodf/attachments/20130723/1356a097/attachment-0001.png>