What about Router per View? about sqladmin

[hasansezertasan]

I'm not entirely sure and I didn't think thoroughly but this approach might solve #681.

[hasansezertasan]

What I learned so far

Flask Admin Routing

As I said, Flask Admin creates a dedicated blueprint for each view and they are all registered directly to the application.

Consider two views: UserView and PostView. UserView has a blueprint named user_view and PostView has a blueprint named post_view.

Flask Admin also registers an AdminIndexView by default and its blueprint is named admin.

In Flask Admin, every view has an exposed method named index_view.

So the URL-building process is like this:

• /admin/: url_for("admin.index_view")
• /admin/user: url_for("user_view.index_view")
• /admin/user/new: url_for("user_view.create_view")

Flask Admin registers AdminIndexView before all other views. That's why I failed when I tried to adopt its core to use Starlette. AdminIndexView occupies all URLs starting with /admin/* when I use Mount.

Starlette Routing

Mount builds an application (if not provided), and the URL that is used while mounting an application, router, or group of routes is occupied by this application.

Route naming: we can name our routes with a colon separator.

admin_routes = [
  Route(..., name="admin:index_view"),
  Route(..., name="admin:user_view:index_view"),
  Route(..., name="admin:rediscli1:index_view"),
  Route(..., name="admin:rediscli2:index_view"),
]

Conclusion

Each view gets registered (mounted) to the main application. Not to an application to be mounted to the main application.

Each view has a dedicated blueprint (Router or Mount instance) and each exposed function gets registered to this blueprint.

Questions

• Do we need something like AdminIndexView?
• Do we need a separate application instance to mount admin to the main application?
• We can name expose functions like rediscli:index_view and they'll be directly registered to the SQLAdmin application and will be accessible by doing url_for("admin:rediscli:index_view") but what about the URLs?
• How does moving list, details, delete, create, edit, export, and ajax_lookup methods to the views as exposed methods sound like? This is the Flask Admin approach to the problem.

In the end problem remains: View can not have a name prefix... So if the user has two custom views with the same exposed URLs, there will be conflicts...