New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
command handler pull requests #47 and #51 #52
Comments
First of all, thank you for your awesome contribution here. Nice work!
Agree, if we are combining decorators we could do something like this:
Not sure what you mean by that, but command_handler will be an additional layer to core library, devs can go either way by doing manual long polling or using command handler.
Agree, with a decorator to identify command functions.
Partially agree, there should be an option for that. Imagine someone trying to run a bot with an invalid token not catching errors (remember logging is not a good thing to auto enable for libraries).
Sure.
One more thing. I've been thinking about in event driven architecture, telegram offers some events where we could turn into useful decorators, how so: on.new_chat_participant I'm back home this long weekend so I'll be able to help, please feel free to ping me on telegram (@leandrotoledo). Once again, thanks for your work here. |
First of all thank you! you are the one doing all the great work here.
As I said I'm building a bot for myself and it needs to be able to respond with a location. #47 is not able to do this now.
Indeed it is true that a program should always stay debugable.
Well this not exactly what I meant. I meant that I want the users of the bot to be able to sent arguments alongside a comment. But I do think an update or just a message object will be enough information to handle a command. But only text a user send won't be sufficient.
I think this is a really nice idea. Maybe you can even replace the getUpdates with some events. for example: I was also thinking of implementing a nice way to create to create a command with multiple messages. An Example of what I mean by that is for example the /setuserpic from BotFather.
a. if 3.a and no more messages are needed by the command then send exit message I don't know how to do this and I haven't done much thinking about this problem but I want to share it because maybe someone already has some neat idea about this. |
Many thanks for the contribution. I second @leandrotoledo idea on event driven architecture. data should be emitted by event handler, getUpdates, increment lastupdatedid and polling mechanism should be completely abstracted out from user. an ideal event driven command handler should be completely handled by "Observer" design patterns. Library requests for listeners (callbacks) for a given action
sample example (Implemented in c++) Thanks, |
Regarding the It would be better to extend Then we could add method decorators for the various types of handlers. Synchronous bots can then use |
@jh0ker has implemented a really nice code for this feature request, many ideas match the discussion we had here, so I'll mark this one as obsolete. Please feel free to reopen in case I'm missing something. Lastest version should be available by Also, some good kick off can be found here |
I noticed that there are two command handlers now. The EnhancedBot from mASOUDd in #47 and command_handler.py from me in #51.
I want to discuss what you guys think of the two. And maybe look at some way to combine them so that there is only one command handler in the package.
some of the main differences are:
The way to create the command handler.
EnhancedBot:
you just create a bot and all the tools are in it.
command_handler:
you create a new class with inherits CommandHandler or CommandHandlerWithHelp.
CommandHandler has a self.bot attribute.
The way to create a command.
EnhancedBot:
To create a command you simply do this.
(I personally love this system as well but I didn't know how to make it.)
command_handler:
create a new method in your class. which starts with 'command_' and takes update.
The way to start the command handler.
but I think this is less important because they do basically the same thing here.
EnhancedBot:
command_handler:
My opinion.
to it as usable as possible to me it has the following requirements:
I implemented some of these in my command_handler
The text was updated successfully, but these errors were encountered: