Django 1.7b1 released
djangoproject.com
djangoproject.com
https://www.kickstarter.com/projects/andrewgodwin/schema-mig...
Maybe this is the way to get solutions to unsexy problems....
Is it more sensible to regard Django (and Rails and other frameworks from that generation) and the node ecosystem as complementary rather than competitive at this present time? i.e. to use Django for the content-heavy parts and run node alongside it for the more app-like or real-time aspects?
And is this likely to change over time?
(please - don't let this prompt another micro vs macro framework debate or a discussion on Django being 'too big' - save that for another time)
That said, it also comes with the baggage of the Python ecosystem. You're not going to find any support for async stuff like node (you'll depend on message queues for async stuff, but frankly there are really nice options out there), and you're not going to find anywhere near the amount of experimental projects. Django is used to solve the use cases of web developers that need to deliver.
I would stay away from it if you definitely need high performance or concurrency, but I have not seen many things comparable when it comes to well-engineered, pretty, and functional CRUD apps. Do not underestimate the difficulty of building those.
That said, it isn't too difficult to hack something together. Kenneth Reitz did a nice little project for Flash websockets that I like: http://kennethreitz.org/introducing-flask-sockets/
Python 3.4 has that nice ayncio module built in. I'm hoping it'll be a big draw for people into Python 3.
I've not found anything in the Node.js world that's as nice as Django's models to sit down with and model the data and relationships required for whatever you need to do and play with it in a REPL as you do so, or kick off an admin config to get the data working before you touch a line of request-handling code. It's a similar story for things that are built on top of django.models, like its auto-admin, or much of the ecosystem of django-* libraries. I couldn't leave django.forms behind, though, so I ported it to JS :)
In terms of your everyday handling HTTP requests, it's much of a muchness. Request objects, response objects, get some data, render a template, you know the drill. It's never going to feel the same as Python & Django, but you can comfortably write the sort of apps you write with Django in it, as long as you're down with the asyncness. If anything, certain parts can be even stronger - Jade templates, IMO, make it even more convenient to to do Django-style template inheritance, while its mixins make it much easier to extract reusable chunks of markup + logic without having to step outside templates. You also have the option to reuse templates - and other pieces which support the whole "isomorphic" thing - on the client side , but that not might be the sort of thing you need to do.
As ever, "it depends".
The default branch is currently focused on using it with React to add client-side interaction and using React's server rendering - master (0.4.2) can be used for rendering and validation anywhere, though.
If you're being drawn to Node because of real-time stuff, though, I personally would suggest a mixed architecture. I'm a fan of using Django for the conventional stuff and then something else alongside it for real-time. You can use a reverse proxy in front to make the services appear to be unified.
With Django, the quick test runs and startup were wins (although Grails mitigates that a bit these days), but I thought Django's organization (or lack thereof) was a confusing mess and dealing with forms was an exercise in bending the API instead of working with it.
The forms API is, granted, not super easy to work with initially, but its abstractions are really powerful and bending them to your will is trivial, because everything is overridable.
I will safely assume that as a beginner I was missing some part of the puzzle, but I was never able to track down a good way to do it. Oh well.
It took me a while to get a solid handle on them, but Django usually does forms very well. The best case is that your UI requirements are fairly loose, otherwise it's likely you'll end up with mostly-custom HTML, but even then you still have the potential to save a lot of Python code with things like ModelForms and/or FormViews.
Crispy forms: http://django-crispy-forms.readthedocs.org/en/latest/
Floppy forms:http://django-floppyforms.readthedocs.org/en/latest/
If you're using a lot of code to generate forms that depend on models, look into ModelForms: they allow you to generate a form that maps to a specific model's fields trivially and allow adding additional validation and persisting the model to the database.
There is the package wtforms, however, which I've found is more pleasant than django forms.
- Form. ModelForm? Formset. Inline formset? Model Formset ... ? Jesus I just need data POSTed back. Why must I use your management_form when you don't also give me the JS to ... manage it?
- ModelForm._meta knows it's app_label, why doesn't a regular Form
- 200-line migration files are just not fun to grok.
- ID based migration file names are a pain when multiple devs are involved (Rails / SQLAlchemy solve it using timestamps / SHA1s. South closed it as a wontfix years ago)
- Having a user model you're not supposed to touch
- urls.py gets way too disconnected from what they are actually routing to
- managing 'apps' is silly, making a new directory in python gives you just about the same advantages.
- if request.method == 'POST': ...
- The `class Meta:` pattern.
SQLAlchemy is the better ORM for python. Jinja2 is a similar template syntax but with better performance. WTForms are easier to work with than Django forms. Tastypie also makes a lot of dubious decisions.
I just really don't see where this framework fits in.
Because Js stuff belongs in the frontend? Django very explicitly does not do frontend logic.
> ModelForm._meta knows it's app_label, why doesn't a regular Form
Because ModelForms depend on models which depend on apps to function properly. Forms are just plain old classes.
> 200-line migration files are just not fun to grok. No, but they allow the migrating class a lot more flexibility by letting you access the ORM within a migration with no concerns about what your current models files look like.
> Having a user model you're not supposed to touch 1.5 and on have pluggable user models. Prior to that most of the important stuff was highly overrideable.
> urls.py gets way too disconnected from what they are actually routing to
That speaks more of the issues with your routes rather than what the framework allows. There are a few well-established patterns which make the routing no less clear than any other framework.
> managing 'apps' is silly, making a new directory in python gives you just about the same advantages.
Then you're not understanding what a Django app actually is and how it differs from a regular module.
> if request.method == 'POST' As opposed to?
> SQLAlchemy is the better ORM for python. Jinja2 is a similar template syntax but with better performance. WTForms are easier to work with than Django forms
Seriously, these are non-issues, they have been touched upon dozens of times, and you clearly have not used the framework's integration capabilities sufficiently to understand its strengths, so either use something else or learn to leverage its unique advantages.
The problem with Django is two-fold: the docs are very good but you need to know Django to be able to find the things there
Also, Django is "magic" but less magic than people think and sometimes you need to go beyond the "public API" to do what you want (it doesn't mean you're piercing the API, but it is more grained than you think)
And sometimes of course the API is faulty and you have to work around it (like password reset emails that are text only and is being fixed in 1.7)
Is there a good guide for going from 1.4 to 1.6?
Just take a look at the backward incompatible changes in both sets of release notes to get an idea of how the migration will affect you. There are lots and lots of nice improvements in 1.6 and especially 1.7 that you may be interested in.
https://docs.djangoproject.com/en/dev/releases/1.5/
Also, remember that when 1.7 is released, 1.4 will no longer received security updates, only 1.5 and 1.6 will.
However, this is only security updates, not necessarily bug fixes.
[1] https://docs.djangoproject.com/en/dev/internals/release-proc...
Having recently upgraded two production projects from Django 1.3 to 1.6, I'd say YMMV but it likely isn't. Go public unless you have someone at hand with enough eagerness and knowledge of the codebase to do the migration quickly so you don't have to postpone the release.
The migration itself is no big deal, as others pointed out—you just make a checklist of backwards-incompatible changes and walk/grep through the codebase for every item. I don't think any DB schema migrations were required. Took me two days a project, not counting manual testing afterwards (unit tests were there, which is convenient but can't guarantee that everything will work).
The process is not very exciting, though. It helps when codebase is stable and you have the time to go through it without rush and make sure everything works for some time after deploying the upgrade to production (being ready to roll back quickly). That's also why I'd suggest going public and leaving Django upgrade for later, when things calm down a bit.
1. How many 3rd party apps are you using? Be especially wary if the a) perform any clever black magic on Django internals or b) are only lightly maintained and the job of updating them might fall to you.
2. Do you have a decent test suite?
Beyond that it was pretty straight forward, but it really helps if you have good unittests to begin with.
Do the upgrade. Just read the release notes for every release between the versions you are going through and make sure to make the changes they suggest/require. It'll take you 2 hours and yes it is worthwhile.
My main interest in porting my 1.3 Django App to a newer version is to get Python 3 support.
Does anyone here run Django on Python3 and care to share the experience?
[1] https://docs.djangoproject.com/en/dev/topics/python3/
[2] https://docs.djangoproject.com/en/dev/releases/1.7/#python-c...
while the package is on: https://www.djangoproject.com/m/releases/1.7/Django-1.7b1.ta...
https://docs.djangoproject.com/en/dev/topics/migrations/#upg...