Support zero-ceremony sub-app mounting (including Blueprints)

[svieira]

#1361, #1498, and #1494 seem to indicate that some people don't see Blueprints as templates for application behavior, but want to treat them as little self-contained applications that are composed onto the main application. Effectively, we would be taking the app composition pattern and building it into the API.

What sort of an API would we need to properly support app composition for such purposes, since that would solve all of these use cases (404 / 405 error handlers at the "Blueprint" level, only able to see its own templates, etc.)?

The minimum API is Flask#mount_app(app_or_blueprint) - but that still leaves a few questions:

1. Does the parent app need to be able to route to sub-app routes via url_for?
2. Does the child app need to be able to route to parent or sibling-app routes via url_for?
3. Ditto for static and templates (although Method render_template does not use blueprint specified template_folder #1361 suggests that such uses would want the static and template folders to be distinct).
4. Other questions which I am certainly missing

What do you need from Blueprints? What else would you expect Flask#mout_app to do?

[davidism]

Possibly also related to #593 (nestable blueprints).

[RonnyPfannschmidt]

this is a hard_ problem ^^

[spight-zz]

The parent should be able to route to sub-apps using url_for. (The feature almost seems built for sub-apps anyway)

The sub-apps do not need to route to a parent app or sibling. The point of a sub-app (in my use case) is to create fully modular apps that I can re-use in other applications.

I would be ec-static if templates and static files would try all expected template or static locations, starting from most specific (sub-app's directory), and ending with least specific (parent app's). Though, I could see how a developer would want the parent templates to override the sub templates, or vice versa. Could this be configurable?

Also, would Flask#mount_app be able to mount other Werkzeug apps?

[svieira]

@spight - I'm not sure how one would mount a Werkzeug app differently than any other raw WSGI application. That said, I don't see why we couldn't also allow mounting arbitrary WSGI apps, but they wouldn't be routable to (unless you provided a url_map for it).

[mattupstate]

The url_for function is really just a wrapper around the current app's url_adapter.build method. If a parent app has a reference to a child app, its very easy to write one's own url_for_subapp function.

[JelteF]

In my case the child app would need to be able to redirect the main app. For instance when redirecting to home. What I use blueprints for is to having the app structure split up into different parts. These different parts do tend to interact with eachother sometimes, although not often.

It is very useful to have a common url prefix and a different template folder and static folder.

[lu-zero]

Indeed it is annoying to workaround the fact you cannot mount sub-blueprints.

[hXtreme]

I would really love Blueprint level error handlers, in particular. if a url routes into the Blueprint's suffix then the Blueprint handles the errors if the user implements them otherwise error handling falls-back to the parent of the Blueprint.

---

Before I read up on why I couldn't do the above I always thought of Blueprints as "flask sub-app" esp. because of the fact that Blueprints have the same blueprint.route() api as a flask app.

[davidism]

I think between #3215, #3709, #3933 for extracting common app/blueprint behavior to a base class, and #593, #3923 nested blueprints, this is addressed satisfactorily for now. I will continue to think about how to refactor the base class more over time.

Apps can already be mounted in a few ways. Werkzeug's DispatcherMiddleware is the most common, and I'd suggest using that. Less common is that Flask views can return any WSGI callable, doing so will call the app as if it were receiving the request. Beyond that, I don't think we actually want to mount apps like blueprints, they are meant to be the distinct entry point and nested behavior will get too complicated.

The one interesting thing would be to be able to generate a new url_for function that understands multiple apps. For example, maybe a make_url_for({prefix: app)) to match DispatcherMiddleware. I'll open a new issue for that specific feature.