Contexts
Contexts are the skeleton of an application developed with Kogno, since in these, a large part of the logic of capturing, processing and replying to an incoming message is developed.
In a given project, all the contexts needed can be created in order to develop a well structured conversation.
Making a parallel with Ruby on Rails or the MVC architecture, the contexts would be the equivalent of controllers.
Creating a new Context
A context is represented by a class which is declared as follows:
class
TheContextNameContext
<
Conversation
class
TheContextNameContext
<
Conversation
Basic rules to create a new context
All contexts created must inherit from the Conversation class.
The class name must end in
Context
. Ex:MainContext
,ProductsContext, PurchaseContext
and so on.All context files must be located in the
bot/contexts/
directory under files with".rb"
extension. Ex:the_context_name_context.rb
,profile_context.rb
,people_context.rb
and so on.
Default context: MainContext
MainContext
In a new project, the context MainContext
is created by default into the file bot/contexts/main_context.rb
.
This is the general context of the conversation and the context by default in a new conversation.
All the logic of capturing, processing and replying to a message from a user that is in a conversation without a context, will be developed here.
Change the default context
The default context can be changed by modifying the config.routes.message
field in config/application.rb
configuration file.
blocks()
method
blocks()
methodThe blocks()
method is declared in a Context
class and within it, the action blocks necessary to capture messages with the characteristics that the context is expecting to handle.
Usage Example
In the code below, see how MainContext
can handle the following scenarios with the declaration of 3 action blocks:
intent "greeting"
: A greeting messages, such as"Hello"
or"Hi"
. If the intent exists and has been trained on the NLP engine.postback "email_subscription"
: A click event, that occurs when the user clicks on the button"Subscribe Me"
replied by the block above.everything_else
: A generic response, in case the message were not any the ones declared above.
The ask()
method, that together with the block answer
, focuses and reduces the conversation to achieve a goal. In this case "get the user's email".
Read more in the ask & answers chapter.
Multi-Context conversation
When the logic of the conversation becomes broader, a better distribution of the code will be very helpful.
For this reason, it's recommendable to create as many contexts needed, in a similar way to when the controllers are created in the MVC architecture.
Example
For this example we will create a new context called ProductsContext
in bot/contexts/products_context.rb
.
And remembering the first example above, in the hypothetical scenario in which a user clicks on the second button "See Featured Products"
(payload: "products/featured"
) that has been sent as reply in the block intent "greeting"
.
The click event will delegated in order to be handled by the ProductsContext
, since the payload contains a route to this context. Learn more about this in Context Routing chapter.
Moving between contexts
These methods are used to take the conversation from one context to another:
change_to(route=String, params=Hash)
change_to(route=String, params=Hash)
Changes the context of the conversation, from the current context to another context or sub-context.
After this method is called, all incoming messages from a particular user will be captured by the context defined in the route
argument, and this context will remain active until the context changes again or exit_context()
method were called.
Usage
Change to other context:
Change to a sub context from other context:
Change to a sub context in the same context
Change From a sub context to his parent context:
Params
route
String
Required.
Contains a context's name of a path to a context or sub-context.
params
Hash
Optional. Only available for sub-contexts. It sends parameters to the sub-context defined. Read more in sub-contexts chapter.
delegate_to(route=String, args=Hash)
delegate_to(route=String, args=Hash)
It delegates the handling of the incoming message to a context or sub-context, but without the conversation changing context.
Usage
The format of the route argument is the same as with the change_to()
method.
Params
route
String
Required.
Contains a context's name of a path to a context or sub-context.
args
Hash
Optional.
If ignore_everything_else
is true
, it will not execute the everything_else block, if it exists in the delegate context. By default false
.
exit_context()
exit_context()
Exits the current context and takes the conversation to the default context.
Usage
keep()
keep()
Keeps the conversation in the delegated context. Whether it was delegated by context routing or by calling the delegate_to()
method.
Usage
Last updated