1. Pluggable Patterns
For Reusable Django Applications

2. Project

3. Project
Configuration URL routing Templates

4. Project
Application Application Application
Application Application Application
Application Application Application
Configuration URL routing Templates

5. Here there be power!
Project
Application Application Application
Application Application Application
Application Application Application
Configuration URL routing Templates

6. We need a better definition
for “Django Application”

7. An app MyBlog App
should not be • Categories
• Custom Tagging
a monolithic • Custom Comments
pile of code • Comment
Moderation
• Assumption of text
markup type
• Single blogs
For example, most blog • Multiple Sites
“apps” available provide
too much functionality ACME MONOLITHS

8. An application should
be “pluggable”

9. A “pluggable” app is
Focused
Write programs that do one thing and do it well.
— Doug McIlroy (inventor of UNIX pipes)

10. A “pluggable” app is
Self-Contained
Batteries are included
Dependencies are declared

11. A “pluggable” app is
Easily Adaptable
Corey’s Law: The less adaptable you make your code, the
sooner you will be tasked to adapt it.

12. A “pluggable” app is
Easily Installed
pip install coolapp
You did declare your dependencies, right?

13. How do we make a
“pluggable” application?

14. Stop thinking like this
http://upload.wikimedia.org/wikipedia/commons/archive/a/aa/20090315161532!Ferrari_Enzo_Ferrari.JPG

15. and think like this
http://www.flickr.com/photos/motagirl2/4301276868/

16. Applications can have
very different purposes
http://www.photoshoproadmap.com/imagenes/blog/lego-brushes/lego-bricks-high-resolution.jpg

17. Application Types
• Data. Manages specific data and access to it
• Utility. Provide aapplication a specific
problem for any
way of handling
• Decorator.functionality of many applications
aggregates
Adds functionality to one or

18. Data Apps
http://www.geeky-gadgets.com/wp-content/uploads/2009/08/lego-usb-hub_2.jpg

19. Situation 1
Lots of variations
Each implementation is different
(e.g. blogs)

20. Abstract Models
GLAMKit http://www.glamkit.org/
EntryBase
FeaturableEntryMixin
StatusableEntryMixin
TaggableEntryMixin
HTMLFormattableEntryMixin

21. Situation 2
A few, well-known of variations
(e.g. Use django.contrib.sites?)

22. Optional Field Settings

23. Situation 3
Optionally use another
application
(e.g. Use django-tagging?)

24. Optional Integration

25. Optional Integration

26. Situation 3
You want to reference
different models
(e.g. Customizable author field)

27. Configurable
Foreign Keys
Viewpoint http://github.com/washingtontimes

28. Situation 3
You want to provide hooks for
other applications
(e.g. While processing in a view)

29. Emit Signals
Satchmo http://www.satchmoproject.com/

30. Utility Apps
http://www.1000steine.com/brickset/images/852759-1.jpg

31. Utility apps are
just code libraries

32. Projects with
template tags need one

33. Does it need to be in
?
Yes, if you have:
• Templates
• Template Tags
• Management Commands

34. Decorator Apps
http://trendland.net/wp-content/uploads/2008/12/lego-ring.jpg

35. CoolApp
New Method New Field
Custom Manager New Admin

36. Registering for Decoration

37. Simple Model Registry

38. Model-Data Registry

39. Lazy Registration

40. Situation 4
You want to add a
field to a model
(e.g. Link to another model)

41. Simple Model Registry

42. Situation 5
You want to add a
method to a model
(e.g. Link to another model)

43. Adding methods

44. Situation 6
You want to customize
a model’s ModelAdmin
(e.g. Change the widget of a field)

45. Lazy Registration of a
Custom ModelAdmin

46. Lazy Registration of a
Custom ModelAdmin

47. Lazy Registration of a
Custom ModelAdmin

48. Touch Points

49. Touch Points of an App
The parts of an application that
usually need tweaking
• URLs
• Templates
• Configurable options
• View responses

50. Situation 7
You want the URLs of your app to
live under any prefix
(e.g. /blogs/ vs. /weblogs/)

51. Name your URLs

52. Reference your
URLs by name

53. Situation 8
You want your templates
to be easily overridable

54. “Namespace” Templates
coolapp
templates
coolapp
base.html

55. “Namespace” Templates
All templates in
coolapp a template
“name space”
templates
coolapp
base.html

56. “Namespace” Templates
coolapp
All templates
templates extend a single
template
coolapp
base.html

57. “Namespace” Templates
coolapp
templates This template simply
coolapp
base.html

58. Import your blocks
Allows you to override any of the templates
extra_head.html
content.html
base.html

59. Situation 9
You want to configure your app
without modifying its code
(e.g. API keys)

60. Configurable Options
Django Supertagging http://github.com/josesoa
Internal Name Setting Name Default Value

61. Configurable Options
Django Debug Toolbar http://github.com/robhudson

62. Define a Storage Option

63. Situation 10
You want to alter the
data your views use
(e.g. Extra context, different
template)

64. Add keyword arguments
Django Registration http://bitbucket.org/ubernostrum

65. Class-based Views
http://github.com/bfirsh/django-class-based-views
http://github.com/pegasus/django-baseviews
http://code.djangoproject.com/ticket/6735
http://codysoyland.com/2010/feb/3/thread-safe-object-
oriented-views-django/
http://www.toddreed.name/content/django-view-class/

66. To be continued…

67. My Info
• coreyoordt@gmail.com
• @coordt
• github.com/coordt
• github.com/washingtontimes
• opensource.washingtontimes.com