Size: a a a

2020 May 16

ЕП

Евгений Петров... in aiogram [ru]
Да не за что
источник

T

Twinkle 🤕 in aiogram [ru]
Евгений Петров
Да не за что
Кстате, будет еще что-то после fsm?
источник

Z

Zack!? in aiogram [ru]
Технопёс
не совсем понял идею, но если ты пытался понять схему моих обработок, то она такова:
Изначально определяются все возможные варианты ответов пользователя. Среди них может быть:
- Корректный ответ
- Некорректный ответ
- Корректный ответ, но не пройдено какое-то условие
- Кнопка «Отмена»
- Кнопка «В главное меню»
- Команда
и т. д.

Как известно, резолв хэндлеров выполняется в порядке регистрации. Я следую этой схеме течения, и регистрирую в порядке предсказуемости:

- Сначала регистрируются обработчики, фильтры которых нацелены на конкретные ответы (ReplyButtonFilter, команды, и т. п.).
- Затем регистрируется обработчик корректного, ожидаемого ответа. Сюда вешаются все связанные с этим фильтры корректности. Если всё ок, сообщение прошло валидацию, оно уходит в обработчик, который занимается дальнейшей обработкой корректного, проверенного ответа пользователя, так мы не загрязняем хэндлер валидирующим мусором, поручив все проверки предшествующему слою фильтров.
- Далее регистрируются обработчики, которые не прошли вышестоящие проверки, то есть идет обработка некорректного ответа. Если хочется сделать один большой ответ «что-то не так повторите попытку», можно просто присунуть эту регистрацию под корректным обработчиком. В противном случае стоит регистрировать все последующие обработчики в одиночном плане (по одной какой-то комбинации фильтров, под ситуацию), в зависимости от непрошедших вышестоящих фильтров.

У меня тут есть небольшой пример такой регистрации.
Звучит запутанно, да, постарался сжаться в размеры чата)
Скоро будет подробней, надо только подождать и не бухтеть (с)
спасибо за развернутый ответ по фильтрам и очередности

Я имел в виду расширенный ReplyButtonsFilter, в который будет отфильтровывать все варианты кнопок, используемых ботописцем, и его добавление в обработчик ожидания корректного ответа. Однако в нём отпадает необходимость, если использовать предложенный тобою порядок.

Статью ждём))

Вообще, идею с ReplyButtonsFilter можно развернуть: сделать его на основе BoundFilter и мидлварь на постпроцессе меседжей, собирающий все replybutton texts в этот фильтр. Например: handler(state=any_state, is_reply_buttons_text=False

Как думаешь, стоит ли заморачиваться и будут ли им пользоваться?
источник

Т

Технопёс in aiogram [ru]
Zack!?
спасибо за развернутый ответ по фильтрам и очередности

Я имел в виду расширенный ReplyButtonsFilter, в который будет отфильтровывать все варианты кнопок, используемых ботописцем, и его добавление в обработчик ожидания корректного ответа. Однако в нём отпадает необходимость, если использовать предложенный тобою порядок.

Статью ждём))

Вообще, идею с ReplyButtonsFilter можно развернуть: сделать его на основе BoundFilter и мидлварь на постпроцессе меседжей, собирающий все replybutton texts в этот фильтр. Например: handler(state=any_state, is_reply_buttons_text=False

Как думаешь, стоит ли заморачиваться и будут ли им пользоваться?
если я правильно понимаю, то ты хочешь воплотить в жизнь 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 чтобы осуществить хоть какой-то роутинг
источник

CF

Captain Flint in aiogram [ru]
а еще вопросик, нельзя редактировать чужие сообщение? тут не про бот, а в целом про телегу. Есть чат, есть админ. Админ хочет изменить сообщение другого юзера.
источник

G

Gabben in aiogram [ru]
Captain Flint
а еще вопросик, нельзя редактировать чужие сообщение? тут не про бот, а в целом про телегу. Есть чат, есть админ. Админ хочет изменить сообщение другого юзера.
нельзя
источник

CF

Captain Flint in aiogram [ru]
Gabben
нельзя
оке, спс
источник

(

( ͡°Ĺ̯ ͡° ) in aiogram [ru]
Парни, кто-то сможет объяснить вот эту строчку:
posts_cb = CallbackData('post', 'id', 'action')
источник

(

( ͡°Ĺ̯ ͡° ) in aiogram [ru]
Если хотите напишите ваше мнение в лс)
источник

q

quavo in aiogram [ru]
там еж есть примеры
источник

q

quavo in aiogram [ru]
и комментарий, как оно выглядит
источник

(

( ͡°Ĺ̯ ͡° ) in aiogram [ru]
Там мало что говорится об этом
источник

(

( ͡°Ĺ̯ ͡° ) in aiogram [ru]
А именно вот это: # post:<id>:<action>
источник

q

quavo in aiogram [ru]
ну ты пример посмотри весь
источник

q

quavo in aiogram [ru]
и поймешь, как оно работает
источник

(

( ͡°Ĺ̯ ͡° ) in aiogram [ru]
Как я понимаю, это значение calldata
источник

(

( ͡°Ĺ̯ ͡° ) in aiogram [ru]
то есть на кнопку можно несколько значений поставить
источник

(

( ͡°Ĺ̯ ͡° ) in aiogram [ru]
Но прав ли я, это уже другой вопрос
источник

q

quavo in aiogram [ru]
в данном примере post это просто как название коллбекдаты
типа тип
источник

q

quavo in aiogram [ru]
id в данном случае id поста
источник