While that makes sense, and I understand the concerns about keeping documentation focused on highlighting the most common cases, a small note with the "suspension" information you described near the section on foreign keys doesn't seem out of place, and would greatly aid people who might not be the "experienced programmers" you describe.
I've been programming professionally for 12 years, using Django for past 9 months, and this wasn't clear to me. Maybe that's worth something, maybe it's not. I'd suspect (and hope) that Django is used by more than people who are expert Django programmers, and helping people just learning it to avoid common snags (and become "experienced programmers") would be useful. As far as behavior, it's still not necessarily intuitive. The same "suspension" done on the string foreign keys could also be done for forms that depend on them. Stating that that's now how things work doesn't have any effect on whether or not that's how they *should* work. In any case, if the consensus of the group is that this really isn't worth doing anything about, I'll shut up and hope google can index this to help the people who run into it in the future. Thanks for listening, -Steven On Dec 8, 7:41 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > This is really one of those cases where the documentation doesn't (and > probably shouldn't attempt to) address every possible alternative > version of code layout. > > On a technical level, this won't work because the "string" version of > foreign keys need to do something after the second model has been > created -- it kind of suspends finishing up the internals of some of hte > first model's data structures until the second model is finished. So you > can't use the first model until that point. > > On a more pragmatic level, this isn't really an issue. Declaring forms > in the same file as models is not a particularly sustainable programming > style. They have different roles to play (one is storage level, the > other is presentational) and although you may think "I'll only ever have > one form related to this model", that will turn out not to be the case > more often than you suspect. > > So, yes, the documentation doesn't address this. Whether it's worth > doing so (thereby making the docs longer to avoid something that is > going to be fairly unnatural to most experienced programmers anyway), is > a separate issue. The problem with addressing every single point on that > level is, of course, that the documentation becomes much, much longer > and the really important content is lost in the sea of small stuff. > > 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 -~----------~----~----~----~------~----~------~--~---
