14. Likely Further Subjects
This will not cover all of Django. But subjects many may move on to.
Deployment
Most websites, guides, and books do not talk about deployment. These materials are written by and for professionals—who are assessing a technology— or wannabe professionals like students—who are learning. These people have no interest in deployment—they are either learning, or have an established procedure. However, it’s no use building a website, then finding there is no way to get it online. You may say to me, bewildered, “But, all the technology available… no technology could be popular without having an established method of deployment… isn’t it easy?” The answers from any direction are “No”. Often, a web technology, especially one that is only a few years old, will only have a handful of viable options.
So what are the pros and cons of Django? I’m not well‐informed person to speak about this but, lacking sane information…. As far as I know, Django is not a popular web‐build technology. It’s been out there since 2005, yet you will not immediately find hosts that support it. I’d beware of any host who claims to support Python. Even or especially if you are looking for a cheap host. Multiple web hosts may offer that they support a technology, but that only means they’ve downloaded and installed a few modules. The implementation and support may be lousy. You need a host known to be experienced in Django, for example Python Anywhere. This isn’t an endorsement for Python Anywhere, more a pointer that you need a host who can demonstrate they know their subject.
After that, there are ‘platform’‐type services where, with various doses of utility, the server is abstracted. For the lowest of these, the interface is little different to a slice of server‐space, but with an abstracted base and GUI controls. The more sophisticated platforms have pluggable module systems. Again, make sure the service knows Django. Some may be advertising their capability because the techs jambed in a few modules—however much you want to pay, that’s not enough to guarantee good service or support.
Finally, there is virtual server deployment, where you buy a slice of server, an IP address, and nothing else. Though cheap and versatile, this is a difficult route. However, Django has a clean abstraction and layout, maybe the cleanest layout I’ve experienced. And it can leverage Python’s virtual environments. If these seem like small points, for this purpose they may not be. On a VPS you can become involved in, say, Java technology’s mass of convention (however strong and versatile), or the way PHP technology is bent towards server and architecture (and the mass/mess of permissions). Between the clean abstraction of Django, and the widespread adoption of Python, Django is a good candidate for VPS. I suppose the final comment should be for running your own host. Or home‐servers, or ad‐hoc test server construction. But the comments about that will be much the same as for VPS—Django is a good candidate.
Make sum, not every host offers Python/Django. If a host posts Python/Django logos to the website I’d be suspicious—I’d look for evidence of specialisation, or a track record. That said, Python/Django is versatile for hosting method. Needs dependant, if I needed a powerhouse of a website flying on a Raspberry Pi, Django would be a strong candidate.
Refs
A community‐maintained list of Django hosting providers. Data mostly scraped from hosting providers, not much review, little categorisation, but useful,
VPS deployment, starts with an excellent summary‐list of objectives,
Mozilla notes on deploying to a platform host (Heroku). Enough to make you consider a VPS,
https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Deployment
Admin customisation
Admin can be customised. Like much of Django, the code has a stack of methods, much of them based on real‐world practical requests by coders. These will help you make code the way you wish to.
However, I must give developers a big warning. This warning is only repeating something mentioned in Django documentation, but rather stronger and more direct. It is nearly always impossible to insert new structural elements, such as inputs, or control the workflow, of Django contrib.admin forms. For example, you want to to insert an extra field on a model form because that field is all the user needs to construct a full return, and you would like this input in one place. An example, to upload a photograph at the same time as an article. I’m afraid this is possible but not worth the trouble or the maintenance. Or you want to string two forms together because they amount to a user workflow. An example, join a model about a product to a model about the product’s sales options. If you are wondering why I say this is practically impossible, look at the code for contrib.Admin.options.py. There you will find 2000+ lines of Python, criss‐crossing in intent and features. Yes, this is Python, so you can hack it. No, it is too much trouble to achieve structural effects.
The best you can do with Django contrib.admin is change the look and operation of the forms using the builtin features. This can be frustrating because you may feel that contrib.admin already has got you three‐quarters of the way. But, I repeat, it is not worth your time.
There is another hang‐up. As far as I know, it is not possible to replicate Django contrib styling outside of the contrib.admin app. This means that further custom forms will not display with the same style. If you start constructing your own forms, you are committed to producing a full‐forms solution for the site, even if this often duplicates work that could be done by contrib.admin.
So, be warned. Consider your wishes before you start. Will contrib.admin provide all you need, or can you reduce your wishes so that it will? Otherwise, you will usually need to construct a full forms solution.
Favicon
Favicons are not obvious in Django, as Django works from an abstract folder structure, not mimicing a server layout. Either you must specially target the favicon as a static file, or use a URL. See my article on Django’s webroot. For making favicons, look on the web, or see my article.
Forms
I havn’t covered forms at all. This is deliberate. For site development, you will likely use contrib.admin to get some data, models and views up and running.
With much the same comments as Dango’s Views solution, Django forms can be a difficult subject. I quote myself,
Django has some basic response methods builtin. After that Django moves on to class‐based forms with a very deep inheritance stack. The classes used contain tricky code. The result is usually clean and tidy, but between the brief documentation, the lack of third‐party documentation, and the bristling, tricky classes, it can be difficult to see what you need to do to achieve an effect. If you do not work with Django as a day‐job, you may need to do much work and meet much trouble. You may need to go to source code, and even that is not easy, due to the deep inheritance and tricks like meta‐programming and decorators.
I would note for you that there is third‐party code to help—for example, Crispy Forms. If you feel you can commit to a solution like this, you may be able to save time by committing from the outset. So do check other people’s solutions, and repository code, from the start.
How to get info from the database—the ORM
Because the aim is to get you up and running, I’ve not touched this. But retrieving data can be a huge subject. Django uses an Object Related Management system. I find the QuerySet API reference is where I go, trying to remember or find how some thing or another works. To get results from the database you use lines like,
results = Review.filter(category = 'pies').order_by('price')
That’s all we’ve used, and it’s neat. But if your application needs to use multiple linked tables, you will pass much time here.
Some people don’t like ORMS. They hide what is happening with the SQL, and are often limited. For example, despite continued web queries, and what seems to be a few efforts, the Django ORM will not do a GROUP_BY query. Also, though I think the Django ORM is handy, to me it’s annoyingly Pythonic. I never seem able to write the query I want, the way I want, with the result I want. And the area of foreign and other related keys is, in the way the Django ORM works with models… awkward. Still, there is the other side of ORMs, that they are a systematic, automatic protection against attack. And Django has tools to let you use SQL, if you want.
Like I say, this can get deep. You’ll find plenty of work online telling you about experiences of trying to improve performance while using the ORM. This kind of problem is nothing to do with Django, most ORMs end in a battle with the tool, not work with it.