Gallery is split in 4 logical parts around one single connection point, The Core application
The Media applications: actual data to show, this can be photos, videos, documents, sound, ...
Each media type has its own application, with its own helpers (cache resized photos, generate thumbnails, etc.)
The Organizational applications. Are elements stored in a tree, with arbitrary depth and contents ? Are elements just grouped by type ? Is everything done with tagging ?
The Metadata applications: Exif for photos or videos, or other sideband metadata.
The ACL applications: who can access the media, how ?
Splitting all these parts in different applications allows:
This is the only mandatory application of mg.
Media models all inherit from mg.core.element.models.Element. In order to implement each media model, Element must be inherited from. In database, this implies data is scattered in many tables and costs an extra index join (not very expensive). In turn, this provides extra flexibility when using The Organizational applications: all media can be referenced in bulk as Element. This is globally a good thing.
In code, when handling an Element object, actual subclass fields are not accessible. Django provides an accessor to the inherited instance (like my_obj.photo), but here, you may not know what model is inheriting (thus unable to say “photo”). Therefore the Element class provides an accessor (actual_element()), which returns the real object “under” an element.
The mg.core.element application also provides generic templatetags which permits to show an element without worrying about its actual type. elem_view and elem_preview use the same kind of implicit template naming than built-in django generic views, and transparently rely on specific templates for each media type.
The organisation of the gallery is optional, and could be ommitted at all. The sole purpose of organizational models is to group elements by other criteria that their own data (timestamp, name, etc.).
Application models described below permit to build different kinds of hierarchy for your elements. See Tutorial: Sorting galleries through rolls for an example.
Applications with models containing elements must adhere the mg.core.element.utils.protocols.ElementContainer protocol.
The Media applications models only contain data, but most media comes with metadata, like Exif. These metadata can be extracted and saved in the database. Depending on your needs, you may like to add different applications to your project to provide metadata to your media.
See Tutorial: Adding Camera information to galleries for an example.