Tag Archives: final report

Improvements to ActiveJS

The ability to create relations between the different objects of the application (a user has many articles, a section has one HTML content) was believed to be implemented in ActiveJS as it is implemented in Ruby on Rails.

An attempt to define the relations between articles and sections was implemented as follows:

[code lang="js"]
Section = ActiveRecord.create('sections', {});

Article = ActiveRecord.create('articles', {
created_at: '',
updated_at: ''
});

Section.belongsTo( Article );
[/code]

And when relations were to be set between instances of the User and Article class:

[code lang="js"]
article1 = Article.create({
created_at: now(),
updated_at: now()
});
section1 = Section.create({ });
section1.createArticle( article1 );
[/code]

It appeared however that those two assumptions were false. ActiveJS in its official implementation requires the following to be written:

[code lang="js"]
Section = ActiveRecord.create('sections', {
article_id: ''
});

Article = ActiveRecord.create('articles', {
created_at: '',
updated_at: ''
});
Section.belongsTo( Article );
[/code]

[code lang="js"]
section1 = Section.create({ });
section1.createArticle({
created_at: now(),
updated_at: now()
});
[/code]

The fact that it was not possible to use pre-existing objects when creating a relation between two objects penalising problem, as it was actually impossible in the application to create a presentation once all of its slides were created.

Instead of working around those two issues, it was decided to spend some time implementing the missing features. The first two snippets of code can now successfully be used with the improved version of ActiveJS and additional unit tests were added to the existing one to ensure that those change will still work with future versions of the framework.

The model

The database

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.