Architecture

SLM is built in Python using the Django website development framework. Django is well documented. A basic understanding of how it works is imperative to understand how SLM is put together. In addition to the good intro tutorials, it’s helpful to understand how reusable Django apps work, how settings files work and how management commands work. See below for links to detailed learning and developer resources for Django.

At a high level, Django implements most of the common functionality required of modern relational database-backed dynamic websites. It provides a pluggable request/response pipeline, encourages an MVC design pattern, provides an easy to work with Object Relational Mapping (ORM), manages database structure updates for you, and does a lot more to remove the drudgery from modern web development.

For experienced developers there are a few things to understand about working with a Django based project:

  1. You will not be writting a lot of SQL. You can always drop back to SQL, but Django has a built-in ORM that maps python classes called Models to relational database tables. These classes are easy to work with and allow Django to manage the database structural upkeep for you. If you make a change to one of your models, Django can generate code that will automatically update the database structure for you.

    For example a SQL query that gets all rows from the Site table where the name column begins with JPLM would look like this in SQL:

    SELECT * FROM slm_site WHERE name LIKE 'JPLM%';

    and look like this in Python/Django:

    from slm.models import Site

Site.objects.filter(name__startswith='JPLM')

    The Django code returns an iterable of instantiated objects of type Site where each column in the Site table is a member attribute on the Site object.

  2. Django bootstraps (i.e. configures itself) off of normal python files. This is called the Django settings file and it contains define-like Python variables that control and configure aspects of the framework. To bootstrap any Django project you will need to point the framework at your settings file. This is typically done by setting the DJANGO_SETTINGS_MODULE environment variable. The Django settings file contains plain old data that Django code and third party extensions use to build the data structures that participate in the request/response cycle during runtime, not limited to, but including:

  3. Django uses a pluggable application system to provide extensibility and override. This is the primary vehicle for separation of concerns and encapsulation in Django projects. Django apps bundle database structure, html templates, URL dispatch and views into reusable, separately installable components that can be layered on top of each other. The app stack is set in settings using the INSTALLED_APPS list. Apps that appear closer to the front of the list override behavior in apps that appear further down the list. For example, if an app defines an html template of the same name as an app further down the installed application list, it’s template will be used instead.

    The SLM is implemented as a Django app. An extension app is bundled with the SLM and is optionally installable called slm.map. This contains the mapbox map widget. It is intended that any desired overrides to SLM behavior can be implemented in separate Django apps and installed above the SLM on the app stack. By this mechanism you should be able to avoid forking the SLM if you need more custom behavior.

The below conceptual block diagram highlights some of the major components and responsibilities of the SLM and where they reside.

Django Structure

Django Resources

Django was first released in 2005 and much of the web’s infrastructure is built on it. There are many free and paid resources for learning more about Django and an enormous corpus of freely available third party extension applications.