I think that a good solution might be even simpler. (this is untested)
Each sub application creates an entry point, say urls.py, which
exports one list variable called handlers:
i.e.
tornado_site/blog/urls.py
from .blog import HomeHandler
<snip>
handlers = [
('/blog/', HomeHandler),
<snip>
]
Then, in tornado_site/start_tornado.py
apps = ['blog', ....]
all_handlers = []
for app in apps:
# import the app, and attempt to find handlers
handlers = find_handlers_in_app(app)
if handlers:
all_handlers.extend(handlers)
app = tornado.web.Application(all_handlers)
Obviously, the all handlers business can be abstracted out of
start_tornado.py, but you get the idea.
The major point is that I don't think there's any reason to create sub
applications within Application--what does that really buy you?
Best,
Andrew
~Thomas
I do like the idea of 'handler_list_name' in this situation.
> I really like this solution, it gives the following benefits
> - not trying to extract urls from re.compile output of instantiated
> objects
> - there is only one application object at a time
> - switching application urls and handlers by simply importing a
> different url_list
> - can automatically disable debug mode when it detects it's not
> running on development servers
> - no need to modify tornado.web.py at all
>
I'm not sure I follow this, how would you not have to modify web.py to
accept the 3rd argument? The 3rd argument for URL handlers is normally a
dictionary to use as keyword arguments in the Handler's constructor. Can
you post the code for this? I'd like to look at it, and others may as well.
> I don't think this is anything novel. It seems the most obvious
> solution after only a few hours of trying different ideas.
>
>
I like simple. Actually, I really like the way tornado handles this
right now, but I do foresee issues down the road when I develop other
applications, so finding a solution--whether it be simple or more
complicated--will be good.
Andrew