You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 Filterclass,
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.
@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.
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.
The text was updated successfully, but these errors were encountered:
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_update
s are always executed first, then@on_message
, and@command
is always executed last. Which is not very flexible.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 thecall_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 atext
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 thetext=
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.as_blueprint
? Or can they simply wrap those in a lambda to call later?Additional Benefits
The text was updated successfully, but these errors were encountered: