It's finally here! My completion of Release 0.4 is at hand!
Before we dive into the technical aspects of this issue and the features I built for ContestReminder, I would like to begin by reflecting on the goals I set for this work.
The first piece of the puzzle I set out to make was a Profile page for the logged in user, where they could choose from a list of Code Contests to determine which ones they received notifications for. To save this list to their account, I chose to create a button that would handle the submitting of the form and refreshing the Profile page.
This goal was completed with a few hiccups when it came to determining the logged in user. This was the hardest aspect of the project, since user authorization has always been something that eluded me, and will be something I strive to tackle head-on as I continue my career. For now, learning on way to do it with Django and Python was nice to add to the toolbelt. While I first thought that using an implemented 'sessions' attribute was my way to go, it was only one of the many paths I could have taken. Thanks to the help from repo owners codestromer and omiz_1812, I was able to piece together what I needed to accomplish this feat. Their helpful notes can be found here and here.
And that's it! A working Profile and Delete set of options are now available for the app, and all of it's users!
Before we dive into the technical aspects of this issue and the features I built for ContestReminder, I would like to begin by reflecting on the goals I set for this work.
The first piece of the puzzle I set out to make was a Profile page for the logged in user, where they could choose from a list of Code Contests to determine which ones they received notifications for. To save this list to their account, I chose to create a button that would handle the submitting of the form and refreshing the Profile page.
This goal was completed with a few hiccups when it came to determining the logged in user. This was the hardest aspect of the project, since user authorization has always been something that eluded me, and will be something I strive to tackle head-on as I continue my career. For now, learning on way to do it with Django and Python was nice to add to the toolbelt. While I first thought that using an implemented 'sessions' attribute was my way to go, it was only one of the many paths I could have taken. Thanks to the help from repo owners codestromer and omiz_1812, I was able to piece together what I needed to accomplish this feat. Their helpful notes can be found here and here.
From there, taking the knowledge I had gained from creating the Profile page, it was time to take on the next hurdle to overcome. I next had to create a Delete Account page, where (you guessed it) the user would be given the option to delete their account. From the Profile page, I placed another button beside the Update button, which would redirect the user to the confirmation page. On this page, the user was left with 2 options: return back to the Profile page, or proceed with the account deletion. Upon deletion, the user would then be logged out, and all trace of that account would get lost in the void, never to be recovered again (deleted, gone, eliminated, GOODBYE!).
Now, I did have a third optional goal that I had initially made for myself, which was to email the user about the changes/deletion of the account. In the end, I decided to skip out on it due to time constraints. I may revisit that option in the future though, since I would like to continue to help the repository grow.
Now to the juicy parts: here are the 5 files that I needed to create/make alterations on for all of this to work.
Now to the juicy parts: here are the 5 files that I needed to create/make alterations on for all of this to work.
users/urls.py: Within this file, I needed to include the 2 new views that I created (ProfileView and DeleteUserView) to be able to use them in my paths (line 9).
Also, I needed to import a decorator to allow me to restrict users that weren't logged in from accessing these pages (line 8).
I then created the paths for these Class-based views and provided the appropriate names (lines 15 and 16).
users/views.py: To start, I needed to import a couple of basic Django view types (UpdateView and DeleteView) so that I could carry out the necessary functions for my Profile and DeleteUser views (line 10).
Loading https://gist.github.com/matt-ross16/fe401c5b89b8ea44bb02545cf068b23c....
users/views.py: To start, I needed to import a couple of basic Django view types (UpdateView and DeleteView) so that I could carry out the necessary functions for my Profile and DeleteUser views (line 10).
Next, I imported the CustomUserChangeForm that was made to handle profile update tasks, as well as the CustomUser model, structures how this data will be handled (lines 13 and 14).
Finally, the views themselves are set up. Both follow a similar structure:
1) The user model is set up (lines 22 and 31)
2) On success, the URL that is to be redirected to is specified (lines 24 and 32)
3) The template name for the corresponding HTML file is assigned (lines 25 and 33)
4) The current user object is returned to the class for use (lines 27-28 and 35-36)
The only difference between the two is on line 23, where the necessary form class (CustomUserChangeForm) is set.
home.html: The only change needed to be made here was the addition of a button to redirect the logged-in user to their profile page (line 10)
delete.html: Within this template, only a few things are different from the normal template structure:
Loading https://gist.github.com/matt-ross16/9053a3679d54da9a9254fa91f2a2f93e....
home.html: The only change needed to be made here was the addition of a button to redirect the logged-in user to their profile page (line 10)
Loading https://gist.github.com/matt-ross16/247b29b266441931c3bd8c6dd0e46da7....
delete.html: Within this template, only a few things are different from the normal template structure:
1) The block title reflects what page we are on (line 10)
2) A form is set up to post the necessary information on deletion (lines 16-30)
3) A csrf_token (Cross Site Request Forgery) is used as protection from CSRF attacks (line 17)
4) A heading, followed by two buttons are used for the functions of this page (return to profile and delete account (lines 18-22)
profile.html: Much like the delete.html file, this template follows a familiar structure. The unique parts of this HTML file are as follows:
Loading https://gist.github.com/matt-ross16/4a60acb....
profile.html: Much like the delete.html file, this template follows a familiar structure. The unique parts of this HTML file are as follows:
1) If there is an error in parts of the form, an error message will be displayed on the screen (lines 19-21)
2) Each form field is looped through and displayed, along with the necessary tags and input options (in this case, checkboxes) (lines 25-29)
Loading https://gist.github.com/matt-ross16/03f2836....
And that's it! A working Profile and Delete set of options are now available for the app, and all of it's users!
Hopefully you enjoyed this series of posts, and were able to take away some knowledge from it!
Comments
Post a Comment