UrlDispatcher refactoring

[asvetlov]

Long text, please read carefully.

My initial idea was supporting both url mapper (implemented as UrlDispatcher class) and traversal.
It follows Pyramid routing schema in some way.
Traversal approach should be done by alternative router implementation.

In fact the idea has failed: too many aiohttp based libraries assumes that router is url mapper. Moreover app.add_subapp explicitly ignores the fact of alternative implementation existence.

Let's state the fact: the router is UrlDispatcher. I want to go even further: deprecate router argument in web.Application. If user need a custom url mapper based router usually it means he adds a couple helper methods for registering resources on top of existing .add_resource()/.add_route(). Better to solve the need by wrapping the whole application by user-specific class with appropriate methods.

In practice it means raising up abstract classes from web_urldispatcher.py to abc.py.

Also I would add add_static and add_routes shortcuts to web.Application. People should use either URL table or RouteTableDef for defining routes, all others are internals. And we have app.add_subapp already, let's keep all casual route table definition in the same place. Other add_* methods are considered as low-level API and will not be replicated in application.

P.S.
traversal still could be built on top of url mapper: just make a resource for matching all paths like '/{tail:.+}' and do what you want in web handler.

[kxepal]

Yay! As a aiohttp_traversal user, how this refactoring would affect on that project?

[asvetlov]

aiohttp_traversal was never officially supported.
As we discussed with @zzzsochi and I mentioned in initial message the library could be rewritten to keep clean compatibility strategy with all future aiohttp versions.

The issue is mostly about declaring the status quo and adding two shortcuts: add_static and add_routes.

[hubo1016]

Does It means that routes SHOULD be managed in a centralized pattern?

[asvetlov]

@hubo1016 please elaborate

[hubo1016]

You mean in the future, routes should always be added with add_routes right? Can it be called multiple times to add routes from different modules?

[asvetlov]

add_routes should be a preferred way. All existing API will still alive forever.
app.add_routes could be called multiple times as app.router.add_routes does right now.

[asvetlov]

Basically it is a way do skip .router property

[achimnol]

Is this issue going to affect the design and implementation of #2756 ?
It would be nice if we have an easier way to extend URL dispatcher's behavior generally.

[asvetlov]

Not sure that extending url dispatcher by custom implementations is the right way to do things.
Overall construction is very delicate, hard to support all behavior right.

I think user should never implement own router.

No, the issue itself does not affect #2756, they are orthogonal

[aamalev]

@asvetlov What fate awaits register_resource and AbstractResource? Is it possible to build compatibility on these interfaces? Maybe you should transfer AbstractResource and AbstractRoute to abc?

[asvetlov]

@aamalev what resources do you register?
Could you provide an example?

[aamalev]

@asvetlov Now I consider ways of development of aiohttp_apiset.SwaggerRouter. He serves on an algorithm similar to traversal.
Offhand there are two ways:

• to adapt TreeResource to registration
• factory the collecting RouteTableDef from the specification. But it will demand considerable processing.

[asvetlov]

But it will demand considerable processing.

Please elaborate