IvanBrasilico
commented
6 years ago The solution proposed for context is simple and well thinked, but I think it is too much responsability into one single function (a view). Also, the view for a while will take all control of the flow, and all error control, security, and wathever core stuff implemented in bottery could by bypassed in the view, possibly leading to bad implementations. The "head_set" implementation could avoid this problems, needs to be studied.
I've been thinking about a solution where the view returns a second parameter (True or False) that would mean: I want a "Hook" or "I want a conversation". The Pattern associated with the view would then process that parameter, and flag HimSelf to a special Pattern that manages the "hook". Looks more complicated, but the implementation of the view would be more simple. In this case, the context could be easily passed to another view, like in webapps, without having to bypass/disallow the central routing controller.
I have made a suggestion code. But since it is not the Pattern that calls the view, it just stores it, in the actual architeture this aproach would not work. It needs some change, that is simple: when bottery core retrieves the view from the Pattern, it is the Pattern object responsability to "run" the view.
class HookableFuncPattern(Pattern):
'''Receives a function to preprocess the incoming message
text before comparing it to the pattern.
Allows use of regular expressions, selecting partial words for
routing, etc
pre_process: a function to process message on check action before comparing
with pattern
context: string with history of messages
conversation: HookPattern Object that will hook any next messages to this pattern
(see ConversationPattern)'''
def __init__(self, pattern, view, pre_process, \
hook_pattern=None, save_context=True):
self.pre_process = pre_process
self.context = ""
self.conversation = hook_pattern
self.save_context = save_context
Pattern.__init__(self, pattern, view)
def call_view(self, message):
'''Local function to check return of view.
Just to treat errors if view returns only response'''
tuple_return = self.view(message)
if type(tuple_return) is tuple:
response = tuple_return[0]
hook = tuple_return[1]
else:
response = tuple_return
hook = False
return response, hook
def check(self, message):
''' If a view wants to begin a conversation, it needs to return True
Default is False.
First we see if the context has to be set, then we run the view.
While view returns True, the hook will remain'''
# If hooked, go directly to view
if (not self.conversation is None) and self.conversation.has_hook:
if self.save_context:
message.text = self.context + message.text
response, hook = self.call_view(message)
if not hook:
self.conversation.end_hook()
return response
# Else, begin normal check
text, _ = self.pre_process(message.text)
if text == self.pattern:
response, hook = self.call_view(message)
if hook:
self.context += text
if (not self.conversation is None) and (not self.conversation.has_hook):
self.conversation.begin_hook(self)
return response
return False
class HookPattern(Pattern):
'''FirstPattern to be checked. Allows a Pattern to "capture" and release
the flow if it receives an incomplete messsage
_pattern = a Pattern Object
Usage:
Put as first pattern
On a view, call set_conversation(Pattern) to ensure the next message will go to this Pattern
Also on a view, call end_conversation to release the hook'''
def __init__(self):
self._pattern = None
Pattern.__init__(self, "", None)
def check(self, message):
if self._pattern is None:
return False
return self._pattern.check(message)
def begin_hook(self, apattern):
'''Pass the pattern that will begin a conversation'''
self._pattern = apattern
def end_hook(self):
'''Releases pointer to Pattern ending a conversation'''
self._pattern = None
def has_hook(self):
'''Return if hook is active'''
return self._pattern is None
conversation = HookPattern()
patterns = [
conversation,
guidiego
rougeth
nicoddemus
As we talked last time, I think it would be nice for
botteryto support more complex conversations by allowing multiple replies from within a message handler.(
head_setis a little joke of course :headphones:)The main advantage of this approach is that we keep the context of the conversation inside the same function. Without this the user will have to maintain that context themselves, which is hard to do and doesn't scale very well. Pairing that with some natural language processing (#4) would make bottery well suited for complex interactions.