[Feature] Nest Admin View Blueprints Under Index View Blueprint for Better Organization (improvement)

[princerb]

Problem

Currently, Flask-Admin registers each view's blueprint directly to the Flask app instance, which can lead to blueprint name collisions (e.g. #55, #910) and makes it harder to manage large admin interfaces. There is currently no hierarchical grouping of admin-related routes, which I think can feel disorganized in complex applications.

Proposed Solution

I propose modifying Flask-Admin to optionally register all view blueprints as nested blueprints under the AdminIndexView's blueprint (named admin by default) or other one created initially. This leverages Flask's nested blueprint feature (Flask 2.0+) to:

• Group admin routes under a single parent blueprint, like /admin/users/ and /admin/roles/
• Reduce namespace collisions by scoping view blueprints within the admin namespace
• Improve modularity and maintainability for large applications

Example Implementation

# base.py
class Admin:
    def __init__(self, app=None, name=None, url='/admin', index_view=None, use_nested_blueprints=False):
        self.use_nested_blueprints = use_nested_blueprints
        self.index_blueprint = self.index_view.create_blueprint(self)
        if app is not None:
            self.init_app(app)

    def add_view(self, view):
        self.views.append(view)
        blueprint = view.create_blueprint(self)
        if self.use_nested_blueprints:
            self.index_blueprint.register_blueprint(blueprint)
        else:
            self.app.register_blueprint(blueprint)

Although the parameter use_nested_blueprints was not in my current plan, I wanted to describe it and thought maybe it has to be there for backward compatibility.

I will be happy if anyone can leave your opinions and suggestions!

[princerb]

I am ready to drop a PR if acceptable.

[ElLorans]

Is this a duplicate of #2495 and #2177?
Can we do anything to prevent the use_nested_blueprints? Can we directly register a nested_view to an already existing one? We are (slowly) working on Flask 2.0, so minor breaking changes would be possible, but I do not like the syntax.

[princerb]

They seem related to BP issues too, and this change could resolve #491 too.

This implementation here is specifically about nesting all admin view blueprints under a specific one to keep things tidy and avoid name clashes. Or am I missing something here?

Instead of use_nested_blueprints, how about making nested blueprints the default for Flask 2.0+ with an opt-out like use_flat_blueprints=True? Or we could add something like

admin.add_view_to_blueprint(view, admin.index_blueprint)

for direct nesting.

What's off about the syntax for you btw?

[ElLorans]

I like more the second option since it looks more clear and elegant. Moreover, you see the difference when you add the view, which adheres to the principle of least astonishment.

[ElLorans]

Thinking about it, maybe we don't even need a separate method but we can add a new argument to add_view

[princerb]

That'll do it as well yes.

With your point, If we register the Blueprints of views' to Bp of IndexView by default (main notion), then we could do:

admin.add_view(ModelView(User, db.session))  # myadmin.user
admin.add_view(ModelView(User, db.session), flat_register=True) # user

Is this what you meant?

[princerb]

Checkout this for simple explanation: changes base.py: 13dbdfb

[samuelhwilliams]

I also really want this 👀

[samuelhwilliams]

Off the cuff, I'd be happy with attaching all blueprints to the index blueprint, so for models you'd end up with something like admin.user.index_view by default rather than just user.index_view 👍

We should aim to get this in for 2.0.0 since it'll be a breaking change.