CSC/ECE 517 Fall 2014/oss E1458 sst

From Expertiza_Wiki
Revision as of 22:42, 26 October 2014 by Sdrangne (talk | contribs) (Created page with "=Expertiza - Refactoring ResponseController= __TOC__ ==Project Description== The response controller allows the user to create and edit responses to questionnaires such as per...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Expertiza - Refactoring ResponseController

Project Description

The response controller allows the user to create and edit responses to questionnaires such as performing a review, rating a teammate or giving feedback to a reviewer. Our project requirement was to perform the following changes :

  • Perform authorization properly.
  • Remove the duplicated methods.
  • Reduce the complexity of the rereview method.
  • Move the functionality incorporated in the controller, to the model, as it is the models responsibility to implement this functionality.

Refactoring carried out

The following changes have been made in the project, as described in the requirements document.

Perform Authorization correctly

  • Authorization to perform actions was not checked correctly. It is supposed to be done through the action_allowed? method at the beginning of the class definition. Different authorizations are required for different operations. For example, someone should be allowed to view a response if they wrote the response, or they are the person or on the team whose work the response applied to, or if they are an instructor or TA for the class. The person who wrote a response should be allowed to edit it, but not the person/team who was being reviewed, nor the instructor or TA for the class.
  • Earlier, the authorization was denied by the redirect_when_disallowed method, which was a more error-prone way of controlling access. This method has now been removed, and now the class has an action_allowed? Method which does the authorization check and allows the user to perform the action if it is allowed.

Before Refactoring:

Code snippet

After Refactoring:

Code snippet

Removal of redundant methods

  • There were two copies of the edit, new_feedback and view methods. The second being the newer one, and, according to the rules for method definition, is the one that is currently in use because the latest version overrides the previous versions. We refactored the code by removing the redundant methods.
Code snippet

After Refactoring:

Code snippet

Cleaning up of the rereview moethod

  • The rereview method was 98 lines long. We refactored the code by turning several parts of it into methods. Now the code is ___ lines long.

Before Refactoring:

Code snippet

After Refactoring:

Code snippet

Creation of a Kludge

  • The rereview method contained a special code to check whether an assignment is “Jen’s assignment”; this was the first assignment that was ever created with a multipart rubric. It was hard-coded into the system, rather than working on a rubric that was created in the normal way. It is impossible to remove this code without breaking that assignment. It is now implemented as a separate method, handle_jace_kludge.

Before Refactoring:

Code snippet

After Refactoring:

Code snippet

Moved methods from Response Controller to appropriate models

  • /*TODO for wiki Sorting review versions is not a controller responsibility; it would be better to do this in a model class (which class?) Ditto for determining whether a review is current (i.e., was done during the current assignment phase). This is a query that is made about a review (actually, about a response, which may be a review, author feedback, etc.). It should be placed in the appropriate model class.*/