Not wanting to get overly involved, but I just want to put my 2p in on this.
Todd O'Bryan wrote: > 1. Allow people to set a prefix for each app in the settings.py file. > This would basically tell the app what URLs that are mapped to it > start with, and views and templates inside the app could use this > when they want to create internally mapped URLs. By default, it would > also pass control of any URL starting with the prefix to the given > app's urls.py module, much as already happens, I imagine, in most > people's implementations, but the prefix would be an attribute of the > app, rather than some unconnected string as it is now. I not a fan of the idea that apps must map to a particular tree of URLs (i.e. the blog app is always under /blog/). It's a common implementation, and a good one, but I don't necessarily think it fits all projects. I'd rather we could say "write your apps using relative references, and here's a toolkit to help you" Basically I like the how powerful and how specific the current urls.py scheme is (sidenote: you're never going to get RoR's 'trigger a nasty script from a URL because I was trying to be clever' hole in django :-) ). I'd be sorry to see it usurped by side-effects of other processes. In fact, I'd rather this sort of conversation focused more on 'best practices', and utilising what is already available, rather than introducing extra mechanisms (especially 'magic' ones) unless really required. btw: It's always bugged me that the tutorial on de-coupling app urls [1] moves the app specific urls into the app directory, but still has to reference the 'mysite' project name in it's urlconf. [1] http://www.djangoproject.com/documentation/tutorial3/#decoupling-the-urlconfs Malcolm Wrote: > Bill Wrote: > > Plone (products) and Eclipse (osgi) do a good job structurally. But any > > kind of plugin framework models suggest Django shift from being a web > > framework to an app server. It's quite a difference, imo. > > Agreed. This was something I was having to explain in my chat with the > Drupal guy as well. That Django was a little more generic than Drupal. +1. Django is not just an app server! For the dependancy/registration stuff, I like the idea of putting some boiler plate code in __init__.py. If INSTALLED_APPS is iterated over at some point during startup, it could inspect some predefined attributes to see if dependancies are met. e.g. __init__.py: APPNAME = "Lebowski" APPVERSION = "0.3" REQUIRES = (("White Russian", ">=3.0"), ("Rug", "=1.0")) def register(**kwargs): settings.TEMPLATE_DIRS.append(kwargs['app_path']+"/templates/bowling") in settings.py: INSTALLED_APPS = (blah, blah, mysite.lebowski, blah) APP_ARGUMENTS = {mysite.lebowski : {'app_path' : "/home/django_apps/lebowski", 'something_else' : 42}} If any of these things aren't there, no harm, no foul. If they are they get checked/called. It's pretty simple to understand, and pretty flexible. I'm in two minds about the register function though. I think if you have somewhere where people can do things like modify settings then they're likley to abuse it, especially if they start trying to add things which are ordered. Maybe they just need a separate 'requires list' like the one above for apps. e.g. __init__.py: REQUIRES_MIDDLEWARE = ('django.contrib.auth.middleware.AuthenticationMiddleware',) And then it's just down to the person installing that they're on the list and in a good order. Paul --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
