какой то не богатый мне список предоставил....
?
хакером себя еще называет😂 читай доку, там есть примеры
Доки
Действительно, без тебя бы не догадался очередной раз в доку залезть
Какой класс?:) 7-9?
буржуазия
что конкретно тебя интересует?
Хорошая статья по созданию собственных фильтров, если такая есть. С объяснением какой должен быть класс и что туда засунуть, а не как в доке список возможных методов.
(и да, с ООП ознакомлен)
только хотел тебе это написать)
А кто такие вообще, эти ваши "хакеры"? 🧐
давай конкретнее. Какой тебе фильтр нужен?
Это кто термукс на андроид скачал
У которого репо сдохли
Ну мне в общем надо обучится ставить собственные фильтры, чтобы лесенки операторов не писать. К примеру, фильтр на userAct, где userAct - статус пользователя взятый из базы данных.
Если один параметр, наследуй BoundFilter
А... Тогда знаю таких, каждый второй получается хакер.
Вот не зря же спросил. Сейчас бы тебе дали пример и ты попал бы в ловушки
каждый четвертый в этом чате скорее
ну смотри. Вообще твой фильтр мог бы выглядеть так: from typing import List from aiogram.dispatcher.filters import BoundFilter from aiogram.types import Message from yourmodule import your_func class UserActFilter(BoundFilter): key = "user_act" def __init__(self, user_act: str): self.user_act = user_act async def check(self, message: Message): return your_func(message.from_user_id) == self.user_act Зарегал бы фильтр как dp.filters_factory.bind(UserActFilter, event_handlers=[dp.message_handlers]) И в хэндлерах использовал бы как dp.register_message_handler(your_handler, user_act="admin") или @dp.message_handler(user_act="admin") НО!! ⚠️⚠️⚠️ Если ты в нескольких местах укажешь этот фильтр, то есть огромный шанс, что на каждый апдейт у тебя будет несколько раз вызываться твой your_func(), до тех пор, пока не найдёт хэндлер, который подходит по всем фильтрам. Это неэффективно. Мысль №1: кэшировать запросы, чтобы твой фильтр на каждый апдейт (или на каждый user_id) лез первый раз в базу (или куда там ты лезешь), а все остальные — в кэш. Мысль №2: если тебе 70%+ хэндлеров надо проверять этот user_act, то лучше сделать мидлварь, которая по-любому только один раз на каждый апдейт залезет в СУБД (или куда там тебе надо) и проверит, а заодно прокинет user_act напрямую в вызванный хэндлер (если такой будет). Мысль №3: в aiogram 3.x можно навесить фильтр на роутер (считай, что это диспетчер для подмножества хэндлеров), тогда проверка будет один раз на все фильтры из роутера.
Так.... Вроде дошло, остальное дело практики.... спасибо большое!
А ты использовал что-нибудь кроме словарика для кэширования?
Обычно кэши короткоживущие, поэтому словарика достаточно
С вытиснением бы хотелось(ттл или как это называется, хз), а то словарик заполнится монструозно
Hi.Вопрос.... А что хуже - лесенка из операторов, которые проверяют userAct, навешаных на хендлер в конце "тип =текст", или действительно около 70% хендлеров/кода, которые также проверяют userAct но уже получается несколько запросов к бд (под каждый хендлер соответственно)?
Да всё херово, как по мне
Тоесть... Наилучший вариант, это кеш? С которым я не разу не работал....
Я ж тебе писал про мидлварь там
Понятно....
какой... загадочный....
Обсуждают сегодня