Django for a Rails Developer

http://uswaretech.com/blog/2009/11/django-for-a-rails-developer/

by scorpion032 • 17 years ago

57 31 17 years ago

uswaretech.com

ulf2• 17 years ago

Anyone knows if this exists vice-versa?

uggedal• 17 years ago

No one goes from Django to Rails...

icey• 17 years ago

Hmmm.... I do Django stuff but I'm working on my first Rails project right now. A Django -> Rails guide would be useful to me.

rbanffy• 17 years ago

I admit. I mod up for funny.

arthurk• 17 years ago

"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/

ashok_raavi• 17 years ago

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.

roam• 17 years ago

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.

kteague2• 17 years ago

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.

nailer2• 17 years ago

For me the hardest thing about Django was comprehending that the 'View' is doing most of the work.

* 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.

ulf2• 17 years ago

Actually, if you apply the MVC paradigm, the Django View is a mix of View and Controller. Admittedly a little confusing

scorpion0322• 17 years ago

Hence, it is defined as MTV.

scorpion0322• 17 years ago

A perfect tl;dr.

riffer• 17 years ago

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.

FraaJad• 17 years ago

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.

sidmitra• 17 years ago

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.

neelesh2• 17 years ago

shabda• 17 years ago

however typical developments do, and this question is about typical development setup

neelesh2• 17 years ago

Agree. What we probably need is a nice way to switch between deployment/development setups, possibly by splitting settings.py like rails

tvon2• 17 years ago

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.

ubernostrum2• 17 years ago

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)

tvon2• 17 years ago

> 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.

kteague2• 17 years ago

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)

ubernostrum2• 17 years ago

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.

artpop• 17 years ago

Seems like Django is more comparable to Sinatra? And is 4 spaces the python way? I like my font big and my lines short.

alexkay• 17 years ago

> And is 4 spaces the python way?

It is, see PEP 8: http://www.python.org/dev/peps/pep-0008/

iamwil• 17 years ago

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.

Django for a Rails Developer

Related Stories