q
Size: a a a
q
q
(
q
(
(
Z
ReplyButtons
, то есть фильтр на какую-то коллекцию кнопок, а не на один вариант. Смутно представляю применение такому фильтру...)Update
- один хэндлер». Я изначально размечаю хэндлеры как точки входа для обработки, например:# обработка реплай-кнопки «Назад»
handle_back_reply_button
# обработка инлайн-кнопки «OK»
handle_ok_inline_button
# обработка введённого имени
handle_name_message
И когда хэндлеры размечены и зарегистрированы, можно вписать в их тела саму логику. У меня это делается через делегирование задачи операционным исполнителям, но сейчас не об этом. Хотя для понимания картинки показать стоит:async def handle_start_command(update, bot, fsm_context):
await execute_hello(update, bot)
await execute_main_menu(update, bot, fsm_context)
и возвращаясь назад, к вопросу об отлавливании множества кнопок, хочу спросить зачем? Разве не удобнее ловить что-то конкретное, и явно его кидать дальше по цепи? Это напоминает мне ньюбайскую схему с одним хэндлером на тип Message
, и кучей if/elif
в теле. Хэндлер должен обрабатывать одну задачу, и реагировать на определенную сущность. Обратная логика приведет к анархии в связях, нам пришлют один вариант из десяти ожидаемых, и мы кинем его дальше в толпу if/elif
чтобы осуществить хоть какой-то роутингТ
from main import bot
и удобнее в обслуживании, т. к. схема хэндлеров остается неизменной, при изменении логики. Помню некий некто выстрелил себе в ногу, вызывав хэндлер из хэндлера из хэндлера ...q
Т
q
Т
ЕП
q
Т
ЕП
Т
Т
q
G
new
- Генерирует новую колбек дату с указанным префиксом, значениями и разделителем (: по умолчанию), которую ты потом помещаешь в инлайн кнопкиfilter
- Возвращает фильтр, по указанным значениям. Его ты указываешь там где и все фильтры.filter()
- значения у "частей" любыеfilter(some_part="foo")
- some_part равен "foo", остальные части - любое значениеfilter(some_part="foo", yet_another_part="bar")
- some_part равен foo, yet_another_part равен bar