Skip to content
This repository has been archived by the owner on Jan 10, 2022. It is now read-only.
cliftonc edited this page Jul 25, 2011 · 1 revision

The Vision

The original vision of Calipso was to use NodeJS and MongoDB to create an incredibly fast and flexible CMS that didn't suffer from any of the issues that attempting to shoehorn content into a relational database leads to.

In addition, it was felt that the inherently event and module based approach that NodeJS takes into its core was actually very similar to the way other popular CMS platforms (e.g. Drupal) are built around, though they have had a constant battle against the fact that their underlying technology stack causes an impedence mismatch (opinion of author here of course!).

So, in end April 2011, I began writing the initial core of what would become Calipso. It has been written based on the following principles and core ideas:

Core

  • The core would do very little, it would provide enough to get a basic server running.
  • Everything that can and should be asynchronous must be asynchronous.
  • The core will focus on providing the basic framework within which modules (e.g. essentially mini MVC applications) can be run and themed.
  • It should be multi-lingual from core outwards.
  • Environment configuration will be abstracted out to enable use on large and complex projects.
  • A Command Line configuration tool will be created to enable integration with Continuous Integration platforms.

Storage

  • MongoDB will be used as much as possible, the initial versions therefore will not be storage agnostic.
  • Apart from configuration, everything should go into MongoDB by default (including sessions - to enable correct operation in a clustered configuration).

Modules

  • Modules can respond to a request, but they will do so in parallel and fully asynchronously.
  • Where there are dependencies, these are described within the dependent module (e.g. the Content module contains the fact that it depends on the Content Types module), and managed via events.
  • Modules will install, initialise and register themselves.
  • Modules expose their own functions and helpers to views.

Themes

  • Themes can be switched at run time.
  • At all times the modules expose UI elements (e.g. structure), this structure can be later modified within the theming layer.