Table Of Contents

Previous topic

6. Developer documentation

Next topic

2. List of how-to’s

This Page


Previous versions


1. Architecture overview

This document describes the architecture of openPLM.

1.1. Main dependencies

1.1.1. Django and Python

OpenPLM is based on Django : a Python web framework. Django follows the model-view-controller design.

1.1.2. Celery

Celery is an asynchronous task queue/job queue based on distributed message passing. In openPLM, we use Celery (version 2.3) to:

  • send mails
  • update search indexes
  • run cron jobs

See also

The documentation of Celery: .

RabbitMQ, an efficient message broker recommended by Celery.

1.1.3. South

South is an intelligent schema and data migrations for Django projects. All applications of openPLM are managed by South to ensure easy updates.

1.1.4. Haystack and Xapian

Haystack is a Django application that provides modular search for Django. Haystack makes it possible to plug openPLM with an efficient search engine. Xapian is a search engine and xapian-haystack is a backend for use with Haystack and the Xapian.

See also

The documentation of Haystack: .

1.1.5. Graphviz and PyGraphviz

graphviz is a tool to generate graphs. It has a lot of features to custom the rendering. PyGraphviz is a Python binding for Graphviz. openPLM uses PyGraphviz to generate the graphs of the Navigate page.

1.2. Directories

 | apache/                    apache/wsgi files
 | apps/                      optional applications
 | bin/                       misc executable scripts
 | datatests/                 test data
 | django_xml_test_runner/    an incorporated dependency required to run test
 | etc/                       files that should be copied to /etc (celeryes configuration files)
 | help/                      help messages in reStructuredText format
 | locale/                    translation data
 +-media/                     all media files (served by apache)
 |  css/
 |  img/
 |  js/
 +-plmapp/                    core application (most of the code!)
 |  controllers/
 |  decomposers/
 |  customized_models/
 |  filehandlers/
 |  fixtures/
 |  management/
 |  middleware/
 |  templatetags/
 |  thumbnailers/
 |  tests/
 |  views/
 +-templates/                 core templates
 |  blocks/
 |  documents/
 |  groups/
 |  import/
 |  mails/
 |  navigate/
 |  parts/
 |  search/
 |  snippets/
 |  users/

1.3. plmapp

plmapp is the main application of openPLM. It defines main models, views and controllers and is the core of openPLM.

1.3.1. Models

A model is the single, definitive source of data about your data. It contains the essential fields and behaviors of the data you’re storing.

Django’s documentation


1.3.2. Controllers

In Django, applications do not have dedicate controllers and let this kind of work to views. But openPLM has several kinds of views (html, api), so to keep the views simple and stupid, openPLM has controllers. Controllers manage user’s rights (they ensures the user can do the asked action) and check inputs. Controllers also keep trace of what have been done (histories) and send mails to affected users.


The following figure shows which models a controller manages. As you can see, PartController manages the Coffee model since CoffeeController does not exist.


1.3.3. Forms

openPLM has many forms. Some forms are generated dynamically from a model (similar to a Django ModelForm). Obviously, views use forms but controllers also use form. For example, Controller.update_from_form() and PLMObjectController.create_from_form() take a form as their argument.



openPLM splits its views module:

  • all common functions are in the base_views module
  • classical HTML views are in the main module
  • ajax views are in the ajax module
  • views that handle the HTTP/Json api are in the api module


1.3.5. Tests

See Testing openPLM.

1.3.6. Others

A complete list of documented modules is available here.

1.4. Custom applications

See Applications and How to add a model (django application).