44OBOP 2023Sem2 PT2 solution

Creating a Login Page and Message System

Overview of the Login Page

• The initial step involves creating a login page with a table layout that includes username and password text boxes, along with a login button.

• There is no need for password validation during this test; all passwords will be accepted.

Post-Login Interface

• After logging in, the previous table (username/password) becomes hidden, and a new table is displayed to show messages.

• The username "Anna" will be displayed in the new message table, which includes headers for sender, receiver, message text, state time options, and reply.

Message Handling Logic

• If there are messages in the database (checked via model.doMessages), they will be displayed using a loop.

• Two buttons will appear: one for replying to messages and another for composing new ones.

Composing New Messages

• When Anna clicks on the "new" button, she accesses a form to compose a message.

• The composition interface includes fields for receiver information and message content.

Sending Messages

• Upon sending her first message ("Elsa how are you"), Anna checks both urgent and confidential options before clicking send.

• After sending, Anna's sent messages populate the previously empty table.

Logging In as Another User

Switching Users

• Elsa logs into the system after Anna sends her message. She sees an interface similar to what Anna saw earlier.

Replying to Messages

• Elsa can reply to Anna's message by selecting it through radio buttons provided next to received messages.

• Upon clicking reply, Elsa’s response field pre-populates with "Anna," indicating she is replying directly to her.

Understanding the Messaging Application Structure

Overview of User Interaction

• The application allows users to send messages, with a specific focus on how messages are displayed and sent between users (e.g., Elsa and Anna).

• Users can only reply to messages received from others, emphasizing the one-way nature of message initiation in this context.

Database Structure Requirements

• The application requires four tables:

• A login table for username and password input.

• A display table for showing received messages.

• An additional table for composing new messages.

• Each table serves a distinct purpose, ensuring organized data management within the app.

C Code Implementation Insights

• Reference is made to lessons 17 and 18, indicating prior knowledge is necessary for understanding the code structure.

• Key variables include sender information, message content, urgency status, and confidentiality markers.

Class Creation and Data Management

• A class must be created to manage message data effectively; this includes sender, receiver, message text options, and timestamps.

• Username and password do not need to be saved due to simplicity requirements; all passwords are accepted without validation.

Page Load Behavior

• Upon loading the page, only the login table should be visible while other tables remain hidden until user interaction occurs.

• The login button triggers visibility changes among tables: hiding the login table while displaying both username and messages tables upon successful login.

Understanding Message Handling in Web Applications

Overview of Code Functionality

• The discussion begins with a reference to lessons 17 and 18, emphasizing the need for students to study these lessons to understand the code's functionality.

• The speaker explains that clicking the "new" button hides the current message table and displays a new one, indicating a user interface change based on user interaction.

• The onPostNew method is introduced, which initializes fields for receiver and message text as empty when triggered by clicking the new button. It also manages visibility of various tables.

Sending Messages

• When users click "Send," they must save all relevant message data (text, receiver, sender) into the database before displaying it in the appropriate table.

• The process involves checking if both sender and receiver are not null; otherwise, it returns without action. This ensures valid data submission.

Saving and Displaying Messages

• After saving message details (including urgency options), the current date and time are recorded. This step is crucial for tracking when messages were sent.

• Once saved, messages are read back from the database to be displayed in a designated table. This two-step process—saving then reading—is essential for updating UI elements correctly.

User Interaction Scenarios

• Following message sending, users can log in as different characters (e.g., Elsa). Each character's view will differ based on their interactions with messages sent to them.

• Users like Elsa can reply to received messages by selecting radio buttons. The system checks if a sender exists before allowing replies.

Reply Mechanism Explained

• If a user attempts to reply but has no valid sender (i.e., they cannot reply to themselves), specific conditions prevent any action from occurring.

• In scenarios where Anna sends a message to Elsa, Anna cannot reply directly back; this logic prevents self-replies while maintaining proper flow within conversations.

Final Steps in User Interaction

• When logged in as Elsa viewing Anna's messages, she can choose to reply. This interaction showcases how different users engage with each other's messages effectively through designed UI elements.

• The session concludes with an example of logging into the application as Anna again, reinforcing how user roles affect messaging capabilities within this web application framework.

Messaging System Demonstration

Sending a Message from Anna to Elsa

• The user initiates a new message to Elsa, indicating the start of the messaging process.

• After checking two boxes, the user sends the message. Upon refreshing the database, it confirms that the data has been successfully saved and shows options for urgency and confidentiality.

Replying to Messages as Elsa

• The user logs in as Elsa and sees a radio button allowing her to reply to messages sent by Anna.

• When replying, Elsa specifies Anna as the receiver. The system prevents self-replies by not displaying a radio button for messages sent to oneself, ensuring logical interaction within the messaging system.