Current situation
We have a separate list of update listeners, a list of command listeners and a list of messages to process.
This comes with a few disadvantages:
@on_updates are always executed first, then @on_message, and @command is always executed last. Which is not very flexible.
- You can't easily add your own rules for listening to messages - you have to use a generic listener and implement the logic yourself, which isn't D.R.Y.
New Approach
We wanna have a Filter class,
having the following methods:
__init__(self, func: Callable, ...)
This needs to take at least the func parameter, collecting the function to call on a match.
match(self, update: Update, ...)
This will check that we can run this very function.
Either raises an NoMatch(msg: str) exception, if we don't match, or returns a variable to use (or not use) in the call_handler later.
call_handler(self, update: Update, match_result)
This will actually call the function registered with the correct parameters.
This allows to supply any parameters for a function.
For example the @command has a text parameter for everything after the /command.
Note: Those has to be keyword parameters, so a function could stack different listeners, if needed. We also get provided the match_result, in case we did have some results there we don't wanna compute twice.
Same @command already needs to take apart the string, so we get the text= parameter there. No need to redo that logic.
@staticmethod as_decorator(teleflask, *args, *kwargs):
This shall be the easy way to use it as a decorator, the old Teleflask would simply call the fitting filter's as_decorator, when it's registering those.
- do we need some kind of
as_blueprint? Or can they simply wrap those in a lambda to call later?
Additional Benefits
- This should make it easier to get away from those Mixin Classes
- Also this should make the code of the Blueprint much easier, as we now have a simple list of filters we need to merge.
Current situation
We have a separate list of update listeners, a list of command listeners and a list of messages to process.
This comes with a few disadvantages:
@on_updates are always executed first, then@on_message, and@commandis always executed last. Which is not very flexible.New Approach
We wanna have a
Filterclass,having the following methods:
__init__(self, func: Callable, ...)This needs to take at least the
funcparameter, collecting the function to call on a match.match(self, update: Update, ...)This will check that we can run this very function.
Either raises an
NoMatch(msg: str)exception, if we don't match, or returns a variable to use (or not use) in thecall_handlerlater.call_handler(self, update: Update, match_result)This will actually call the function registered with the correct parameters.
This allows to supply any parameters for a function.
For example the
@commandhas atextparameter for everything after the/command.Note: Those has to be keyword parameters, so a function could stack different listeners, if needed. We also get provided the
match_result, in case we did have some results there we don't wanna compute twice.Same
@commandalready needs to take apart the string, so we get thetext=parameter there. No need to redo that logic.@staticmethodas_decorator(teleflask, *args, *kwargs):This shall be the easy way to use it as a decorator, the old Teleflask would simply call the fitting filter's
as_decorator, when it's registering those.as_blueprint? Or can they simply wrap those in a lambda to call later?Additional Benefits