I don't think scaffolding is bad just because it can't support all admin interface situations. It's great while you're prototyping, and may be perfectly fine for many applications where you just want a simple admin interface. Django's admin interface falls down as well if your requirements are a bit complex. It's the same argument.
As for best practices, I think we can copy and improve on RoR. The directories RoR creates is a good list of "best practices" to start from. django-admin can support environment variables similarly to the way 'cvs' does so. The point is that in 99% of the cases you don't want to use it after you've checked out a project. > Generating the model from the database is one of the few things that I > absolutely cannot stand about Rails, and to my mind it creates a > significant and unnecessary learning curve... [ it violates DRY ] In Django, as soon as you have a production system with legacy data, you'll have to keep both the database model and the Django model up-to-date. Having the framework automatically update the database schema is probably too volatile, so you'll have to do it manually. The point is you'll ALWAYS have to deal with the database schema, eventually, so why not make this be the source of the model? That is DRY in my opinion. Django isn't strictly MVC... Well, maybe it's close enough, and maybe it should be made more close. In any case, redefining well-established names like 'view' (especially when there is a 'model' in there as well) is not going to make it any easier to understand. I'm not saying Django should be 100% like RoR, but I'm just afraid we're so stuck on trying to be different that we're falling victim to the "not invented here" syndrome and ignore good learnings from RoR.
