[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/afd0dba4/attachment-0001.png>