coaster
coaster copied to clipboard
ClassView must support init_app with blueprints, and with multiple apps
ClassView currently expects an app in the init_app
call. It must also accept blueprints, and most support registration with more than one app.
The main (known) consideration when using a blueprint is that endpoint names must be prefixed with the blueprint's name. This applies to the ViewDecorator.endpoints
set.
For multi-app support, endpoints must be saved against each app, making ViewDecorator.endpoints
a dict of lists (not sets, see below), mapping the app to endpoints.
The ViewDecorator.endpoint
attribute must change to a property that returns an appropriate endpoint for the current app. At the moment this will be the first endpoint in the list of endpoints registered for the current app, since we do not have a problem statement for selecting a specific endpoint.
Blueprint support was added in b3d08ad71e1149c3bb301d9c6673d3341545e922.
For multi-app support, endpoints must be saved against each app, making ViewDecorator.endpoints a dict of lists (not sets, see below), mapping the app to endpoints.
Endpoints are the same regardless of app, since they're defined inside the class, and the entire class is linked to the app.
Instead, ViewHandler.init_app
(it's no longer called ViewDecorator
) performs initialisation that does not need to repeat for additional apps. This should be gated.
ClassView.init_app
has a similar requirement. It needs to be split up.