Kudos to the Django team! Great to see it continue to improve.
Anyone know if there are any plans to update the HTML/CSS for the Admin app? Functionally it rocks, but visually it feels like you're revisiting 2001. I'd LOVE to see it rebuilt based on Zurb's Foundation or Bootstrap. I think we'd see a lot of innovation inside the admin.
Because we want to maintain compatibility with 3rd party admin extensions which often depend on the specific markup, we've had a lot of luck with CSS-only reskinning. The markup really isn't terrible so we've made sure no Django CSS is loaded (just create 0 byte CSS files matching each built in CSS file).
We then add in Bootstrap CSS+JS so we can some of the handy UI components and then our own CSS on top of that.
I would be very much in favor for at least updating to some CSS3 features and refreshing the experience. Tweak some colors and borders here and there, no total overhaul needed.
Yes, there're a few solid projects which do just that. Though it does use GIF's for many of the icons. It's really a very minor issue. Besides, the admin panel should generally be for internal use.
The 1.7 release is another great upgrade to the solid Django ecosystem. Personally I am very much looking forward to native migrations (another step forward from South, which by itself was awesome) as well as some of the new custom QuerySet and Manager functionality.
That said, there seems to be a slight hiccup in third-party apps moving towards 1.7, since those that have existing South migrations are in the dilemma of whether to break backwards compatibility in moving to the native migrations framework. Also there is a nice chunk of deprecated APIs (such as @transaction.atomic) that many projects will throw warnings about now, until those are patched.
Personaly, I've already started migrating projects to 1.7 in anticipation of an upcoming release in the next few weeks.
Where do you see that @transaction.atomic is deprecated? It's not in the release notes[1] and if I recall correctly, was only introduced in 1.6 as a means to come up with a consistent API for nested transactions and savepoints. Are you implying that it's deprecated as a decorator? Even if that's the case, I still can't find a source.
The big addition of the 1.7 is for me the Schema migrations (rework/improvment/integration of South http://south.aeracode.org/docs/about.html). I really like Django, kudos to the team!
Other than being a little confused at first about why it wasn't included by default, using south as a separate module is about as inconvenient as using any other python package that isn't part of the standard library.
For people who know about it, yes. But probably the biggest win from pulling it into core is that, here on in, a newbie will be told to get migrating stuff from the first tutorial they do, and thus get working with this particular best practice up front. Yes, it's always been pretty hard to do django for more than 5 minutes without finding someone urging you to use South, but you never know...
I've always been a huge fan of Django and how productive it feels to build web apps with. In a past life my employer was 100% Microsoft ASP.NET and I wanted to migrate them to Django to save on licensing. I think the Django core is strong enough to stand up to Microsoft.
I used to love Django, but after using it for a couple of years I've got a bit sick of it. The template language is horrible, as is the ORM. It's only redeeming features is the forms framework (only just) and the admin panel. That being said, it's super-awesome for getting a quick demo up or starting a project with unclear requirements.
Edit: Why the downvotes? The templates are slow[1] and restrictive (no function calls with parameters in templates. wat). and the ORM is utter rubbish compared to SQLAlchemy. Django shines because it is convenient (and there is a large ecosystem) - relationships are easy to configure and everything just works together. Which is nice I guess, but it does force you to use all of Django's inferior stuff.
I'm not sure why you'd hate the template language. Its deliberate dumbness can be tiresome, but on the other hand, if you're running into that, it's a code smell. I was sceptical about the whole "designed for designers" aspect of it - but I've had to introduce a couple of people, one of whom isn't a developer, to Jekyll at work, with the Liquid templates which are very similar syntactically, and it's been picked up very quickly.
I keep hearing it's slow, but I haven't had to run at a scale that it's a pain point, so I wouldn't know.
Its deliberate dumbness was a good idea that does not get enough credit. You should not be doing complex logic in the template layer.
I still think it could be made more user friendly for designers, though. We need some sort of app that will autofill django templates' context variables with test data so that designers can see how it all looks and edit them under different circumstances without having to deal with the messiness or state of the system underneath.
The link you posted tell us that Jinja2 templates are way faster than Django's. Well, you _can_ use Jinja2 in Django, and you get the function calls in templates too, so what's the problem?
Using jinja2 is technically possible, but it would be difficult to use other django apps at the same time as they all assume the standard django templates.
Some of the new ORM features in 1.7 are great - and there are some even more cool things planned for 1.8 (a big generalisation of F expressions that will also include more flexible aggregation and annotation functionality).
I like the ORM - the design philosophy is about making the simple things easy and the hard things possible and it think it succeeds at that.
I originally didn't like how you couldn't do real function/method calls in Django templates. It felt a bit like I had my hands bound, very restricting. However as I've used Django more and more, I've come to find keeping all but the most basic presentation logic out of templates makes it easier to write thorough view tests. When you weave a bunch of logic into a template, it becomes difficult to write proper tests. I've found using this "thin" template approach has helped me write simpler and faster code in general. Making this separation, also seems to make it easier to write more generic views and templates. Which helps with maintainability. If you absolutely need to make calls in templates, Django makes it trivial to write custom templatetags, which can be used to do this. They're also easy to test independently, seeing as Django implements this feature with a regular decorator. So templatetags can be called like any other Python function. After using Django quite a bit, I've really come to appreciate how it separates view logic from template logic. It really is the better approach IMO.
The ORM is bad because it is a poor abstraction of SQL. This manifests itself in several ways, the largest being little control over the SQL queries generated.
The poor abstraction really causes problems when you need to do anything beyond the simplest of use cases. To achieve even modest performance gains, you're better off hand writing your SQL. Additionally, doing even the most trivial of trivial aggregate queries will also mean that you're hand writing SQL.
SQLAlchemy is light years beyond the django ORM in this regard.
I think the most important difference between Alchemy and Django is the separation between the SQL abstraction layer and the ORM. There is no separation with django, making it very difficult to really get in there and make changes.
But I don't think this makes the django ORM bad. It is very easy for beginners to get up and running. It is very easy to understand the models and the query language.
As an FYI - 1.8 should make it possible to use .annotate() for constructs that aren't aggregates - like functions and extra select columns. You'll also be able to write more complex aggregates. It should give you greater control over your SQL, removing the need for .extra() in most cases (but not .raw()). It's what I've been working on recently: https://github.com/django/django/pull/2496
>The poor abstraction really causes problems when you need to do anything beyond the simplest of use cases. To achieve even modest performance gains, you're better off hand writing your SQL. Additionally, doing even the most trivial of trivial aggregate queries will also mean that you're hand writing SQL.
This isn't really a big deal - you can just hand-write your sql directly using .raw() and just pull out the corresponding result set and use it as you were doing before.
I've had to do what you're suggesting, but not a huge amount. Maybe 10-15 times on large, high scale projects.
SQLAlchemy is better but the number of times I have to break out of its abstraction layer are not enough for me to feel like I really have a desperate need to use alchemy instead. It's a minor inconvenience, nothing more.
It's got better. When I first started using it you couldn't bulk save objects, each save was an individual query. It also loves to make lots of queries, especially in templates. I guess my true dislike stems from using SQLAlchemy, and realizing how awesome it is compared to Django's ORM.
I do love the relationship stuff - making a m2m field is super easy and it just works. Also manager/queryset extensions are super easy.
I haven't actually used SQLAlchemy, but I know it has a lot of features that would be extremely useful for django. I really like how it separates out the Core and ORM components.
I prefer djangos syntax for composing queries and defining models though.
The common criticism I hear is that it can't do everything, unlike SqlAlchemy. Fair enough, but the Django ORM is no doubt simpler to use than SqlAlchemy.
SQLAlchemy is designed for people who know SQL already and want a safe and convenient way to use it from Python.
The Django ORM is designed for people that want their Python data objects to be persisted to a back-end data store.
Both of these things have their place. The problem with the Django ORM is sometimes you need to do something slightly more complicated than what it supports and your back to raw SQL. These scenarios are really common, 90% of Django project have raw SQL in them.
SQLAlchemy uses the data mapper pattern whereas django ORM uses active record - that's the main difference. Neither one is really 'better', there are advantages to both approaches:
The main advantage to django ORM in my opinion is 'less code', although it does create an excessive coupling between your persistence / model layer. Whether that is something you can live with or not is up to your project's requirements.
I'm pretty happy to work with both. Just don't make me use RoR!
I've got to disagree with the 90% figure. The vast majority of projects I've seen (which are typically pretty straightforward from a data modeling perspective) rely only on the ORM.
LOL. Which is one of the huge benefits of Django, IMHO. You can slam the speed of template rendering and the ORM all you want, but in the Django tutorial the first thing you do is use the framework to model data and display it to a user.
The Pyramid tutorial has you sending responses to the browser, which is so low-level I would hope the framework is more flexible than Django.
EDIT: While I'm responding, I'll also note that if you're running into speed issues with your templating language, you've waited too long to setup a decent caching layer. (Hello, Varnish)
I agree with the general sentiment of this comment. I strongly believe that Pyramid is a "graduation" framework.
Once one is past the honeymoon period of Django, for non-cookie cutter projects, Pyramid's very well suited for that "advanced" project where you find yourself fighting Django.
django templates have gotten a lot faster in the last few years + plus is you think they are just slow, why not push everything to the client using a front-end MVC - everything is going that way anyways.
I think that is a bit of confirmation bias. Client-side rendering has definitely garnered a lot of attention lately, but that doesn't mean that everyone has simultaneously stopped doing server-side rendering
Yep. There are times when server-side is the right thing to do (mainly content-based sites - especially if SEO and accessibility are major concerns) and times when client side is (SPAs and the more 'app-like' end of the spectrum).
Writing a template in one go, all in one file, is still vastly easier to wrap your head around than writing all sorts of different components in JavaScript and then gluing them together. There's great JS templating frameworks, but I don't see why anyone would use them unless you really have to, e.g. for data binding / dynamic changes to the DOM.
I'm really curious why you say that? Certainly it seems to me there's enough downsides to client side rendering still that I can't see how it's that clear cut.
Well, restricting the server to basically providing a REST API for client code is basically the dominant way of doing certain sorts of applications, particularly those that may have web and native implementations and so forth.
Some of us, however, make websites. We generally render our HTML server side. And Django templates are as good a way as any other (leaving aside speed concerns).
They are hard to compare, a completely different mindset. They are minimalist frameworks while django tries to be a more complete framework. Each one excel at their goals in my opinion.
A bit offtopic, but I was wondering what some good books/resources for learning django are? I've mostly been using rails or sinatra for web stuff, but planning on doing a project that I want to host on GAE and write with django and django rest framework.
Do not use Django with GAE. Really pointless to do this. You are better off with Frameworks like Flask with GAE in my experience. To get the full benefit of Django you really need to avoid GAE in my opinion
This project is pretty great for using Flask on App Engine: https://github.com/gae-init/gae-init - I've been using it for a while now, and it's been smooth sailing. Also, it's actively maintained and continually improving.
The big issue is that Django's ORM is built around traditional relational databases, while Google App Engine is not. You can certainly make the two work well enough together if you know what you're doing, but for someone just getting started, it's an unnecessary exercise in frustration.
If you want to use GAE, I recommend just starting with web.py or whatever is the default framework there. It's fairly easy to learn. If you need a place to host Django, a good chunk of the Django documentation is dedicated to discussing how to do that. There's also Heroku and what not as well.
While not being able to use Django's ORM (or admin) is frustrating, you can still use Django's API, like routes, middleware, templates, forms and so on. That's far from useless and Django on GAE is actually as default as it can get.
I actually have an older project made with Django for GAE. Haven't updated it and haven't tested it in a while, but it should still work and one might find it useful for inspiration: https://github.com/alexandru/TheBuzzEngine
Totally agree with Andrews reply. And this is just one of the annoyance. Even simple things like uploading a file to GAE will present you with new unecessary challenges.
One thing though, you can use the Django Orm on GAE if you are using Google Cloud SQL as your database instead of the data store that GAE comes with. This will prove more expensive for you though.
I haven't looked in a long time, but it probably works well enough. My point is that much of the "batteries included" aspect assumes a relational database. See, for example, the caveats django-norel makes with respect to the bundled admin interface (http://djangoappengine.readthedocs.org/en/latest/admin.html). I suspect there are implications for the built-in user authentication and permissions app as well.
That's not to say this isn't workable -- it's just that a lot of the Django plugins, tutorials, and documentation out there will be far less useful to you if you're starting with GAE.
I've been using the Django dev version (1.8) for a personal project for a while now. I really like the built in migration framework, which is available from this release (1.7). I think it's even easier and cleaner than South! Also the documentation is very clear (as always).
There's just two commands [0]:
makemigrations - to create migrations
migrate - to (un)apply migrations
Adding migrations to an existing app is just running the `makemigrations` command for that app [1]:
python manage.py makemigrations your_app_label
It will create a migrations/ folder in the app folder and you're good to go. When you change your models and run `makemigrations` again, it will make migrations for the changes you made and you can apply them with the `migrate` command. For migrations that can't be detected automatically (like renaming models/fields) you can create an empty migration file (by supplying `--empty` to the `makemigrations` command) and edit the migration file yourself. With the great documentation this is easily done [2].
They also support data migrations (migration for the data in your database instead of the scheme of the tables). So I think it replaces pretty much all features of South. BTW, the original creator of South (Andrew Godwin) helped create the migration framework in Django, so no hard feelings ;).
Unfortunately AppEngine only includes django up to 1.5 I don't know why they take so long to update their Third Party libs.
Of course you can include the lib yourself in the project but that's a burden specially with large apps because you get restricted by the number of files you can upload, so adding large libs is not the best world.
Not unless you run into a library incompatibility with Django 1.7 (specifically, custom FileField's come to mind).
If you have few dependencies other than Django, the upgrade from South should be fairly smooth. You essentially start your migrations from scratch: Delete the South ones, let Django re-generate migration 0.
If I were to summarize Django: it's a godsend for new comers (the whole package is fabulous & comprehensive with excellent documentation). It'll get you to your destination fast & in style. But very soon, as you start getting a hang of it, you'll realize that it's rigidity is wearing you out. I wish there's a django-light fork that takes all the good things in it and mashes it with jinja2 & SQLAlchemy.
Please make it a lot more modular. Maybe a kickstarter (like South did & Postgres improvement is doing)
P.S. I know there's flask, but it's still a while before it reaches that point for some of us.
More modular? I think how modular it is, is one of Django's greatest strengths. Don't like django's templating? You can be up and running with jinja2 in less than 20 lines. Don't like Django's user model? Substitute your own, or if you just need a different auth backend, write your own. Have a desire to use a less common DB? Write a db backend. As far as trashing the ORM for SQLAlchemy, there are a number of django packages that aim to do just that.
There is a small number of ways I could imagine Django being MORE modular.
You're free to use Django without the template language - that's a relatively simple replacement and one we're looking into making even easier.
The ORM/SQLAlchemy is a more difficult issue. To some extent, Django _is_ its ORM, and making that modular is extremely difficult. You can remove the ORM, but you'll obviously lose everything on top of it - admin, migrations, generic views, etc.
I personally believe that while the ORM is not as configurable as SQLAlchemy, that's one of its strengths; having a relatively fixed target makes writing things that rely on it a lot easier (migrations would have been much harder given SQLAlchemy as a base, for example).
I'm pretty sure Flask is as robust as it's going to be. Flask is Django without all the batteries included, which is what you're asking for. Throw Jinja2 templates in there and SQLAlchemy for an ORM and that's exactly what you're after.
Now, if you want views and middleware too, well that's core Django and you probably want django as well.
One common theme I'm hearing is that individuals want a "way to grow big" but with the ease of getting started quickly while having an extensive ecosystem.
Flask was written on top of Werkzeug as an example of how to build a "roll-your-own" web framework. It has a few shortcomings, but overall, it's OK and you can contour it to whatever you need done. After all, if Flask starts to "wear you out," you can always graduate to just Werkzeug.
I think there's an opportunity here for something like this to be built on top of Pyramid, which I've found to have a very extensible API. The main problem with Pyramid is the perception to newcomers - there is more than one way to do it and it doesn't have any opinions on how you should go about doing something. It leaves it up to your imagination. There's a slight trade off here between an opinionated framework and the extensibility of Pyramid.
I think the problem with not being opinionated is that 3rd party libraries have nothing they can rely on. Do you write 3 sets of templates for the 3 most popular templating libraries? Do you provide models for SQLAlchemy AND Django? Or do you pick your combination of dependencies, and let someone else reimplement your library with a different combination?
That's where I think Django shines. It might not have the best templating library, ORM, or routes frameworks. But app developers and library developers know exactly what they have to integrate with. This encourages a better ecosystem.
I've been using Django for about ~2 years. I haven't found it to be too rigid at all. And for the few situations where I've really needed to implement something novel, I've found working with Django to be an absolute pleasure. There's hooks to easily extend things in all of the right places. Django's source as a whole is very well written and documented.
I love Python's batteries included philosophy. It's nice not to require 500+ dependencies just to write a simple fizzbuzz. It's really nice to see Django take this to heart.
I with Django would add the south project to their core. It seems like an enormous oversight that you can't change data models after you sync them to the DB for the first time without deleting all the data or using a 3rd party app (south).
EDIT: I need to read things more carefully. My bad. Good job Django.
There's a bunch of awesome new features in this release. The new `QuerySet.as_manager` method permits using the same code for both custom querysets and model managers. No more hideous code duplication. I don't know how this https://github.com/django/django/blob/stable/1.6.x/django/db..., ever meshed with Django's DRY philosophy. There's also the new `Prefetch` class, which allows for more sophisticated prefetch queries (more than just model.related.all()). Though the new migration framework is definitely the star of this release.
As I understand it, the smallest run they can do is 20. So if you can find 19 other people who missed out, they could run another campaign. I'd guess Russell Keith Magee or someone else from the DSF would be the one to bother about it.
I'll save you the suspense - we've run the campaign twice, and we're not going to run it again. Part of the sales gimmick was that it was the limited availability.
But, fear not - given the success of the campaign this time, I think it's fair to say that when the time comes, there will be a Django 1.8 release shirt.
I bought one but ordered too small a size so I'd be in for purchasing another if someone were to make this happen. It's a nice shirt and I want one that fits!
Where do Django stand in the js everywhere fortresses of MEAN and damn awesome stuff like meteor/derby? I mean it's possible to use django with client-side js, precompiling js templates server side and using Django as REST backend or use websockets layer on it and do stuff the modern apps should (arguably) be doing i.e refresh-less UX, fast native-like apps, but still these major server-side frameworks (django, ror and friends) are so much loved and used by vast majority of "pros".
Most likely I am living in a bubble that making apps same language both sides specially in frameworks like Meteor which revolutionises the workflow is the best way to go.
Please break my bubble and enlighten me why we should still be using these framweworks and not js only alternatives.
I don't mean to start a flame war (or may be I do), I just want my perspective changed. It is sitting pretty stubbornly in my head that meteor like start-to-end pipelined flows are the way to go (read all-sides javascript frameworks).
If you find using the same language in the browser and the server to be a compelling advantage, js is your only option. But IME it's not actually that big an advantage; most logic code belongs to one layer or another. For domain objects (i.e. non-logic code) you can use something like protocol buffers and then you can use the same object definition in both languages.
Advantages to me would be much more mature ORM support (e.g. others are talking about how good the migrations are; there are some cool efforts in js e.g. Knex but they're still very primitive in comparison to what Django can now do automatically), better templating (certainly arguable, but I find none of the js approaches encourage proper separation of markup and logic), and a much more comfortable language for writing business logic in. Python has nowhere near as many "gotchas" as js, and is much more readable for a less-technical domain expert.
You can easily do this with Clojure/ClojureScript too. As I understand it, it's also possible with Haxe. Theoretically, you could do the same with Ruby or Scala too (not sure I've heard of other languages with reasonably complete implementations that can handle both compile to native code (or a fast interpreter) and compile to javascript).
A huge plus is being able to use Python. I'm not completely anti-javascript but given the choice - I'd rather use Python for the bulk of my application logic. I'm sure Ruby people feel similar. As great as the strides in js have been, it's just not as nice a language as many of the alternatives.
I dont agree on this point. Javascript has quite a many gotchas i agree, but once u get over them, javascript is a pretty beautiful language. I've been a pythonist before getting into js about 4 months ago, i still love python but the flexibility js provides is unmatchable. Even python cant beat it.
I'd love to here some specifics here. I've never heard anyone call javascript beautiful before. I don't mind js, but please let me know what flexibility js provides that is unmatchable.
I am no expert of Python or Javascript, but here's some of what I love in javascript
* first-class functions
this is the first thing anyone would fall in love with when coming from Python. Python do treat functions as first class, but Python follows OOP way more strongly and functions in Python never get that level of authority as they do in javascript. Ability to define anonymous and named functions anywhere, immediately executable, fully or partially is a huge plus.
* highly dynamic: monkeypatch anything anywhere
Javascript is highly dynamic, you can override almost any property of almost any object anytime in the timeline. This opens room for all sorts of hacker. Like I worked on a fairly complex Meteor application and we needed to modify the behavior of some core meteor methods. No, using them through a proxy wasn't a possibility as we wanted to change how the app behaves overall. How would you do it? Fork meteor and roll out other version? No. Just overwrite the functions on Meteor at right time in the timeline. I know it's more hacking than engineering, but not all hacks hurt.
at many places we would intercept the objects being created in one part of the framework that would go to another for further processing and do shit load of operations on them half-way to make them work as we want (like temporarily turn mongodb cursors to model (in MVC terms) like interfaces which are more easier to work and reason with), and then forward them with original interface, properties changed to processed values.
* prototypical inheritance
I like the way javascript does inheritance. Or how we force it to. The prototypical ladder cause many problems but it also open doors for many interesting solutions which won't be that easily achievable in other languages.
* fun of writing code
Once you grok the fact that js is a functional language, accept it and start using it like a functional language, javascript is tons of fun to write. I mean you won't miss (m)any python features if you sue javascript as a functional language and make use of the functional abstractions provided by several js libraries. Just using underscore makes a huge difference.
* flexibility and extensiblity
reading prototype.js code blew my mind. You can beat, bend and extend js in whatever way you want.Yes there are several gotchas (some of the language itself and some because of browser implementations), but despite of that what javascript has to offer is remarkable. I was intrigued to read prototype by js ninja book, and it is indeed mind blowing for someone new to js like me. I am looking forward to desiccate javascript libraries which provide highly functional interfaces and macros. Ability to serialize (almost) any function and modify it and then execute at the runtime opens room for innovative solutions (and all sort of sorcery/hackery).
* freedom
python is quite liberal, but javascript takes it to another level in terms of what you're allowed to do with your code. I don't know how to express it with words, and I don't know how you can not feel it when doing a js project.
In some ways Python is more liberal but in different areas - Metaclasses, 'magic' methods (hooking into __getattr__ allows some very clever behaviour), operator overloading, control of the abstract syntax tree and doing crazy stuff with imports. Try doing some of that in javascript.
Monkeypathing? Nothing forbids it other than a sea of raised eyebrows if there was a cleaner way to achieve the same thing.
The only limitation Python has with first-level functions is that they can't be anonymous. I know a lot of people chafe at this but I've never seen any javascript code that wouldn't be improved by removing a couple of levels of nested anonymous functions ;-)
I think it's the extreme level of flexibility I dislike about javascript. Even Ruby is a touch too malleable for my tastes.
For me it's about hitting a balance between readability and brevity and having clear community norms so that other people's code is immediately comprehensible.
There's just Too Many Ways To Do It in javascript.
I'd be very interested to know what flexibility you think javascript provides that python doesn't. I have nothing against JS (I usually enjoy writing JS), but IMO it doesn't begin to offer anywhere near the functionality or beauty that python does.
I'm not interested in language wars, just genuinely curious about your statement.
Anyone know if there are any plans to update the HTML/CSS for the Admin app? Functionally it rocks, but visually it feels like you're revisiting 2001. I'd LOVE to see it rebuilt based on Zurb's Foundation or Bootstrap. I think we'd see a lot of innovation inside the admin.