Django for a Rails Developer(uswaretech.com)
uswaretech.com
Django for a Rails Developer
http://uswaretech.com/blog/2009/11/django-for-a-rails-developer/
8 comments
Actually i would prefer it if models do most of the major work. And views to convert them into a format suitable for presentation. Sometimes that not possible, but it just feels cleaner and more manageable if it is.
Actually, if you apply the MVC paradigm, the Django View is a mix of View and Controller. Admittedly a little confusing
Hence, it is defined as MTV.
Sometimes I wonder if they renamed the pattern just to keep up the music theme...
Same here - MTC would have been simpler to understand for me.
but Google thinks its MVT.
http://www.google.com/search?q=django+mvt
http://www.google.com/search?q=django+mtv
http://www.google.com/search?q=django+mvt
http://www.google.com/search?q=django+mtv
Perfectly stated. I still have the piece of paper from a couple of years ago where I drew this out (I'm both analytical and spatial/visual), and my holistic diagram looks just like what you wrote.
At the risk of being negative, I think the real issue is that the extensive documentation is geared more towards designers than hackers.
At the risk of being negative, I think the real issue is that the extensive documentation is geared more towards designers than hackers.
I am far far away from being considered a designer and I consider the Django documentation to be excellent for programmers. Just because it also caters to designers, the documentation is not necessarily watered down.
A perfect tl;dr.
"Why not create a ‘templates’ directoy and a ‘base.html’ either in project’s directory or in the apps’s directory, because creating the same templates directory and same base.html for every project is not DRY?"
There's nothing wrong with that. Even the djangoproject.com website does it: http://code.djangoproject.com/browser/djangoproject.com/djan...
"Why serving static files in development has to be a additional setup, as no developer wants to setup a server for serving static files, I am aware of ‘django.static.serve’ but still that is an additional setup, why not create a sample media directory and a url for the same in urls.py ?"
Read this: http://www.b-list.org/weblog/2008/jun/23/media/
There's nothing wrong with that. Even the djangoproject.com website does it: http://code.djangoproject.com/browser/djangoproject.com/djan...
"Why serving static files in development has to be a additional setup, as no developer wants to setup a server for serving static files, I am aware of ‘django.static.serve’ but still that is an additional setup, why not create a sample media directory and a url for the same in urls.py ?"
Read this: http://www.b-list.org/weblog/2008/jun/23/media/
The question is, why not the framework create it automatically ?
why one has to create it manually every time a project/app is created ?
Atleast a default template directory and a standard base.html on a project level will reduce the repetitive work.
The question is, why use the framework to create the layout of project which happens to depend upon that framework at all? Instead, use a generic project templating tool to create the layout, then it's easy to choose alternate starting points depending upon what you need in your project. In Python, 'paster' is commonly used for this. It lets you create projects that depend upon TurboGears or Zope or Plone or Grok or even plain old Python projects which don't depend upon a full framework.
You're right that it would be easier if some things were set to a reasonable default.
But if you want it right now: create a custom command to do it your way and wrap it in an app that you add to the path. When you start a new project, the first thing you do is add the application to your installed apps and you can use it over and over again.
But if you want it right now: create a custom command to do it your way and wrap it in an app that you add to the path. When you start a new project, the first thing you do is add the application to your installed apps and you can use it over and over again.
I work with Django for a living but the lack of init/buildout in a new project has always driven me a bit nuts, I guess it's one of my development pet-peeves.
I've never had project that didn't need:
- a project-wide templates/ directory - media/[css|img|js] directories - some kind of database setup by default - contrib.admin (well, I created a form mailer once that had no admin)
Django seems to take a "we don't want to force you to use any particular setup" stance, but the result seems to be to force you to make a bunch of relatively meaningless decisions before you can start writing code. (they could have other reasons, I haven't looked into it lately)
These days I have a script that does all this, and I know others have written similar scripts as well. It just strikes me as being a gaping hole on the Django development model... IMO anyway.
I've never had project that didn't need:
- a project-wide templates/ directory - media/[css|img|js] directories - some kind of database setup by default - contrib.admin (well, I created a form mailer once that had no admin)
Django seems to take a "we don't want to force you to use any particular setup" stance, but the result seems to be to force you to make a bunch of relatively meaningless decisions before you can start writing code. (they could have other reasons, I haven't looked into it lately)
These days I have a script that does all this, and I know others have written similar scripts as well. It just strikes me as being a gaping hole on the Django development model... IMO anyway.
And your script probably sets things up differently from everyone else's :)
But if you think it's a problem, why not publish whatever you use and encourage others to use it as well?
(also, FWIW I don't have such a script -- a new site at work always simply inherits default settings from other stuff, and those defaults are set up to match how our production servers work)
But if you think it's a problem, why not publish whatever you use and encourage others to use it as well?
(also, FWIW I don't have such a script -- a new site at work always simply inherits default settings from other stuff, and those defaults are set up to match how our production servers work)
> And your script probably sets things up differently from everyone else's :)
I don't doubt it. Much like how there is the occasional "this is how I handle managing multiple settings for different systems" blog post, people have come up with their own systems because Django provides none.
> But if you think it's a problem, why not publish whatever you use and encourage others to use it as well?
http://github.com/tvon/django-gig
Written for personal use, so...
There is also "create project" or "project template", I forget the exact name, but it's on bitbucket or github... and "paster" from zopeskel seems to have potential to do something like this but it may be too zope specific, I don't know.
There are ways to do it, but IMO it's something the framework should be handling. As it stands, "basic setup and configuration" is a much higher hurdle in Django than it is in Rails.
> (also, FWIW I don't have such a script -- a new site at work always simply inherits default settings from other stuff, and those defaults are set up to match how our production servers work)
Well, you don't have a script that builds things out in a certain way, but you have a system in place that handles project defaults.
I don't doubt it. Much like how there is the occasional "this is how I handle managing multiple settings for different systems" blog post, people have come up with their own systems because Django provides none.
> But if you think it's a problem, why not publish whatever you use and encourage others to use it as well?
http://github.com/tvon/django-gig
Written for personal use, so...
There is also "create project" or "project template", I forget the exact name, but it's on bitbucket or github... and "paster" from zopeskel seems to have potential to do something like this but it may be too zope specific, I don't know.
There are ways to do it, but IMO it's something the framework should be handling. As it stands, "basic setup and configuration" is a much higher hurdle in Django than it is in Rails.
> (also, FWIW I don't have such a script -- a new site at work always simply inherits default settings from other stuff, and those defaults are set up to match how our production servers work)
Well, you don't have a script that builds things out in a certain way, but you have a system in place that handles project defaults.
Also note that the default Django template is showing it's age. I don't think it's ever been updated and it contains a few faux-pas to look out for. In particular, it starts you off inside a python package (__init__.py file), which is highly confusing. If you later want to treat your Django project as a normal Python project, you need to create a setup.py file. But this file would be one directory up from the project directory ... which is outside of your Django project. Django puts the directory one level up on your PYTHONPATH to compensate for this, with the assumption that part of your project lives outside of version-control, etc. The solution is to remember to put the directory above the directory that the project lives in version-control and treat it as part of the project. Although then you have to put a library location on your PATH to run the manage.py commands, since this file won't work if placed in your projects /bin directory.
(Speaking of /bin directories, it's always bugged me that Rails renamed this directory to /scripts ... if it's executable, it goes in /bin, it makes no sense to split executables based on arbitrary implementation details)
(Speaking of /bin directories, it's always bugged me that Rails renamed this directory to /scripts ... if it's executable, it goes in /bin, it makes no sense to split executables based on arbitrary implementation details)
Well, to be perfectly honest I almost never use the 'startproject' or 'startapp' commands. When I'm working on a new app I just create the directory and an __init__.py, and then start filling in specific files inside it as I need them.
For stuff at work apps all go into one of a couple particular namespaces, so packaging concerns don't come up there; for my personal stuff the package name is almost never the same as the app anyway (e.g., django-registration provides an app in a module named 'registration').
Also, I'd really really like the concept of the project to die soon.
For stuff at work apps all go into one of a couple particular namespaces, so packaging concerns don't come up there; for my personal stuff the package name is almost never the same as the app anyway (e.g., django-registration provides an app in a module named 'registration').
Also, I'd really really like the concept of the project to die soon.
The most annoying part about doing Django as a dev coming from Rails is the RequestContext that isn't used by default, if you want to access specific contexts like settings. Then it means having to hack it using direct_to_template or writing a decorator.
It's a different philosophy, but it's hard getting use to having to explicitly spell out everything when I just want to get going with defaults that make sense.
It's a different philosophy, but it's hard getting use to having to explicitly spell out everything when I just want to get going with defaults that make sense.
"Why serving static files in development has to be a additional setup, as no developer wants to setup a server for serving static files, I am aware of ‘django.static.serve’ but still that is an additional setup, why not create a sample media directory and a url for the same in urls.py" - Because typical deployments don't use django for serving static files?
however typical developments do, and this question is about typical development setup
Agree. What we probably need is a nice way to switch between deployment/development setups, possibly by splitting settings.py like rails
the usual trick is to use a local_settings.py.
put all of your environment-specific variables in there, and put 'from local_settings.py import *' at the end of your settings.py
put all of your environment-specific variables in there, and put 'from local_settings.py import *' at the end of your settings.py
Seems like Django is more comparable to Sinatra? And is 4 spaces the python way? I like my font big and my lines short.
> And is 4 spaces the python way?
It is, see PEP 8: http://www.python.org/dev/peps/pep-0008/
It is, see PEP 8: http://www.python.org/dev/peps/pep-0008/
* urls point to views
* views do stuff. Perhaps hard, manly stuff. Perhaps involving models. Django views have hard, beefy beceps. They're awfully controlling.
* the view passes a dict of results to the template, which is sent as a response to the browser.
Once you get that, it's not so hard.