Design

Foreword

Several media gallery projects exist out there, and we tried to see what was so different between them. If you let aside the language wars (PHP, Python (Django), ASP, Java), there are few differences between all gallery projects. Most have in common the following points:

• Themable (you can change the HTML design)
• Can import bunch of images
• Automatically generates thumbnails

Some have advanced features:

• Can import image archives
• Have a fully asynchronous JS frontend with no slow page loading, image prefetching, etc.
• Can also host movies, text, sound, etc.
• Multi user, with ACLs
• Give rights to access photos for a limited time frame through “session tokens” (generally urlencoded)

Most of the duplicate projects differ on one thing: the file tree modeling:

• Some galleries are just one big bunch of elements with searcheable tags, date, name, comments, author, type, etc. And also have sorted views of the library (by date, author, etc.).
• Some galleries are 2 levels deep, like “User/Portfolio/Photo”, with no flexibility (you won’t be able to have a picture in “User/Picture”).
• Some are fully implementing a file tree where elements and directories can be parented in an arbitrary way.

Our wishlist

We were two of us developping two new media galleries, nearly at the same time, with specific needs. Common needs were:

• Use Django (what else ?)
• Be able to handle image archive uploads (through HTTP, FTP, scp, etc.)
• Use external tools for thumbnail generation, and do it offline
• One of us had the additional needs:
  • Have a single user photo library
  • Have a simple Theme/Roll/Picture hierarchy
  • Pretty thumbnails
• The other of us had the additional needs, coming from a former media gallery (in python, but without supporting framework, and no SGDB):
  • Multi-user, ACLs, Session Tokens
  • JS frontend
  • Arbitrary tree support
  • Composed directory thumbnails (ala WinXP)

Having done a little research about available projects, we thought about the following projects, but had some :

• Photologue: Tied to the Gallery/Photo tree, photo-centric. There is a 3.x branch coming, solving some of our rants.
• ...

Design of a Media Gallery with Django

• We are in Django. Apps cost nothing, create lots of them.
• Be able to host other filetypes than pictures, therefore:
  • The core model wont be a Picture or Photo, but an Element. An element is something with a name, a date, and some Thumbnails. Each element type:
    • is in its own Django app. We thought about pictures, videos, text, sound.
    • is responsible for creating a Thumbnail.
    • provides its caches (e.g. reduced image sizes).
• Be able to support most organization models:
  • There is a mg.orga.tree application handling the “directory/...directory/element” model
  • There is a mg.orga.roll application handling a roll of elements
  • There is a mg.orga.theme application handling grouping of rolls
  • You can define your own organization scheme !
• Provide Ajax views of the data, for web browser or “hard” clients
• Reuse Django generic applications for usual tools
  • tagging
  • comments
• At last, the core feature of the project is the flexible data model. Therefore, administrative tweaks must be super-easy:
  • Ease the template creation: provide lots of tags for lots of usual patterns (pick a random element (of a given type), display an element thumbnail with a link, etc.)
  • Ease the integration with other applications: Passing through template tags for everything makes the complex logic stay in mg.
  • Ease the administration adding admin commands:
    • Updating thumbnail cache (should run asynchronously when adding new media)
    • Tweaking the file tree (if you choose the complete tree model mg.orga.tree, there is a shell manage.py mg.orga.tree_shell, which is like bash but living inside the media gallery. You can do standard file actions, review comments, rehash thumbnails, ...)
    • Importing photos (There are admin commands for importing archives, directories, URLs, mails, etc.). See Importing Elements.