I am +! on this as well.
Lakin
On 2/19/07, Thomas Steinacher <[EMAIL PROTECTED]> wrote:
>
>
> Hello,
>
> What is the current status of the ROOT_VIEW setting?
>
> Are there any plans to implement this?
>
> I am +1 on this, because it would allow me to use one Django instance
> for multiple subdomains, without wasting system ressources. Also,
> this is more flexible than e.g. a HostURLResolver (see http://
> code.djangoproject.com/ticket/1192).
>
> Thomas
>
>
> On Nov 21, 2006, at 6:22 AM, Adrian Holovaty wrote:
>
> >
> > Currently, Django uses the ROOT_URLCONF to determine which module
> > contains the URLconf from which to start processing the URL. Simon
> > Willison and I were discussing this a while ago, and he had the idea
> > of turning things around to make things more flexible.
> >
> > Instead of a ROOT_URLCONF setting, we could have a ROOT_VIEW setting,
> > which would point to a single view function that acts as the site
> > root. The URLconf, then, would *become* a view -- that is, patterns()
> > would return an object whose __call__() method took an HttpRequest
> > object and returned an HttpResponse. The logic of this view would
> > simply implement the regular expression lookup stuff that the URLconf
> > infrastructure currently uses.
> >
> > Why make this change? At first, it seems like it wouldn't be much
> > different than the way Django currently works. But consider these
> > advantages to a ROOT_VIEW setting:
> >
> > * All of a sudden URL traversal gets way more flexible. Your root view
> > can delegate to Django's URLconf for a certain app, or some other URL
> > traversal library (e.g., Routes) for another piece of the URL tree.
> >
> > For instance, you could set your root view to this:
> >
> > def my_root_view(request):
> > if request.path.startswith('/foo/'):
> > # Do something special
> > return parse_urlconf(request, my_urlconf)
> >
> > (In this example, the framework would provide the parse_urlconf
> > view function.)
> >
> > * The processing of requests gets conceptually simpler. The whole
> > shebang is just a single view function, and the URLconf happens to be
> > a "configurable" view function.
> >
> > * It would make it dead simple to do a web.py-ish "all in a single
> > module" application, by providing a run_django() function that took a
> > view and treated it as the root view:
> >
> > if __name__ == "__main__":
> > run_django(root_view)
> >
> > This would also make testing simpler.
> >
> > * It would make view decorators more flexible. You could apply a view
> > decorator to a selection of views, for instance. This might even make
> > middleware unnecessary, but I haven't fully thought about that.
> >
> > * Oh, and it would be easy to make this fully backwards compatible.
> >
> > Thoughts, criticisms?
> >
> > Adrian
> >
> > --
> > Adrian Holovaty
> > holovaty.com | djangoproject.com
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
