CSC/ECE 517 Fall 2016/oss E1639: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
Line 27: Line 27:


== What needs to be done ==
== What needs to be done ==
1)  Refactor the update method to improve the functionality of checking the @map type.<br/>
1)  Refactor the update method which is too long and hard to read.<br/>
2)  Refactor the saving method to improve the case handling of selfReviewResponseMap<br/>
2)  Refactor the saving method to improve the case handling of selfReviewResponseMap<br/>
3)  Move new_feedback method from ResponseController to ReviewMappingController - ResponseController should only handle one kind of object<br/>
3)  Move new_feedback method from ResponseController to ReviewMappingController - ResponseController should only handle one kind of object<br/>
4)  Modified functional tests for new_feedback method<br/>
4)  Modified functional tests for new_feedback method<br/>
5)  Added functional test for update_method of response controller<br/>


== Solutions Implemented and Delivered ==
== Solutions Implemented and Delivered ==
Line 36: Line 37:
==='''Refactor the update method'''===
==='''Refactor the update method'''===


Update method is called when any kind of response is edited by the user. This method was very long and hard to read. It was checking the type of @map and performing various operations based on it using long if..elseif..else ladder. We implemented a function call to perform the type check operation, thus simplified the update method<br/>   
Update method is called when any kind of response is edited by the user. This method was very long and unreadable. It was checking the type of @map and round parameter to find out questionnaire  using long if..elseif..else ladder, which did not look neat and elegant. There was a helper method 'set_questionnaire' which was being called indirectly by the edit method for retrieving the questionnaire.We called the same function. The intuition behind using this same method was that if it is an update, user is not filling a new rubric and the response object should be available.We can find the questionnaire from the question_id in answers.Hence, in this way the if-else block was eliminated by calling the already available function.
Similarly, there were lines of code,which were creating score if not found or updating if an entry exists. The function 'create_answers' does exactly the same. Abiding by the DRY principle, we called this function which made the update method look concise and simplified. <br/>   


==='''Refactor the saving method'''===
==='''Refactor the saving method'''===

Revision as of 14:52, 28 October 2016

This wiki page describes changes made under E1639 OSS project assignment for Fall 2016, CSC/ECE 517.

Expertiza Background

Expertiza is a web application for educational purposes. It is an open source project based on Ruby on Rails framework. Expertiza has been created and maintained by faculty and students of NCSU. It helps teachers set up assignments for students who can then make submissions. Students can also review work of other students and give feedback to help incorporate improvements.

Project Description

The following OSS project deals mainly with the ResponseController. The goal of this project is make the code more readable, maintainable and to improve elegance of the code. We would like ResponseController to adhere to the DRY principle. It focuses on refactoring some of the more complex methods and removing some redundant code. At present, ResponseController has methods that would better be located in other controllers. The project relocates such methods to its appropriate Controller class.

Files modified

Following files were mainly modified for this project namely:
1. response_controller.rb
2. response_controller_spec.rb
3. review_mapping_controller.rb
4. review_mapping_controller_spec.rb
5. routes.rb
6. _reviews.html.erb
7. _scores_submitted_work.html.erb
8. _self_review.html.erb

ResponseController

Response controller manages the responses entered by users. When a user fills out any kind of rubric (review rubrics,author-feedback rubrics,teammate-review rubrics,quizzes,surveys), a response is generated. Responses come in different versions. Any time an author revises his/her work, and the reviewer reviews it again, a separate Response object is generated.Each Response object points to a particular ResponseMap, which provides details about reviewer, reviewee and reviewed entity.

What needs to be done

1) Refactor the update method which is too long and hard to read.
2) Refactor the saving method to improve the case handling of selfReviewResponseMap
3) Move new_feedback method from ResponseController to ReviewMappingController - ResponseController should only handle one kind of object
4) Modified functional tests for new_feedback method
5) Added functional test for update_method of response controller

Solutions Implemented and Delivered

Refactor the update method

Update method is called when any kind of response is edited by the user. This method was very long and unreadable. It was checking the type of @map and round parameter to find out questionnaire using long if..elseif..else ladder, which did not look neat and elegant. There was a helper method 'set_questionnaire' which was being called indirectly by the edit method for retrieving the questionnaire.We called the same function. The intuition behind using this same method was that if it is an update, user is not filling a new rubric and the response object should be available.We can find the questionnaire from the question_id in answers.Hence, in this way the if-else block was eliminated by calling the already available function. Similarly, there were lines of code,which were creating score if not found or updating if an entry exists. The function 'create_answers' does exactly the same. Abiding by the DRY principle, we called this function which made the update method look concise and simplified.

Refactor the saving method

Saving method is called to save the response when user edits any particular response or creates one. It was assigning params[:returs] to 'selfview' if the @map type is selfReponseMap. This params[:return] value was then further used in redirection method to handle the selfReviewResponseMap separately. We removed the assignment params[:return]= "selfreview" from save method. Rather we are directly passing the :return parameter value from edit and new methods of _self_review.html.erb, a view of SubmittedContent controller which handles the selfReview functionality.

Move new_feedback method from ResponseController to ReviewMappingController

new_feedback method is called when a user provides author feedback for any review. It was defined in the ResponseController earlier which was rather suspect. We moved the method to ReviewMappingController since ResponseController should only handle Response object, while new_feedback is dealing with FeedbackResponseMap object.


Modified functional tests for new_feedback method

We modified the test cases to accommodate changes of the new_feedback method and created new rspec file review_mapping_controller_rspec.rb