Learning the Python Web Framework as a Front-End or CMS Developer
You can take Django head-on, or you can come at it sideways. The head-on way would be to jump in and tackle the infamous Polls app as instructed in the mega-tutorial on the Django Project website. If that works for you, great. I got halfway through and lost steam, because I’m busy and I found it incredibly boring.
My work required me to learn the Django templating language, so I skipped ahead to that and got it pretty quickly, and outside of that in my free tinkering time I got sidetracked from Django entirely, with my curiosity pulling me instead towards Jekyll and Node.js. Then some Django builds pulled me back in, and here’s a few things I found helpful trying to sneak up on Django and learn it the lazy way.
Note: this post is aimed at front-end or CMS developers without a lot of MVC experience – who are coming at Django as their first big web framework.
Starting at the Front
If you’re a front-end developer or designer, like me, your comfort zone isn’t system architecture and databases. It’s HTML, CSS, and JavaScript – and design. If you’re a visual obsessive, it’s easy to get impatient when you have to wait a really long time to get to the point where anything cool-looking gets outputted to your screen.
For all these reasons, this tutorial started to get the lightbulbs turning on for me: Django for Web Designers and Front End Developers, by Tracy Osborn from PyCon 2014.
Osborn has a disarming, super-approachable style and her own story is inspiring if you’re mainly a designer and looking to learn a serious framework like Django: she built her own web app which became a profitable small business. Her book-in-progress (pre-order here) looks like it will be a very promising elaboration of this tutorial, which differs strongly from the polls app by starting with views instead of models. Also it does not assume you arrive with a solid understanding of MVC.
This approach is incredibly helpful for a front-end person, because you quickly get an understanding of how Django assembles output to the browser and right away you start styling things and serving static files. The Django templating language comes first, with all its built-in tag awesomeness, using basic placeholder data, and only after all this do you get into models.
This may seem not only sideways, but full-on backwards if you are a back-end programmer, but believe me, it’s not only helpful for a front-end person, it’s actually practical. If you’re working on a Django project with even one other developer who has more back-end chops, the templating language and changes to static files and views will quite likely be all you need to know.
Of course, given the prevalence of MVC architecture on the front-end with libraries such as Backbone, Angular, most web developers will eventually need to know this design pattern even if you’re mostly concerned with interfaces and experiences. I doubt Django is the easiest way to learn it, but it does pay off, and the wonderful thing about Django is the depth and detail of its documentation: it’s all clearly explained, and Python code as sane and readable as code gets.
Paths to Glory
In Django, every page in your website has an entry in urls.py – a so called URLconf – that tells it which view to use, and the template gets assigned in the view. The urls.py file is like a traffic controller that steers site visitors to the appropriate address. If you’re used to CMS’s or HTML, at first, it may seem like a pain in the ass to define all the URL paths by hand. If you’re just creating a handful of pages, defining a url pattern, which directs to a view, which assigns a template seems like a lot of work.
But of course, this is a system built to scale – to create web applications used by hundreds or thousands of users, to create any kind of content you can cook up. Django can route a url not just to a single page – ‘mysite.com/about’ to an ‘about.html’ template – but any number of urls to any number of pages – ‘mysocialnetwork.com/users/profile_00012098093’ to the 12,098,093rd user’s profile page, served up with something like ‘user_profile.html’.
Now we’re talking! But here’s the hitch – to unlock that power, you’ve got to roll up your sleeves and learn some regular expressions. Yes, those mysterious heiroglyphs that look like a string of cartoon curse words. I know. Annoying. Other web frameworks don’t make you do it (I admit I prefer the simpler way of creating routes in Express).
Django is like “you’re an engineer, of course you know regex, dummy.” My suggestion is don’t go down the rabbit hole too deep – learn by creating something, go one character at a time to master the expression you need to read or write at the moment. Then move on.
Routing URLs is only the half of Django’s URL dispatcher – it doesn’t just take patterns and direct them places. It lets you grab values from those patterns – like the post name in ‘myblog.com/movies/django-unchained’ – and pass that on to your view, where you will send data to your template, then use Django’s templating language to do things like this: <h1>{{ movie.title }}</h1>.
Models and Migrations
Now is a good time to be learning Django, and that’s because migrations are built in. And after digging into the above topics to get your hands dirty and make things less boring, maybe it’s a good time to revisit the polls app.
Something to get in your head right away if you’re coming from CMS-land is this: database migrations are NOT a way to keep your data in something like version control. There’s even a command called ‘syncdb’ and no, it does NOT sync your database in the way you may be thinking. All of this has nothing to do with the content in your database – that you have a user named ‘Joe,’ and a poll named ‘Funky Christmas’ with 18 votes yes. None of your actual content in included in any of this syncing.
This is all about managing the schema of your database: the structure of the data, what’s being stored, what type of information goes where, and what the relationships exist between your data. That’s pretty important stuff. It’s what your database can do, rather than what it contains.
A comment on the polls app. It is long, very detailed, kind of epic, and someday may go down as a kind of classic of technical literature from this era of web frameworks. The polls app, like Django, expresses certain preferences. Does it do anything to help you get up and running quick that it takes you into the Django shell before taking you into the Django admin interface? Not really. But it is really cool that you can so easily interact with your database models on the command line. It does make sense in terms of leading up to writing views. And it may come in handy sooner than you think, like when you lock yourself out of the admin because you forgot the password.
A View is a Function
This was a lightbulb moment to me. Wrapping your head around MVC (or Model View Template in the case of Django) is not easy, because you have to ingest several abstractions at once. But a function is a very familiar construction if you’ve done any programming at all. Just think of a view as a function that gathers your data and shoots it like a bolt of electricity into the reassuring HTML-land of your template.
Configuration Over Convention
Ruby on Rails is said to favor “convention over configuration.” Django is said to be “configuration heavy,” and I have found this to be true. It is a lot about choosing between several possibilities. On a Django project, the templates might be in one of several places. Same with static assets you are working with. And it goes on like that.
A lot of this is due to Django’s concept of your app as a collection of standalone apps – independent modules, almost like packages or project dependencies. In reality though, things get tangled. I’ve found myself splitting my template, CSS and JavaScript over a projects ‘home’ app and an app within it that theoretically, would stand on its own. If this sounds overly complicated, believe me it can be.
This isn’t necessarily a flaw of Django. It gives you the flexibility to do things how you want, and it’s up to you to organize the code well. But I will say that breaking things into their own apps as a default way of doing things can easily go wrong, which leads us to…
Apps Gone Wild
Once you get the hang of this stuff – defining your content with models, wiring urls up to views, catching all the output in the templates – you can kind of go nuts with it. Everything becomes a custom app, and you can quickly build your own tailor-made CMS with an Events app, a Shop app, a Maps app, whatever.
Once you get the basic hang of it, but are still inexperienced, you reach a point where a framework is empowering you more than it is guiding you. Does everything need to be modularized, with its own models and templates bundled with an eye to repurposing? Or would you be better off more tightly coupling functionality into your core application?
It all comes down to what you want to do, and lot of trial and error.
