daytron / revworks Goto Github PK

To prevent from users pressing it over and over while the server is processing the request. The button is enabled again if there are failures detected.

To-Do List:

1. Rename Review to Notes
   • for schema, script and code
2. Since both share the same functionalities because of this, it is possible to merge components and coursework views into their respective relative coherent logic.
3. Create an executor service for refreshing the notes area.
   • adds another session attribute for this executor to shut down the thread later on when the session ends.
   • One second interval for the new thread.
4. A way to distinguish lecturer's notes from student's notes.

1. Create wrapper for the EventBus class to handle subscribers exception.
2. All custom events are handled by a new abstract class. All events are static and final.
3. Replace all click listeners and move them to UserAccessControl

Observers:

• UserAccessControl
  • For user login and logout events
  • For option group change value event (from login screen)
  • For webmaster link click event (from login screen)

A submission list view of courseworks.

This is where lecturer can browse the selected student coursework and provide reviews.

The view load the coursework page by page. The lecturer will be able to navigate through the pages.
Reviews can be attached on a page. Each review will have set of comments in which students can participate to comment in real time if they are both online at the same time.

Each time a review is open, a new thread is initiated to listen for new comments either from the student or lecturer and display it on screen.

Use cases triggers:

For Lecturers

1. When student submits a coursework
2. When student submits new note (aggregate)
3. When student replies with new comments (aggregate)

For students

1. When lecturer adds a new note (aggregate)
2. When lecturer replies with comments (aggregate)

Now comes with icon for greater recognition and visibility.

• Number validation for student ID:
  • Accepts numbers only
  • Limits to 5 numbers only
  • Validation triggers upon clicking login button.
  • Required field
• Email validation for lecturer's username
  • Validation triggers upon user typing in the field
  • Required field
  • Maximum of 254 characters following the standard email length
• Password validation
  • Minimum of 6 and maximum of 16 characters
  • Validation triggers upon clicking login button
  • Required field

To be consistency with the new initial semester check done upon login and only match the current semester id from session attribute.

To save SQL connections and resources, instead of reading class info everytime announcement, coursework submission, coursework module view are loaded.

As soon as the class are read after login. The class data is saved in the session using CopyOnWriteArraylist for concurrency proof purposes.

This refactor will require huge modifications among classes.

Another feature is born because of this. User can now login even if it is in between semester, but the data will be empty, instead of barring access in between semesters. Only within the current semester, the user has complete access to the relative data.

Verify login data with the application's database.

The textfield page turner doesn't show 100% width page.

A view where lecturers can submit announcement to their students. A lecturer can submit an announcement to a class he/she registered to teach.

An insertable error label is less intrusive than a popup that requires user to click in order to continue.

Something like this.

The home view will show the general state of the application.

This includes but not limited to:

• The number of currently login users.
• Total number of sessions that has no user login.

• The UI after login is accepted and verified.
• Navigational menu
  • collapsible and can be hidden through a small button o n top
  • horizontal bar on left
• Default page points to submissions
  • has 3 modules divided into 3 tabs
• logout option on top right

Use Cases trigger:

1. Student submit new Coursework (CW) -> no notes
   • (student) unread (by default, since user hasn't open it yet)
   • (lecturer) unread
2. Student submit new CW -> no notes && Lecturer open it -> no notes
   • (student) unread
   • (lecturer) read
3. Student submit new CW -> open it -> no notes && Lecturer open it -> no notes
   • (student) read
   • (lecturer) read
4. Student submit new CW -> open it -> add a note or notes
   • (student) read
   • (lecturer) unread
5. Student submit new CW -> open it -> add a note or notes && Lecturer open it -> did not read notes
   • (student) read
   • (lecturer) still unread (due to unopen notes)
6. Student submit new CW -> open it -> add a note or notes && Lecturer open it -> read notes
   • (student) read
   • (lecturer) read
7. Student submit new CW -> open it -> add a note or notes && Lecturer open it -> read notes -> add a note or notes or comment to previous read note
   • (student) unread
   • (lecturer) read
8. Student submit new CW -> open it -> add a note or notes && Lecturer open it -> read notes -> add a note or notes or comment to previous read note && Student open it and read all notes
   • (student) read
   • (lecturer) read

Centralise all exceptions into a single point of entry using ErrorHandler interface. Create a central helper to manage all notifications.

Any remaining announcements that fall within the current week, are shown as well. Otherwise, they are not shown.

Switch from 100 dpi to 300 dpi, for clearer page render. Quality is much preferred over performance. May cause longer time to load the pages of the coursework than the usual.

The main view of the navigator in the dashboard. This view will aggregate recent announcements to lecturers and students.

Factor announcement data into the database.

The pdf saved in the database is converted and presented in displaying the coursework

The popup is attached to link available in footer area of the login page, see issue #12.

It has to be blue.

An enum should be adequate.

Then use the properties file to access the credentials back to the source code, specifically to the JDBC connection pool object.

Obviously the properties file should never be allowed to be uploaded in the repo for security purposes. For better security, new database credentials will be used instead when deployed in the cloud server.

Allows student to submit the following filetypes docx, odf and odt.

Build the base UI for user login.

To encapsulate separation of processes for each type of user.

• An interface for overview of methods
• An abstract class to implement the interface for common methods for each user, such as home view data population for students and lecturers.
• A concrete class to inherit the abstract for each user type with their own SQL​ access methods

This can be triggered when the user signout or close session due to inactivity, close browser tab, etc.

Use cases trigger:

1. When student creates new note
   • student is_read set to true
   • lecturer is_read set to false
2. When lecturer creates new note
   • student is_read set to false
   • lecturer is_read set to true
3. When student clicks a note
   • student is_read is set to true
   • (no change)
4. When lecturer clicks a note
   • (no change)
   • lecturer is_read set to true
5. When student submits a comment
   • (no change) (already true when student clicks initially)
   • lecturer is_read is set to false
6. When lecturer submits a comment
   • student is_read is set to false
   • (no change) (already true when lecturer clicks initially)