On Fri, 2007-09-07 at 12:48 -0400, Joshua 'jag' Ginsberg wrote: [...] > First, every section of Django becomes customizeable without chopping > up the source tree. We already permit drop-in authentication backends, > database backends, and caching backends; there's been talk of drop-in > session backends and certainly others. This would permit much greater > flexibility in allowing more customized installs. For example, I wrote > a Trac Component to recognize Django sessions instead of using its own > authentication sources in just 50 lines without touching the Trac > source tree. That's pretty nice. > > Second, Django applications are proliferating. We as a community need > to look long term about the environment this is going to create. We > already know there are enough blog applications to overflow MAXINT. > There are probably half as many blog rolls and contact information > databases and so forth. If this continues unabated, there will be > tremendous integration problems for administrators who want to reuse > other developers' apps unless the community creates a consensus > blessing many more apps as part of django.contrib tools which doesn't > sound terribly likely. Alternatively, if django were to bless certain > interface definitions for applications, leaving each developer to > select the components that best implement those interfaces, we could > avert this balkanization.
It's not clear what problem(s) you are actually trying to solve here in these paragraphs, so your ideas come across as a little abstract. Firstly, you seem to be conflating core and application, which is a misunderstanding. django.contrib is just one directory where applications live. It's only "special" in that it's owned by Django itself -- i.e. it's where the maintainers might put any apps we ship with Django. But that's the complete limit of it's specialness. Apps are just importable Python packages. Stemming the proliferation of applications sounds like an anti-problem: we want to encourage people to write apps, not stop them. Secondly, keep in mind that infinite flexibility is not necessarily a pragmatic goal. Partly because it means you spend forever tweaking the interfaces between sections and it actually restricts what you can do (because any single change has enormous external implications). Django already allows a lot of replacement of core components. ORM, templates and URL dispatching can all be done by other means if you like. You can use whatever web front-end you like and we have plans to fix things like the slight WSGI incompatibilities we currently have. Besides those things, there's not much else in core when you break it down. In most cases, it's not even a lot of code to do these replacements. Contrib apps can be used or not as you like. You mention a couple of examples where contrib apps allow some internal customisation. Could you be more concrete about what is missing. Remember that Django aims to provide something that is "sufficiently good" for creating production-capable websites. As a bonus (and by design), if you want to replace things, you can. However we're not TurboGears where they are intentionally only building interfaces between existing components. If somebody wants that type of changeability, then TurboGears is probably what they want. So maybe there is a particular thing you are trying to solve here. If so, have another shot at explaining what it is, with real-world examples. Which pieces aren't flexible enough? Abstract conversations aren't particularly productive (and you'll see that they've come up here before) because there's no path towards any sort of goal that comes out of them. Django strives to find a reasonable between "batteries includes" and allowing customisation. Where do you want to tweak that balance? Regards, Malcolm -- Everything is _not_ based on faith... take my word for it. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
