On Sat, 2006-08-12 at 22:29 -0700, Gary Wilson wrote: > Malcolm Tredinnick wrote: > > One point of view (mine!) is that if an application can't play nicely > > with other applications and wants to do its own authentication, etc, > > then it's not an application, it's a whole other project. The project > > developer should have complete control over what the policies are for > > things like this. Otherwise it's too hard to understand what each app is > > doing when incorporating it. > > So if am using the admin application with its (contrib.auth) > authentication and then the rest of my site using a custom user model > with its own authentication, you are saying that I should make them > separate projects? That just doesn't seem right.
Project administrators (or whatever we want to call them) having their decision usurped by individual apps feels like bad system administrations practice. If a project sets up a particular authentication scheme (particularly authentication, which is security-related), an application should not be able to avoid that. I'm not really sure that there is a true "right" answer here, Gary. Again, this is a thread where a lot of untested ideas are being bounced around. I do know how I would be thinking as a Systems Administrator or Operations Manager in cases like this (even if it just on my own personal production machine(s)). Most of what we come up with is going to be suggestions or best practice ideas and we need to think about that side of things as well when coming up with ideas. > I don't think anyone has answered the OP's question of how plugable are > apps supposed to be? Except that wasn't Todd's original question. :-) He was floating a few ideas about how to manage multiple applications. We've had quite a few productive emails on those lines with various ideas in this thread. And some of the consensus that came out was that it was going to require some thinking on the part of the project creator and that isn't necessarily a bad thing. There is also the quite valid position, that you're obviously an advocate for, of having a lot of automated configuration stuff as well. But it feels like we are going around in circles with semantics at some points in this thread. Words like "pluggable" or "modular" or "application" or "project" are somewhat irrelevant: what we are really talking about is "how can I use some of that guy's code and use it in my code". > Currently, the only way you can achieve full > modularity is to make every installed app its own project. Only then > can I set the app's TEMPLATE_CONTEXT_PROCESSORS, MIDDLEWARE_CLASSES, > AUTHENTICATION_BACKENDS, etc. and be sure that applications won't stomp > over each other. Stop viewing your applications as warring parties and start thinking of them as cooperative contributors to your project as whole. You're not trying to prevent them from stomping over each other, you are trying to get them to work together. :-) I can think of lots of potential problems with per-app configurations like this and I can see that in some cases it might make life easier as well. It feels a lot like you are moving request-level things down into applications, for example. (So at which point in the request handling do they get processed?). But try it out for a while. See if it does make your application sharing easier. I have zero experience with your approach, so maybe it is easier and I'm just old and inflexible. Like I said in my first or second post to this thread, we can only benefit from people reporting back real-world experiences: things they have tried that worked or didn't work and why the new thing wasn't handled nicely by our existing infrastructure. Best wishes, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
