View api cli

[IvanBrasilico]

View that interacts with Pattern and a configuration Dict / JSON View that interacts with Pattern and a configuration Dict to allow rule based command line like interface on the bot to user interact with a JSON/REST API. This implementation is making an http request as an action, but with small modifications it can do DataBase access, too.

Note: the network and DataBase acess would be better if asynchronous. Tried to do it, but looks like asyncio needs a chain of async "defs" to work, so to implement this async call, the part of the API that calls the view needs to be modified. I will try to see/test how to make it.

[rougeth]

Hey @IvanBrasilico, didn't get what are you proposing :/

[IvanBrasilico]

Hi @rougeth @nicoddemus, good morning.

I've been focusing on providing conversations that go beyond a "ping-pong". Something that allows a view to "capture" the flow a while. Like stated in issues #76 and #81. In resume, doing real world actions, a ChatBot User Interface to some system.

I first thanked about the Pattern having the responsibility to call the view, since the Pattern is the object that directs the flow.

So I made a lot of tests using bottery and made three different applications in my repository https://github.com/IvanBrasilico/cli_talker/.

In these tests, I realized a better approach than changing responsibility of the Pattern. Just create a new object on application that the view can access. But I still needed to define a special Pattern that will do the "hang" of the flow on the view. If you find a better approach, please let me know.

I also began to realize that conversation is a huge topic, with a lot of possible needs/implementations.

So I would like to propose the possibility of making extensions to bottery. I already prepared one in https://github.com/IvanBrasilico/binput. It has the new classes and an example application. With extensions, bottery source would not be bloated with a lot of functions and patterns. Maybe only the most used would be in bottery. One thing really good in bottery is that it is not bloated like most frameworks, in part because of its little age. But extensions could help to keep this lightness.

There are two more proposed patterns in https://github.com/IvanBrasilico/cli_talker/. All three applications are mixed in botteryapp.py, patterns.py and in the views:

1. A simple database Application with all flow expressly controlled in the view
2. A Input like command defined in the view
3. A flow, defined by a Dict or JSON configuration, that can map, in theory, any action (whose address is called resource in the dict) to a sequence of commands, like an interactive cli. I successfully implemented two examples: access to a non-strict JSON API, and access to a RESTful API, implemented by flask-restless

I will separate 1 and 3 and move it to an extension too.

So, I will close this PR, but would like you to take a look on proposed binput extension first, to make route corrections if needed.

Thks in advance.

[nicoddemus]

Hi @IvanBrasilico,

From what I can gather, the main functionality of the binput extension is for the user to entry data for a certain action (in the example, create a new project):

    # This block will be executed on first call
    if not app.input_queue:
        app.hang_in(message)
        app.input(message, 'name', 'Enter Project Name:')
        app.input(message, 'language', 'Enter Project Language: ',
                  ['python2', 'python3'])
        return app.print_next_input(message) # To return first message of queue
    # On next calls, this block wil be executed
    stay, response = app.next_input_queue(message)
    if stay:
        return response # Contains message from Input Command
    # Queue ended, now you could save resulting Project and exit view
    app.hang_out(message)
    return 'Project created: ' + response # Response contains user entries

I appreciate the requirement, although I find this API a little clumsy. Of course I understand this is a rough draft of the idea and one of the points is to exactly discuss the API, so I think that goal was reached.

I will have to think a little about this. 👍