October 28, 2016
The purpose of this post is to talk about the technologies and process I used to create a ‘Facebook-like’ Java/JSP web application.
The purpose of this project was to create a ‘Facebok’-type JSP/Java web application. The end-user can create an account, update their profile information, write posts, read other posts on their ‘Wall Posts’ section, like other posts, and ‘add’ and ‘remove’ friends from their friends list. All of this was to be done utilizing just the core Java Web Technologies. JSON files are used as a ‘database’ instead of MYSQL due to the machine it was developed on had administrative program restrictions.
When a user is creating a new account, the app will check the ‘user.json’ file for any possible duplicate users. If a duplicate is found, then the user will be redirected to the ‘home.jsp’ page to re-register. Otherwise, if there is not a duplicate user in the ‘users.json’ file, the app will create a new user session. Some of these session attributes will be used on the main ‘userHomePage.jsp’ for various functions.
A particular feature of focus, when viewing another user’s profile page, is the ‘Add Friend’ or ‘Remove Friend’ button. Depending on whether that particular user’s id is in the current app user’s ‘friends list’, the relevant button will be displayed and carries out the expected function through WebSockets, updating instantly.
This section displays the user’s bio info and has a link at the bottom of it that user can click to update their bio info. When the user goes to update their bio info, the app will check to see if the user has any bio information or none at all. If not, then the app will write the new bio data to the ‘userBio.json’ file, else it will only update the fields the user updated. After submittal, the page will redirect to the ‘userHomePage.jsp’ and will display the userBioInfo via an AJAX GET request and a JQuery each loop.
Friends are displayed through an AJAX GET request and JQuery loop that appends a form ‘submit’ button to the ‘friendsList’ div. When one of the user buttons is clicked, a request is sent to a ‘UserProfilesServlet’ where it carries out the methods described previously in Viewing Other User Profiles
This section of the User’s Home Page screen is practically the same as the Friends List section, except that it pulls in all users of the apps to display and explore through.
Just like Facebook, a user can create a new post and submit to the ‘Wall Posts’ for display. When the user does create a new post, that post is stored in a ‘data.json’ file and then displayed at the top of the ‘Wall Posts’ posts, and it is all done instantly with WebSockets.
A post contains the user’s email, the date and time of the post, the user’s full name, the post text, a like count, and a liked by users list.
The ‘Logout’ button is located in the app’s navbar menu. When the user clicks on the button, a request is sent to a ‘LogoutServlet’ servlet. This servlet will invalidate the user’s session and remove all of session attributes associate with that session. Afterwards, the user is redirected to the ‘home.jsp’ page where they can log back in or register as a new user.
There are times when you do not want your user to access certain pages when they or logged into your application or are not logged into your application. To prevent certain page access according to an app user’s logged-in status, I used two Java Filters, ‘LoggedInUserFilter’ and ‘NotLoggedInFilter’. When it comes to mapping page access with filters, there are three that it can be done: through annotations, the deployment descriptor, or programmatically. I decided to go the deployment descriptor route since I was already using it for my Servlet mappings. Just makes sense to keep everything in one place.
The biggest hurdle I had while getting the filters to work was figuring out what parameter to test for. The first thing most people would think is to simply check to see if there is a user session in place or not. Well….the thing with that is that when a session is invalidated, it removes the session’s attributes, but can leave the session id available for future user sessions to use. This is where I flipped that logic and decided to check for those session attributes. If a particular attribute existed, in this case the user’s full name, then it would fire the ‘LoggedInUserFilter’ and vice versa if the attribute did not exist.
That about wraps it up for this project’s description and proccess. If you are interested in learning more about some of this app’s features, you can read more about the technologies I used below or even the entire app’s code on GitHub.