Smart Interfaces

[php-telegram-bot]

Smart Interfaces

[akalongman]

All messages already tracked. We can store state in db, but I think will be better if first we complete what we have :) And after we will add more features

[MBoretto]

I think about this because i'm making experiment with custom keyboard, and is mandatory to use this implementation.
If you press a button on the keyboard a message is sent to the bot without command.
So the bot have to manage message without command and at the end execute the command.
However soon i will pull the class ReplyMarkup to build easy keyboard.
Then we can think about it! ;)

[akalongman]

You read CONTRIBUTING.md file? There is contributing notes. Also we must write more unit tests for our classes

[MBoretto]

Yes i red it! But i never use those intruments before so i have to study a bit!

[MBoretto]

Hi! I've got in my mind a way to implement this feature! I would like to have a feedback before start seriously to code.

To do this i need a new .sql table:

CREATE TABLE `track` (
  `id` bigint UNSIGNED AUTOINCREMENT COMMENT 'tract id',
  `track_name` CHAR(255) COMMENT 'Name of the command to execute',
  `user_id` bigint  COMMENT 'User that wrote the message',
  `data` VARCHAR(10000) COMMENT 'Data stored from command',
  `date` int(11) UNSIGNED COMMENT 'Date the track in Unix time',
   PRIMARY KEY (`id`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci

I would like to add 3 methods to the Command class:

• startTrack(){}
  Check if a track has already been created in the database. If the track is not found, a new track is created.
  startTrack fetch the data stored in the database with unserialize() function:
  $data = startTrack();
• updateTrack($data){}
  Store the array/variable in the database with serialize() function
• deleteTrack(){}
  delete the track from the database

When a new message arrive without command, the bot check if a track for the user is stored on the database, then if a track is found the message is handled by the command stored in the track.

[akalongman]

I think will be better in tracks table store not full data, store message_id. Messages already stored in messages table

[MBoretto]

The data field is also intended for store information useful in the future interaction with the user maybe some Flags or status. Something like $_SESSION

I prefer non to include a field with message_id because a track can include multiple interaction with the user for example:
user: /calc
bot: press calculous on the keyboard! (track is started a row is added to the db)
user: 2 (the bot execute calc command and store in the track the element 2)
user: * (the bot execute calc command and store in the track the element *)
user: 5 (the bot execute calc command and store in the track the element 5)
user: = (the bot execute calc command the full command is executed)
bot: 2 * 5 = 10 (the bot show the result and delete the track)

To avoid store rendundat information from messages i have to create another table to link track and messages something like:

id
track_id
message_id

[danielberlin]

Sounds good! I would need that as well for a convenient interface, will be your tester once it is available.

[ericxxp]

Good job man ! I like it

[hakdig]

Good idea. I have a suggestion to add a "status" column to store data like : in progress, cancelled, finish. It let the possibility to add a button "cancel" to the custom keyboard and forget the scenario.

[MBoretto]

I like your idea @hagdig !
I wrote a code to do this.
I didn't share it yet because it add complexity to command interface.
I think that the library is not ready for this:
with the new inline feature a lot of work should be done in order to build a new table schema able to store the inline query.

If you and other people are interested we can complete the library with those feature and impove my tracking system!

[FerX]

I'm interested !

[MBoretto]

@FerX can you describe in details the feature you're looking for?

[FerX]

the possibility of defining a dynamic menu tree

[MBoretto]

There is PR open for this feature. @hakdig I implented you status columns that could be: active stopped cancelled

[MBoretto]

Smart interfaces has been introduced since 0.29. I'm closing this, then we can open another issue to improve this feature 🎉