-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The mechanism of the rules for the matching of subapps #2809
Conversation
b85b227
to
1fb9b83
Compare
Codecov Report
@@ Coverage Diff @@
## master #2809 +/- ##
==========================================
+ Coverage 97.99% 98.01% +0.02%
==========================================
Files 39 39
Lines 7379 7506 +127
Branches 1296 1316 +20
==========================================
+ Hits 7231 7357 +126
Misses 47 47
- Partials 101 102 +1
Continue to review full report at Codecov.
|
I think Regarding to router changes: they are either incomplete or sense-less. Say, I see no usage of |
@asvetlov add_domain is more readable but highly specialized. DefaultRule was born because of the lack of add an application without a prefix. UseCases:
|
It still looks too complex, |
fb0e4b9
to
bbe37ed
Compare
bbe37ed
to
8241398
Compare
Should this be closed? |
I am asking because I would like to continue to work on #1342 |
66d1513
to
7097208
Compare
Codecov Report
@@ Coverage Diff @@
## master #2809 +/- ##
=========================================
+ Coverage 97.98% 98% +0.01%
=========================================
Files 44 44
Lines 8075 8151 +76
Branches 1356 1365 +9
=========================================
+ Hits 7912 7988 +76
Misses 68 68
Partials 95 95
Continue to review full report at Codecov.
|
@asvetlov please review |
@asvetlov Final realization adds only one public interface Application.add_domain(str, subapp) which encapsulates the mechanism |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR.
Please address my comments
aiohttp/abc.py
Outdated
@@ -145,3 +145,18 @@ def __init__(self, logger, log_format): | |||
@abstractmethod | |||
def log(self, request, response, time): | |||
"""Emit log to logger.""" | |||
|
|||
|
|||
class AbstractRuleMatching(ABC): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I doubt if we need this abstract class: it is used for Domain
class only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still the question
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two and a half ways to decide his fate:
1 Throw away
2 To refine the subsystem of rules
2+1/2. Combine MatchedSubAppResource and PrefixedSubAppResource as they differ practically only by the method resolve
class PrefixedSubAppResource(PrefixResource):
async def resolve(self, request):
if not request.url.raw_path.startswith(self._prefix):
return None, set()
class MatchedSubAppResource(PrefixedSubAppResource):
async def resolve(self, request):
if not await self._rule.match(request):
return None, set()
and implement the rule
class Prefix(AbstractRuleMatching):
def __init__(self, prefix):
self._prefix = prefix
@property
def prefix(self):
return self._prefix
def match(self, request):
return request.url.raw_path.startswith(self._prefix)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to not introduce a new public ABC class.
Moreover, in aiohttp 4.0 I want to drop a pluggable router. By this, we'll have the only supported router implementation -- the current one. In this light adding a new ABC to API part that will never be extended outside doesn't make any sense.
If you have a feeling that ABC is valuable -- feel free to keep it but move into web_urldispatcher.py
.
@asvetlov I moved AbstractRuleMatching to web_urldispatcher
and local mypy-0.641
|
Please merge master, mypy is updated and |
…e-matching-subapps
Thanks! |
@@ -1387,6 +1387,21 @@ duplicated like one using :meth:`Application.copy`. | |||
|
|||
:returns: a :class:`PrefixedSubAppResource` instance. | |||
|
|||
.. method:: add_domain(domain, subapp) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aamalev Maybe domain
might have been better named pattern
. Also there is no documentation about how domain
is matched against the host ie. the fact that foo*
match foobar
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pull request is welcome!
I propose to implement subdomain as part of a general approach, when subapp can be matched according to a certain rule
Are there changes in behavior for the user?
No
Related issue number
#1342
#2194
Checklist
CONTRIBUTORS.txt
CHANGES
folder<issue_id>.<type>
for example (588.bugfix)issue_id
change it to the pr id after creating the pr.feature
: Signifying a new feature..bugfix
: Signifying a bug fix..doc
: Signifying a documentation improvement..removal
: Signifying a deprecation or removal of public API..misc
: A ticket has been closed, but it is not of interest to users.