Hi Malcolm,  Thanks for the reply.

I just spent the day banging through the admin code down to the
oldform fields to track down a problem I was having.  It took a very
long time because I don't know Django under the hood, and I only have
just started to learn Python.

I can think of some features in an IDE that would make this much
easier for me, and no doubt other noobs like myself.  I'll list them
out here in hopes that someone that creates IDE's reads it.  :)

*  go to last edit position (line/file), and keep going back through
history.  Komodo doesn't do this.
*  code completion and inspection in django templates and python
code.  Komodo does this a bit, but it's limited.
*  show """ doc for a object, if available
*  integrated debugger
*  Fast open - type file name to open it


On Jul 9, 2:20 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> 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