1. Styling Molly
Bangor University
11 May 2011
Chris Northwood
Lead Developer
Oxford University Computing Services
Mobile Oxford Molly Project
University of Oxford
http://m.ox.ac.uk http://mollyproject.org
http://www.ox.ac.uk
@mobileox @mollyproject

2. TEMPLATE INHERITANCE
• Template inheritance is used to define a base site template
(base.html) which all pages can use to ensure consistent styling
along the site

3. BLOCKS
• Base templates define blocks, which are the areas of the template
which can be overridden by child templates

4. TEMPLATE STRUCTURE
base.html Molly comes with a complete set
of generic templates which can be
used to get a site up and running
very quickly.
library/base.html
Any single template in the
hierarchy can be replaced with
library/index.html one unique to your site.

5. CUSTOMISING A TEMPLATE
base.html
Your template is
used
library/base.html in preference to
the
built-in one
mysite/templates/
library/index.html
library/index.html

6. FINER GRAINED CONTROL
• Replacing a whole template is often a coarse tool, especially if
most of the code remains the same. You lose the benefit of any
upstream template improvements.
• More useful is the ability to only replace part of the template.
• We can do this by extending the original template and only
overriding the part of it we’re interested in.

7. EXTENDING THE ORIGINAL
TEMPLATE
base.html
library/base.html
library/index.html library/index.html

8. EXTENDING THE ORIGINAL
TEMPLATE
• However, extending isn’t quite that simple, your replacement
template hides the original, so you can’t address it in the
traditional method
• To get around this, Molly also exposes all of its templates under
the prefix of ‘molly_default’

9. library/index.html
(in Molly tree)
library/index.html
(in Mobile Oxford tree)

10. • This can be done at any point up the hierarchy
• At the very least, most sites will want to customise
base.html
• Documentation for the full list of templates, and
overrideable blocks within them is incomplete, the
best way to determine what’s available is to read the
code.

11. • Template paths from the point of view of Django are
relative to the containing ‘templates’ folder, i.e., ‘molly/
apps/places/templates/places/entity_detail.html’ is
referenced as ‘places/entity_detail.html’
• Core templates (404.html, etc) are stored in the
‘templates’ subdirectory of Molly. Templates for apps
are stored in the ‘templates’ subdirectory of that app.

12. • If a template isn’t customisable enough for you, raise
an issue on http://issues.mollyproject.org and
additional blocks will be added to the main Molly
code.

13. PRACTICAL TIME

14. MINIFYING MEDIA
• Molly includes a powerful framework for handling CSS and
JavaScript, including concatenating it into single files, and minifying
the code
• This is based on the django-compress library: http://
code.google.com/p/django-compress/

15. CONCATENATION
• Each app is self-contained in Molly, including any styles and
JavaScript
• New HTTP requests are expensive over GPRS, reducing the
amount of external files is desirable

16. SPECIAL FILES
• Molly treats the files smart.css, dumb.css and smart.js specially -
served to appropriate device classes
• For serving, each app’s smart.css, etc, file is concatenated with all
the other apps, to result in one smart.css, etc, for the entire site
• This means there’s no need to reference these files specifically
within your template

17. IT’S NOT PERFECT
• Your CSS/JS ends up on pages that it’s not intended for. Careful
class names and JavaScript guards are needed to avoid
unintentional side effects.
• The resulting files are larger than are strictly necessary in the
context of a single page
• However, in the context of the whole site, this means fewer
requests and is better in most cases

18. MINIFICATION
• Well-understood and widely used
• “Compresses” code by removing whitespace, replacing variable
names with single letters, etc
• Combined with gzip at server-time makes a significant difference
to file size
• Obfuscates code and makes it hard to debug

19. DJANGO-COMPRESS
• Disabled when debug mode is on
• Any file ending ‘.css’ or ‘.js’ is minified
• Adds a timestamp to the filename which allows for clients to
aggressively cache files, whilst also working around cache
breakages
• Templates can access these files using the compress_css and
compress_js template tags, rather than linking to the files directly

21. DJANGO-STATICFILES
• An external library prior to Django 1.3, now part of core Django
• Copies all media files from various places to a single ‘media’
directory in your site
• Also allows for overriding of files - placing an image in your
site_media folder will cause that file to be used, rather than the
default one - useful for replacing logos, etc

22. WHERE MOLLY KEEPS FILES
• Images, CSS and JS that are associated with an app are stored in
the ‘static’ subdirectory of that app
• The ‘media’ folder in the main Molly directory contains site-wide
files - core icons, CSS, logos, etc
• The ‘site_media’ folder in your site contains your manual
overrides

23. BEWARE!
• Django-staticfiles copies all of the files to a ‘media’ folder in your
site folder
• This is where your webserver should serve the files from - but
these are not the source files!
• Files in here should not be edited, as they will be replaced the
next time media is rebuilt - only edit the source files, or replace a
core Molly file in your ‘site_media’ folder

24. HOW TO OVERRIDE A FILE
• Find the relative path name of the image to be replaced (either
through the documentation, exploring the source tree, or by
looking at the URL of the item)
• Place the file you would like to replace that file under the same
path/filename in your ‘site_media’ folder
• Rebuild the media (e.g., re-run the quickinstaller)

25. PRACTICAL TIME