On Tue, 2008-07-08 at 19:08 -0700, ristretto.rb wrote:
> I leading a project based on Django, and I come from 12 years of Java,
> and 0 years of Python.  <pause - waiting for laughing to stop>

You won't get any crap from me, at least. The more languages people
know, the better.

> I'm currently digging into the django-trunk on many an occasion,
> trying to explain things that I can't find in the docs.  Because I
> don't understand how Django was designed, and can't guess too easily,
> I find that really slow.
> 
> I'm wondering if getting the KomodoIDE editor with a debugger would
> make learning Django faster.  Or would WingIDE be a better bet?  Or
> Eclipse with pyDev.  In theory, I could see stepping through code to
> learn how it all fits.  But, does this work well in practice?

Personally I have no experience with any of those, so I'm not going to
give advice.

The one cavaet I'll point out is that *running* pretty much anything in
Django requires a settings file, since there are a few places where code
is executed conditionally based on settings. Most files can now be
imported without a settings file being present (allowing you to import
things and then manually configure settings in advanced cases), but
there might be some deep internals where that isn't possible. All this
means is that you *might* need to have DJANGO_SETTINGS_MODULE set and
pointing to some reasonably simple settings file (specify a template
loader and a database engine).

> Any other tips to getting up to speed fast? 

With the internal code? I wish there was some silver bullet like that.

When you are poking around the internals, things are generally grouped
fairly logically. Although, like any piece of software with five or six
years of development behind it, there are some historical oddities as
well. But, by and large, you'll find like grouped with like. For
example,

        django/templates:
                all the template loading and rendering code
        django/core/handlers:
                the stuff that is the outer layer of request/response
                handling.
        django/db/models/fields/
                all the model field code
        django/db/models/sql
                SQL statement creation
        django/db/models/*
                all the other model stuff
        django/db/backends/
                the individual database backends and common wrapping
                code for them.
        django/utils/translation/
                i18n/l10n support

django/utils is a bit of a grab bag of internal common stuff that is
used in multiple places. Django/core is stuff that didn't sit anywhere
else but was important.

In something as modular and wide-ranging as Django there isn't really an
obvious way to read it from beginning to end. However, if you really
want to understand what's going on you could start with the lifecycle of
an HTTP request (django/core/handlers/wsgi.py, say), which leads to URL
resolving, following through to the middleware, view calling, middleware
again and response dispatching. Orthogonal to that is model handling,
database interaction (triggered by the model code) and various view
support stuff like generic views.

Regards,
Malcolm



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to