Allow plugins to define additional URL routes and views

[simonw]

Might be as simple as having plugins get passed the app after the other routes have been defined:

datasette/datasette/app.py

Lines 1270 to 1274 in b2955d9

	app.add_route(
	RowView.as_view(self),
	'/<db_name:[^/]+>/<table:[^/]+?>/<pk_path:[^/]+?><as_json:(\.jsono?)?$>'
	)

Refs #14

[simonw]

This depends on #272 - Datasette ported to ASGI.

[simonw]

See also #520 - asgi_wrapper plugin hook.

[simonw]

I just closed #520 which means this is now technically possible.

But... doing it using the new asgi_wrapper hook https://datasette.readthedocs.io/en/latest/plugins.html#asgi-wrapper-datasette isn't particularly obvious.

I'm going to leave this ticket open for the moment. I think I need at least one example plugin to show that this approach is good enough - and it's still quite possible that I'll add an extra, easier hook for this.

[clausjuhl]

Hi Simon. Any news on the ability to add routes (with static content) to datasette? As a public institution I'm required to have at least privacy, cookie and availability policies in place, and it really would be nice to have these under the same url. Thank you for some great work!

[simonw]

@clausjuhl your use-case there is now covered by custom pages from Datasette 0.41 https://datasette.readthedocs.io/en/stable/changelog.html#v0-41

[simonw]

I deprioritised this a while ago because the asgi_wrapper hook allowed me to set up new URL routes: https://datasette.readthedocs.io/en/0.43/plugins.html#asgi-wrapper-datasette

But... those were pretty low level, for example this code here: https://github.com/simonw/datasette-auth-github/blob/6c971064f6f4e6857bade5c6b88842f9cdeca9d9/datasette_auth_github/github_auth.py#L104-L113

Now that Datasette has a documented request object #706 and that object is used by things like the flash messages system (#790) - https://datasette.readthedocs.io/en/latest/internals.html#add-message-request-message-message-type-datasette-info - I find myself wanting to add views which get a request, as opposed to an ASGI scope.

So I'm re-prioritising this, with the main need being a way for plugins to hook up their own view functions that can accept a request and return a response.

[simonw]

I'll refactor existing code to register views using the same mechanism that plugins will have access to.

Maybe plugins get to register their routes first? That would allow plugins to do things like entirely take over the / page.

[simonw]

I might use some dependency injection here, with call_with_supported_arguments() from 41a0cd7#diff-942305c83055fdc0ff5f4e7d6ab06b29

Maybe a view function can take request and optionally also take datasette? Or scope or receive or send.

[simonw]

Stretch goal: make it easy for plugin views to implement formats, so they can produce HTML by default and .json or .csv etc as alternative outputs.

[simonw]

I'm going to imitate register_output_renderer and register_facet_classes - both return a list of things to register.

So I'll do this:

@hookspec
def register_routes():
    "Register URL routes. Return a list of (regex, view_function) pairs"

[simonw]

I'm going to implement this one documentation-first in a pull request.

[simonw]

I'll need to add documentation of the Response object (and Response.html() and Response.text() class methods - I should add Response.json() too) to the internals page https://datasette.readthedocs.io/en/stable/internals.html

[simonw]

WIP documentation: https://github.com/simonw/datasette/blob/770dedb21adfc706592e6b5cdf5e751a8720fdf9/docs/plugins.rst#register_routes

[simonw]

Documentation: https://datasette.readthedocs.io/en/latest/plugins.html#register-routes