CSC/ECE 517 Fall 2013/oss cmh: Difference between revisions
Line 16: | Line 16: | ||
== Motivation == | == Motivation == | ||
Briefly talk about why invitation controller needed refactoring. | |||
== Design Changes == | == Design Changes == | ||
Revision as of 21:02, 29 October 2013
Introduction
What the invitation controller does and the process advertising, creating invites and accepting invites.
Project Description
Classes: invitation_controller.rb (104 lines) invitation.rb (5 lines)
What it does: Handles invitations to join teams.
What needs to be done: The code is deeply nested and quite confusing. There should be a single method responsible for finding whether a user is already on a team, adding someone onto a waitlist, dropping someone off of a waitlist, changing/updating the topic that the user is assigned to, etc. Some of these methods should be in model classes, such as invitation.rb and signed_up_user.rb. Break the complicated methods into shorter methods with clear names, and place these methods in the most appropriate class, moving a lot of functionality to the model classes.
Currently, after someone joins a team, pending invitations are not removed. There should be a method handling deletion of invitations (including declined invitations) to a user after that user joins a team. This should be a model method.
Though this class is not long, the code looks and reads like it is very complicated. Breaking it down into multiple methods with clear names and proper division of functionality between classes will be a challenge.
Motivation
Briefly talk about why invitation controller needed refactoring.