Django 1.7 RC1
djangoproject.com
djangoproject.com
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.
[0] http://grappelliproject.com/ [1] https://github.com/sehmaschine/django-filebrowser
https://github.com/django-admin-bootstrapped/django-admin-bo...
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.
Both are trivial to set up and install.
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.
Kudos!
It's better to have it built in, sure, but it wasn't a nuisance before.
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.
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)
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.
Most of the default building blocks are very sensible and if you need to decouple them (in extreme use cases), it's not that hard.
Here's a gist I made the other day demonstrating this. https://gist.github.com/jawnb/cd7a899cac5300c01709
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.
Don't take just my word for it though, here's a talk Alex Gaynor gave saying the same things. https://www.youtube.com/watch?v=GxL9MnWlCwo
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
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.
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.
http://russellscottwalker.blogspot.sg/2013/10/active-record-...
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 do love the relationship stuff - making a m2m field is super easy and it just works. Also manager/queryset extensions are super easy.
I prefer djangos syntax for composing queries and defining models though.
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).
PJAX is a great compromise between the two approaches: https://github.com/jacobian/django-pjax https://readthedocs.org/projects/django-easy-pjax/
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.
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.
Pyramid, Flask, and Bottle are all better alternatives.
Pyramid + SQLAlchemy + Alembic (migrations) + Deform (...forms) + your choice of (jinja2/mako/etc) == happiness
It's good, and certainly better than most frameworks out there, but better? I don't think so.
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.
There's just two commands [0]:
makemigrations - to create migrations
migrate - to (un)apply migrations
python manage.py makemigrations your_app_label
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 ;).
[0] https://docs.djangoproject.com/en/1.7/topics/migrations/#two...
[1] https://docs.djangoproject.com/en/1.7/topics/migrations/#add...
[2] https://docs.djangoproject.com/en/1.7/ref/migration-operatio...
A friend recommended: http://www.amazon.com/Two-Scoops-Django-Best-Practices/dp/09... but looking for other recommendations as well.
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.
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 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
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.
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.
https://developers.google.com/appengine/docs/python/tools/li...
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.
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.
There is a small number of ways I could imagine Django being MORE modular.
Now, if you want views and middleware too, well that's core Django and you probably want django as well.
What parts of it see too rigid to you?
https://www.youtube.com/watch?v=aFRH-oHcbn8
slides: https://speakerdeck.com/jacobian/django-minus-django-djangoc...
if you take time to really look into it, it's pretty modular...
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.
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.
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).
It's been eight years now and I haven't got worn out. When should I expect that feeling?
EDIT: I need to read things more carefully. My bad. Good job Django.
They even made a t-shirt[1] punning on it.
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.
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).
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.
* 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.
You want prototypical inheritance? Here you go: http://tobyho.com/2009/05/23/prototype-inheritence-in/
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'm not interested in language wars, just genuinely curious about your statement.
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.