By the way, the saying is "Nipping (X) in the bud." It has to do with cutting a flower before it's grown past the bud stage. No butts I'm afraid ;-).
On Dec 10, 12:09 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Tue, Dec 9, 2008 at 9:24 PM, Christopher Allan Webber > > > > <[EMAIL PROTECTED]> wrote: > > > So, by now the primary problem with Django is not the lack of good > > applications. There are tons of good applications. The primary problem > > is that almost none of them work together. There are a few reasons for > > this... some of it has to do with templating, some of it has to do with > > people not using url reversal, and some of it has to do with the fact > > that most large django applications want to install some non-models > > related administrative ability to the django admin, so most of them > > override the admin templates in ways that make them incompatible. But > > by far the biggest problem (and which encourages these other problems > > even more) is projects. > > > Projects! > > > I probably don't need to go into detail about *why* projects are bad. > > That's been discussed plenty before: > >http://groups.google.com/group/django-developers/browse_thread/thread... > > > But it's such a shame... we know that we're teaching bad habits from the > > very beginning. We know that tying applications to a specific project > > make those applications either unusable or very difficult to use with > > installations outside that project. And yet we still teach it! And the > > vast majority of users still follow these bad teachings. Some of the > > best, most high profile django projects follow these bad practices, like > > Review Board. And it isn't their fault! > > > If there was a cancer that was rapidly spreading through sexual contact, > > but which was preventable by being vaccinated early on, what would the > > best thing to do be? Sure, it's worth our time to treat the victims, > > but it's much less costly if we just stop the problem upfront by > > vaccinating. In fact, it's even worse. It's like we're handing our > > users a bottle of lube known to be contaminated with the stuff and > > saying, "Here you go guys, apply liberally." > > > Okay, that analogy starts to break down when you think about it too > > much. But the point is, it's easier to prevent by teaching good > > practices from the get-go. > > > So, django's documentation is already suggesting that we want users to > > do the right thing: > > > Philosophy > > > Django apps are "pluggable": You can use an app in multiple projects, > > and you can distribute apps, because they don't have to be tied to a > > given Django installation. > > > Unfortunately, this is telling users that right after telling them how > > to set up their site structure with "startproject". And there is no > > mention, here or later, that there is a better way of doing things, and > > a pointer to whatever kind of document would help describe that way. > > > In the previous discussion, James Bennett listed two solutions to this: > > > 1. Expand the default application skeleton, or differentiate somehow > > between a minimal, "traditional" app skeleton and a more robust one > > which includes files and directories oriented at a distributable > > application. > > > 2. Spend a lot more time documenting best practices of application > > development, possibly even mentioning in the tutorial that the > > "apps inside project" model it uses is followed for convenience and > > not because it's the best/only way to work. > > > People seemed to be in favour of number two, which is "Teach the bad > > habits with an emphasis that these habits are bad, and that there is > > documentation to do things right." I think this is fine (teachers and > > professors do this all the time with their intro students)... we just > > need to do it. > > > I am more than happy to help with writing up documentation, whatever. I > > just want to see django applications work together as a big, happy, > > pluggable family. > > Then what are you waiting for? Start writing. It's easy to tell others > what needs to be done. It's a lot harder to actually do the work. > > We are only too happy to accept any offer of help to improve our > documentation. However, that help needs to come in the form of a patch > to documentation, not as a "hey guys, you know what you should do" > post on a mailing list. We already know that our documentation could > be better. There are any number of new tutorials, howtos and guides > that could be written that would be of benefit to the Django > community. What we don't have is an infinite supply of time to turn > these ideas into reality. > > If you want to help out, we're only to happy to provide feedback or > advice during the drafting process. However, the only meaningful > feedback we can provide on a concept is "Sounds great, show us a > draft". > > So.... Sounds great! Show us a draft! :-) > > Also... regarding the subject of this post: the phrase is "nip it in > the bud", not "nip it in the butt"... unless, of course, your HPV/lube > analogy was going somewhere else entirely.... :-) > > Yours, > Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
