sheets/doc/ModelViewArchitecture.dox

0001 /**
0002 \page architecture Document/View Architecture
0003 \author Ariya Hidayat (<a href="mailto:ariya@kde.org">ariya@kde.org</a>)
0004 \date 2004
0005
0006 \par Status:
0007     FINISHED
0008
0009 <p>MVC (Model/View/Controller) means that the application consists of three
0010 big parts, the <i>Model</i> which holds the data structure and objects,
0011 the <i>View</i> which shows the model to the user and the <i>Controller</i>
0012 which handles user inputs and changes the model accordingly. Like other
0013 office applications, Calligra Sheets uses the Document/View architecture, a slightly
0014 different variant of MVC where the View and Controller are put together
0015 as one part.</p>
0016
0017 <p>In order of its complexity scale, Calligra Sheets code has to be well separated,
0018 i.e. the <i>Document</i> and the <i>View</i>. We may also call them as
0019 <i>back-end</i> and <i>front-end</i> respectively. Right now part of which
0020 should belong to the Document sometimes has access to the View. For example,
0021 a cell stores information about its metrics in pixels (which is zoom dependent),
0022 knows whether it is visible to the user or not (which is view dependent), etc.
0023 This needs to be changed.</p>
0024
0025 <p>One easy way to decide whether some stuff or relationship must really really
0026 alienated in the Document is to imagine that somebody wants to create another
0027 View (front-end) to the Document object model (back-end) that is being worked
0028 on. Say, one decent guy would like to copy the look-and-feel of classic Lotus
0029 1-2-3 (for whatever reason we are not really interested in here); so basically
0030 to some extent he can take most part of the Calligra Sheets back-end and glue a new
0031 user interface around the code.</p>
0032
0033 */