Python: Model Django request handler without route#4864
Conversation
Since I really want to use our existing infrastructure to model that we can recognize something as a request handler without it having a route, we need this as a separate concept. All tests have been adjusted. The early modeling was based on flask, where all request-handling is based on handling requests from a specific route. But with the standard library handling and handlers without routes, the naming had to change.
A bit scary that we don't have any tests to indicate that I forgot to add this :O
Not doing so earlier was just a mistake.
Since this was causing a CI error. also changed things a bit so we do it in a consistent way :)
I accidentially deleted that line :D
yoff
left a comment
yoff
left a comment
There was a problem hiding this comment.
Generally looks fine. I had to think it through, but it seems right that there are route setups, which have request handlers. Routed parameters are a concept associated with route setups, and "handled routed parameters" is a concept associated with request handlers. The latter is currently also called routed parameters, should we consider renaming it?
|
|
||
| /** Gets a function that will handle incoming requests for this route, if any. */ | ||
| Function getARouteHandler() { result = range.getARouteHandler() } | ||
| Function getARequestHandler() { result = range.getARequestHandler() } |
There was a problem hiding this comment.
Could this return a RequestHandler? (likewise in Range)
There was a problem hiding this comment.
This was something I struggled a bit with myself. Thanks for pointing it out, I should definitely have added a comment about this myself.
With the current setup, since the result of getARouteHandler is a Function. This means if you're modeling a web-library that uses "route to specific function/class" pattern (like flask/Django/Tornado), it's easy to specify the request handler function: Example of defining a route-setup in flask.
If we changed the result of getARouteHandler to be a HTTP::Server::RequestHandler, then we need to write some boiler code to make things work. Why? Since RequestHandler doesn't include any functions by default, we need a separate class to extend HTTP::Server::RequestHandler::Range before getARouteHandler can have a valid result.
Writing this up, it seems like I was faced with a trade-off between making it easy to write library models, and using library models, and I chose to make it easy to write them. That's probably the wrong trade-off. Can I fix this in a separate PR? I know deep down in my engineering heart that I should probably do it in this PR since this is the PR that introduces the concept, but I also know that it'll probably take me a bit of time, and I also have an urge to get this (and the Tornado PR) merged 😄 Let me know what you think 😉
There was a problem hiding this comment.
Doing it in a separate PR is probably fine, especially if it will touch many separate places. That PR will just need some explanatory text to not be confusing. If that is now the intention, we might add a comment already now to that effect.
There was a problem hiding this comment.
sure, added a comment now 😊
Co-authored-by: yoff <lerchedahl@gmail.com>
That doesn't match my understanding. My understanding is that specific URL-patterns in route setups can make web frameworks pass part of the URL to parameters of the function handling the request. These parameters are "routed parameters" (I think I invented this term myself, since different frameworks calls this different things). |
Ok, so we agree that inherent in the route setup is the fact that part of the url is passed on. I should like a name for those parts and for that to be used with the associated get-function of the route setup. A handler for such a route then may or may not actually be ready to handle being passed such a thing, but if it is, we call it a routed parameter. I would expect that we could write a query saying "Here is a route setup and here is one of its handlers. The route may pass on this part of the url, but that handler will not handle it". Is that expectation off? |
I see your point. I didn't really consider this, but I think it's a good idea! Being able to write such a query would be nice, but for sure not something you can today 😬 Having such a setup might also make it easier to get to a point where we can write |
Cool. This meaning some rejigging of interfaces, is that something you would rather postpone or sort out right away? Is it enough work to be shunted to a separate PR? |
No I really want to merge this PR now, since there are 2 other PRs that build on top of this PR. So it will become much easier (for me) to do proper cleanups after merging those 2 PRs as well. Although we have agreed that we can make improvements to the way our Concepts are modeled (yay), I don't see it as a blocker, and the changes present in these 3 PRs should still add a good deal of value without perfectly modeled Concepts (in my view) |
yoff
left a comment
yoff
left a comment
There was a problem hiding this comment.
Happy to merge this now and postpone improvements.
2 participants
I would strongly recommend going through this commit-by-commit 😉