Package: django-subserver
django_subserverAllows you to compose your web app from a hierarchy of "sub views".A standard django view is responsible for interpretingallof the url parameters, and then returing a response. In crud/management apps, you often end up with many views that share common "preprocessing" steps.The "sub view" approach is different. A sub view may return a response, or it may interpret only part of the url and then delegate the request (and the rest of the url) to another sub view.Each sub view in the chain can preform any type of middleware action - attach data to the request, return early, manipulate the response from subsequent sub views, or handle exceptions from subsequent sub views.OverviewSubRequest: A simple wrapper around django's HttpRequest, which maintains a concept of "parent_path" (which has already been interpreted by higher sub views) and "sub_path" (which must still be interpreted). You won't likely ever have to create these, but you'll be using them instead of plain HttpRequests in your sub views.Router: A sub view which performs pattern matching (on sub_path) and delegates to other sub views.MethodView: A sub view which performs dispatch-by-method, similar to django.views.generic.View.sub_view_urls(sub_view): A utility function for generating a list of url patterns, for mapping a parent path to a particular sub view.module_view.module_viewandmodule_view.package_view_importer:
Utility functions for organizing your code in a module-per-view structure.
Completely independent of the rest of django_subserver.Recommended (Basic) Setupurls.pyfromdjango_subviewimportsub_view_urlsfrom.routersimportroot_routerurlpatterns=[# standard django views here...,path('',include(sub_view_urls(root_router))),# OR# path('my_sub_view_handled_section/', include(dsv.sub_view_urls(RouterRoot))),]routers.pyWe recommend:put all your routers in a single fileuse common prefix for related routersuse snake_case instead of CamelCase for your Router subclasses: you'll have a lot of routers, and the names will be easier to read this way (especially if you use code folding or some other editor feature to show a condensed list of all your routers)put all of your auth logic in routers.py: the final sub views you delegate to should be dumbfromdjango_subserverimportRouterfromdjango_subserver.module_viewimportpackage_view_importerfromimportlibimportimport_moduleget_view=package_view_importer('project.view_modules')classroot_router(Router):root_view=get_view('home')routes={'admin/':admin_router(),'my_books/':'my_books_router',}classadmin_router(Router):...classmy_books_router(Router):defprepare(self,request):# ensure user is logged in...request.my_books=...root_view=get_view('my_book_list')routes={'<int:book_id>/':'my_books_detail_router',}...classmy_books_detail_router(Router):defprepare(self,request,book_id):request.book=get_object_or_404(request.my_books,pk=book_id)root_view=get_view('my_book_detail')...sub_views/sub_views/
home.py
my_books_list.py
my_books_detail.py
...home.py:from django_subview import MethodView

class View(MethodView):
    def get(self, request):
        ...DocumentationRead the code.Credits / Similar IdeasThis is very similar to Dart's "shelf" package (https://pub.dev/packages/shelf). I've never used it, but did some take some inspiration from it after glancing it over.I've had this concept in my mind for a long time, and there are probably other implementations of it.TODOAdd debug logging (which routers are handling the request)