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/
