A simple online chat function based on PHP

I have always wanted to try to do this interesting function. I feel that the complexity is not the data interaction and table structure, but the front-end development is the trouble...So...

demand analysis

To realize the function, first do the front-end.After comparing the online chat functions of other websites, it is found that in addition to the basic chat functions, the following points must be noted.

1. You can only chat with one person at a time, but you can switch other people at will.
2. If the user comes in from the "send message" entry, then immediately switch to the corresponding chat window, and if there has been a chat history before, the chat history should also be displayed.
3. If you are coming in from the "My Messages" entrance, then no chat history should be displayed. Waiting to select a chat partner.
4. The message sent by "I" is displayed on the right, and the message sent by "the other party" is displayed on the left. It can also be the other way around, but it should be different.
5. When switching chats, you cannot refresh the entire page, otherwise the experience will be poor. The same is true for sending messages, so ajax should be used.
6. To ensure the timeliness of online chat, you should communicate with the server every very short time, that is to say poll ajax.123456

Front page

After a simple needs analysis, and then looked for other websites, compared the function display in the interface, and finally determined the interface. Then it took a few hours to complete.

Finished product 
Write picture description here

This is the final result (including the back end).

Click on the left to switch, the multi-line text box below, enter the chat information, and then click Send.

The whole process is probably like this.

database

Looking back at the requirements, it is obvious. First, there must be a table to store the conversations between the two parties. After thinking about it, I decided to define fields like this: 
Write picture description here
mainly these two fields: 
user_id represents the subject of the message sent 
chat_user represents the subject of the message received

The advantage of this definition is that you can easily distinguish which is the sender and which is the receiver from a message, in preparation for the front-end display.

But this is not enough

With this table, you can query by the user ID in the currently logged-in session, and you can know who you are chatting with. But this is inconvenient and requires complicated processing.

1. Assuming that there is a message sent by your own party, then insert the data'own party''other party''content', and you can know that one person in the current chat is the'other party'. 
2. But suppose there is a message sent by the other party , For the current user, the data is the'other party''own party''content'.

In other words, if you want to achieve multi-person chat, you must get the users who are currently chatting with'me'. Whether they are sent by the other party or sent by'me', it should be counted. The database needs to be traversed twice , And a lot of data that is repetitive and useless at present. In the step of "getting the main body of the chat partner", you only need to know whether the two people have a chat relationship, and you don't need to care about the specific content.

So there is also a chat relationship table. I defined the fields like this: 
Write picture description here

Among them, user_id and chat_user are double primary keys and cannot be equal at the same time. In this way, only the chat relationship is recorded, and the chat content is not recorded. It is much more convenient to 
search.'I' is user_id and'other' is chat_user

For example, the first field indicates that I have a chat relationship with the user with ID 9, so there should be this user on the'I' interface. Similarly, the second field indicates that the other party has a chat relationship with me, then On the other party's interface, there must be a user like me.

Generally speaking, the chat relationship is mutual, but it can also be deleted. Deleting the chat relationship does not mean deleting the chat history. For 
example, on my interface, I deleted the chat relationship with user 9 and then I can’t see it. The chat message with user 9 is out, but for user 9, I am still on his interface and can send me a message at any time. When he sends me a message, the server will generate another data "I" 'Partner', in this way, the chat relationship between me and the other party is established again, and at the same time, the chat history has never been deleted, so when the chat relationship is re-established, the chat history can be displayed.

Moreover, after deleting the chat relationship, I can also re-initiate the chat and establish the chat relationship again.
So this table provides a lot of convenience after it is established.  The requirements analyzed above and the display of chat records can also be completed well.

The code will not be released, let's talk about the implementation ideas

First of all, the main function has a controller, two tables, and two models. As for the avatar, nickname, etc., it is not counted in the main function.

There are five methods in the controller MessageController.

1.showPage() is used to respond to non-ajax requests. When the user accesses through the browser, such as the first time entering the chat interface, it is accessed through the browser. At this time, the showPage method is called. At this time, the background only obtains the chat relationship ( The fourth method) is displayed on the left side of the interface. Others are not processed.

2.newChat(), used to respond to non-ajax requests, for example, when I click to send a message through the user profile page, this method is called at this time. First determine whether the chat relationship exists, if it exists, it will not be processed, if it does not exist, it will Insert a chat relationship. And to get all the chat relationships (the fourth method), the latest row above, transfer the user ID to the interface. Prepare for the later.

3.getChatText(), used to respond to ajax requests. Used to obtain chat information. 
After the user'I' came to the chat interface, the front end began to perform ajax polling. Keep accessing the getChatText() method. At this time there is Two situations.

1 Currently chatting with a certain user, js sends a request to the getChatText method, and the parameter is the user ID of the other party. Because the ID of'I' can be obtained from the server session. Then use these two information to get the chat message from the database .Return to json format, js performs data processing, node operations, etc., and then displays the message.

2. If you are not currently chatting with a user, then Ajax will not be started for now, and polling will be started when the chat partner is selected. 123

4.getChatTemp() method, get the chat relationship of the currently logged in user. As a tool function, for the first and second functions.

5.pushChat(), used to respond to ajax requests, that is, send message requests. Insert chat messages into the database.

It's almost like that.

Overall, the basic functions of online chat are realized, but there are defects. When I get chat messages, I get them all regardless of whether there are new messages. Then I clear the chat box and fill
it again.  The result is that when there are a lot of chat messages Sometimes, the scroll bar will have a problem. Each time a message is sent, the scroll bar will first scroll to the top and then scroll down. One solution is to add a field to the chat relationship to store the number of messages for two people. After getting the data When it is time, first count to see if it is more than the original. If it is too much, only get more data, and then update the number of messages. If there is not much, then discard the data and do nothing.

In fact, I thought that at the beginning, but I don't know why I made all the acquisitions later. 
Miscalculations, miscalculations.

Guess you like

Origin blog.csdn.net/mjian178/article/details/113020691