The model of the application has been built with the specifications of the project in mind and the will to make it future-proof. Although it was only supposed to support an application used for managing presentations, creating/editing slides and playing presentations, it seemed sensible to enable, in its design, features such as revision control, collaboration as well as the possibility to store different kind of documents in the application. The following criteria have been considered
- in order to make the model more generic, it is designed for “multi-parts documents”, rather than “presentations composed of slides”,
- the different parts of a document are split to make it possible to load only the parts of the document that the user needs (lazy loading),
- the HTML terminology is used to designate those “multi-parts documents”, a document being an <article>, which is composed of an unlimited number of <section>s
- a document has a unique creator, a user registered in the application, although it might later have multiple authors if collaboration is to be enabled,
- there are no folders in the application, but presentations can be tagged with an unlimited number of tags and later sorted by tags,
- the bin is just a tag which, when applied in a document, prevents it to be displayed in the main view,
- a document can have a theme, which is stored as a style (using the CSS format) that will be applied to all of its parts
- additionally a document can be associated with a piece of script describing its background as vector graphics for example (to be translated either to SVG or VML)
- a section of a document has an HTML content, a style to overwrite the theme of the document and define the layout of the content, as well as a piece of script used to represent its vector graphics content in a browser agnostic way,
- the script, the style and the html content are split to make version control easier (details follow)
This description of the model can be graphically represented as follows:
About the version control
Version control would be easy to implement with this model because it makes creating a new revision of the document inexpensive: when the content of a single section is modified, instead of duplicating the whole document, a new version of the this specific content is created, and only the representation of the document and the sections are duplicated, not their unmodified content. This mechanism is illustrated in the following figures.
Since there is no content at all directly in those representations, the database does not expense at an exponential rate. The elements coloured in red in those figures are the ones potentially heavy weight.
The way the revision control could be implemented is rather clear: to restore a previous revision, a relation between the user an the previous revision (found through the current revision) has to replace the current relation.