That would be pretty cumbersome to migrate, and confusing especially since it would require adding an argument to each controller method, that isn’t actually reflected in the arguments provided in the routes file itself.
I can’t exactly tell how the 2nd example would operate.
In projects I’ve worked on, I mostly use
request() as a way of detecting arguments added to individual calls, allowing for more fine-grained control over things like database queries.
A common example is providing start and stop times in the URL parameters. Those can be entirely optional. Making a separate route for no provided times, only start provided, only stop provided or both provided, seems like a bad idea when I can do it with only 1 route. And with this data, I can then dynamically add parameters to the ebean query.
They’re optional dependencies and the decision of adding them is entirely up to the user making the call. They might want a historical view of everything between 2 UNIX timestamps(provide start and stop), or they might say “I want everything of the past X hours”(provide only start).
The concept of a “context” seems logical, as each route being called(each action) is logically its own separate thing that cannot affect the application as a whole.
My main concern is: will I still be able to easily, without changing much of my code, access this data that I will unpredictably need or not?
EDIT: I just remembered optional parameters in the routes file. I probably forgot because I recall demonstrating the mere abilitty of doing