A small modification. In actual code, discover_view just passes the view to telegramAPI, then telegramAPI passes the messsage to the view. To ensure comomn behavior to future APIs, the base plataform can take more responsability, so TelegramAPI can pass the message to BasePlataform, that will call the view, not just discover. The APIs can still treat / process the message before passing to the function.
Also, when calling the view, the new function also checks if the active pattern has a function to call views (seeing if a method called "call_view" exists). If it exists, passes the responsability to call view to Pattern.
This flow will allow the Patterns that implement the call_view method - and now have access to the return of the view - to make decisions about the flow allowing more complex and flexible interactions.
@IvanBrasilico I personally don't like this approach. A function should do only one thing, and do it well. Being responsible for two different actions, can make it harder to integrate new stuff.
A small modification. In actual code, discover_view just passes the view to telegramAPI, then telegramAPI passes the messsage to the view. To ensure comomn behavior to future APIs, the base plataform can take more responsability, so TelegramAPI can pass the message to BasePlataform, that will call the view, not just discover. The APIs can still treat / process the message before passing to the function.
Also, when calling the view, the new function also checks if the active pattern has a function to call views (seeing if a method called "call_view" exists). If it exists, passes the responsability to call view to Pattern.
This flow will allow the Patterns that implement the call_view method - and now have access to the return of the view - to make decisions about the flow allowing more complex and flexible interactions.