Here at the Texas Tribune, we started using a project called django-chunks some time last year. Consider this post a cautionary tale and think long and hard before you start using. We didn’t. We’re paying the price.
django-chunks gives you the ability to inject arbitrary chunks of HTML into any template inside Django. You load up a template tag library, call a templatetag, and you’re off to the races. No more waiting on clients (or other departments) to get you copy. “Here’s the chunk, go to town,” you tell them.
That seems pretty good, right? We’re all lazy, that’s why we program. The idea of making a computer do something for us tends to be at the core of why most programmers got into programming. Second only to making computers do the work is making other people do the work, so django-chunks let’s us off load that work to someone else.
Once you’ve started making things chunks, everything becomes a chunk. It’s a golden hammer of sorts.
This field needs to be copy edited once in its entire existence? Bring in the chunks!
This type of thinking is shortsighted at best, and harmful at worst. This
morning I took a look at our join page only to discover that we were giving
users a security error due to a mishandled chunk. An image URL had been
http instead of
https, mixing insecure content in to a secure
page. Yes, there was a chunk created who’s sole purpose in life was to be
edited to change out an
Don’t use chunks. The case above is where a simple model should have been used
if we really need to let non-technical people change out the image. We have a
hard requirement on
https on that page, and as programmers we can enforce
Django is meant for building custom stuff. Go do that. Use things that help you build that custom stuff faster, but don’t go looking for turn-key. Someone else’s answer to the problem isn’t going to be as good as what you could have built.