Rewritable Django apps
The common good approach in designing applications for Django is write them to be reusable. Another approach is to build rewritable applications on top of reusable ones.
What’s the point?
There’re number of specific tasks, which can be splitted to generic blocks. But it seems, some “generic” blocks better not to be generic by theirs nature, because they need “a little bit specific” usage for every project.
We can build such apps in two ways:
- make big reusable application with customization settings or
- build rewritable application
Reusable vs Rewritable
Here’s comparison table of approaches.
| Reusable | Rewritable |
|---|---|
| Try to cover most generic use cases “out-of-box” and provide settings | Set of “sketches” to provide basic use cases with examples for usages and possible extendings |
| Source code is redundant as it covers different use cases | Source code is minimalistic |
| Usually depends only on Django and extra generic Python libs | Usually are build on top of other proven applications |
| You’d better not modify application source | Application source can be rewritten or extended using provided basis |
Examples
Reusable:
- django-tagging
- sorl-thumbnail
- and many other Django apps
Rewritable:
- django-accounts-basic
- (… actually, it’s hard to find examples, as that’s not common practice to publish such apps, but they MAY be useful! Here may be: basic e-shop application, basic wiki application, etc. Yes. I know, there ARE e-shops and wikis, but they are designed to be reusable, not to be rewritable).
Conclusions
Both approaches are for applications made by programmers for programmers.
Reusable applications are good for providing “out-of-box” solutions for generic tasks, they are rather “solid”, so fine customization is hard or can cause overcomplication.
Rewritable applications are good for providing code basis on top of reusable apps. They must be clean and as small as possible and it’s critical to provide working examples.
