Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-13T01:13:13Z

Kjones15: /* Tasks Completed */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap (Ex: the 'edit' partial hasn't been updated in TextResponse yet). More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza. For more information refer to the Test Plan section below.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Test Plan ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made !! Test
|-
|1
|questionnaires_controller.rb
|
|-
|2
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
|Added comments - Provided functionality detail in the comments for all methods
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/checkbox_spec.rb Created RSpec testing for all methods]
|-
|3
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
|
*Replaced 'edit' method with partial
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/criterion_spec.rb Created RSpec testing for all methods, and different question scenarios]
|-
|4
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
|
*Replaced 'edit' method with partial
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/dropdown_spec.rb RSpec test - tests 4 methods]
|-
|5
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_checkbox_spec.rb RSpec test - all methods and different # of boxes selected]
|-
|6
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_radio_spec.rb RSpec test - different tests to make sure valid questions can be created]
|-
|7
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/scale_spec.rb RSpec test - tests all methods]
|-
|8
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_area_spec.rb RSpec test - tests all methods]
|-
|9
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_field_spec.rb RSpec test - tests all methods]
|-
|10
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]
|Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/upload_file.rb RSpec test - tests 2 methods]
|}

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality. For instance the name 'complete_first_second_input' might not be intuitive for some who didn't work on the code. The comment provides more insight into what will be displayed for each method.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
...
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
...
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
...
end

Overall, we met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable. Then we would like to get our code ready to merge into Expertiza.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-13T00:18:06Z

Kjones15: /* Plan of work */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap (Ex: the 'edit' partial hasn't been updated in TextResponse yet). More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza. For more information refer to the Test Plan section below.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Test Plan ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made !! Test
|-
|1
|questionnaires_controller.rb
|
|-
|2
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
|Added comments - Provided functionality detail in the comments for all methods
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/checkbox_spec.rb Created RSpec testing for all method]
|-
|3
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
|
*Replaced 'edit' method with partial
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/criterion_spec.rb Created RSpec testing for all method, and different question scenarios]
|-
|4
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
|
*Replaced 'edit' method with partial
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/dropdown_spec.rb RSpec test - tests 4 methods]
|-
|5
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_checkbox_spec.rb RSpec test - all methods and different # of boxes selected]
|-
|6
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_radio_spec.rb RSpec test - different tests to make sure valid questions can be created]
|-
|7
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/scale_spec.rb RSpec test - tests all methods]
|-
|8
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_area_spec.rb RSpec test - tests all methods]
|-
|9
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_field_spec.rb RSpec test - tests all methods]
|-
|10
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]
|Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/upload_file.rb RSpec test - tests 2 methods]
|}

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality. For instance the name 'complete_first_second_input' might not be intuitive for some who didn't work on the code. The comment provides more insight into what will be displayed for each method.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
...
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
...
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
...
end

Overall, we met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable. Then we would like to get our code ready to merge into Expertiza.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T22:39:24Z

Kjones15: /* Design Goals */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza. For more information refer to the Test Plan section below.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Test Plan ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made !! Test
|-
|1
|questionnaires_controller.rb
|
|-
|2
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
|Added comments - Provided functionality detail in the comments for all methods
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/checkbox_spec.rb Created RSpec testing for all method]
|-
|3
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
|
*Replaced 'edit' method with partial
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/criterion_spec.rb Created RSpec testing for all method, and different question scenarios]
|-
|4
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
|
*Replaced 'edit' method with partial
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/dropdown_spec.rb RSpec test - tests 4 methods]
|-
|5
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_checkbox_spec.rb RSpec test - all methods and different # of boxes selected]
|-
|6
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_radio_spec.rb RSpec test - different tests to make sure valid questions can be created]
|-
|7
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/scale_spec.rb RSpec test - tests all methods]
|-
|8
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_area_spec.rb RSpec test - tests all methods]
|-
|9
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_field_spec.rb RSpec test - tests all methods]
|-
|10
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]
|Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/upload_file.rb RSpec test - tests 2 methods]
|}

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality. For instance the name 'complete_first_second_input' might not be intuitive for some who didn't work on the code. The comment provides more insight into what will be displayed for each method.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
...
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
...
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
...
end

Overall, we met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable. Then we would like to get our code ready to merge into Expertiza.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T22:37:25Z

Kjones15: /* Tests */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Test Plan ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made !! Test
|-
|1
|questionnaires_controller.rb
|
|-
|2
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
|Added comments - Provided functionality detail in the comments for all methods
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/checkbox_spec.rb Created RSpec testing for all method]
|-
|3
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
|
*Replaced 'edit' method with partial
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/criterion_spec.rb Created RSpec testing for all method, and different question scenarios]
|-
|4
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
|
*Replaced 'edit' method with partial
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/dropdown_spec.rb RSpec test - tests 4 methods]
|-
|5
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_checkbox_spec.rb RSpec test - all methods and different # of boxes selected]
|-
|6
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_radio_spec.rb RSpec test - different tests to make sure valid questions can be created]
|-
|7
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/scale_spec.rb RSpec test - tests all methods]
|-
|8
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_area_spec.rb RSpec test - tests all methods]
|-
|9
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_field_spec.rb RSpec test - tests all methods]
|-
|10
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]
|Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/upload_file.rb RSpec test - tests 2 methods]
|}

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality. For instance the name 'complete_first_second_input' might not be intuitive for some who didn't work on the code. The comment provides more insight into what will be displayed for each method.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
...
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
...
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
...
end

Overall, we met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable. Then we would like to get our code ready to merge into Expertiza.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T22:36:46Z

Kjones15: /* Next Steps */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made !! Test
|-
|1
|questionnaires_controller.rb
|
|-
|2
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
|Added comments - Provided functionality detail in the comments for all methods
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/checkbox_spec.rb Created RSpec testing for all method]
|-
|3
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
|
*Replaced 'edit' method with partial
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/criterion_spec.rb Created RSpec testing for all method, and different question scenarios]
|-
|4
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
|
*Replaced 'edit' method with partial
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/dropdown_spec.rb RSpec test - tests 4 methods]
|-
|5
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_checkbox_spec.rb RSpec test - all methods and different # of boxes selected]
|-
|6
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_radio_spec.rb RSpec test - different tests to make sure valid questions can be created]
|-
|7
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/scale_spec.rb RSpec test - tests all methods]
|-
|8
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_area_spec.rb RSpec test - tests all methods]
|-
|9
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_field_spec.rb RSpec test - tests all methods]
|-
|10
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]
|Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/upload_file.rb RSpec test - tests 2 methods]
|}

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality. For instance the name 'complete_first_second_input' might not be intuitive for some who didn't work on the code. The comment provides more insight into what will be displayed for each method.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
...
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
...
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
...
end

Overall, we met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable. Then we would like to get our code ready to merge into Expertiza.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T22:35:53Z

Kjones15: /* Tasks Completed */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made !! Test
|-
|1
|questionnaires_controller.rb
|
|-
|2
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
|Added comments - Provided functionality detail in the comments for all methods
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/checkbox_spec.rb Created RSpec testing for all method]
|-
|3
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
|
*Replaced 'edit' method with partial
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/criterion_spec.rb Created RSpec testing for all method, and different question scenarios]
|-
|4
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
|
*Replaced 'edit' method with partial
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/dropdown_spec.rb RSpec test - tests 4 methods]
|-
|5
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_checkbox_spec.rb RSpec test - all methods and different # of boxes selected]
|-
|6
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_radio_spec.rb RSpec test - different tests to make sure valid questions can be created]
|-
|7
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/scale_spec.rb RSpec test - tests all methods]
|-
|8
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_area_spec.rb RSpec test - tests all methods]
|-
|9
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_field_spec.rb RSpec test - tests all methods]
|-
|10
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]
|Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/upload_file.rb RSpec test - tests 2 methods]
|}

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality. For instance the name 'complete_first_second_input' might not be intuitive for some who didn't work on the code. The comment provides more insight into what will be displayed for each method.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
...
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
...
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
...
end

Overall, we met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T22:33:52Z

Kjones15: /* Tasks Completed */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made !! Test
|-
|1
|questionnaires_controller.rb
|
|-
|2
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
|Added comments - Provided functionality detail in the comments for all methods
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/checkbox_spec.rb Created RSpec testing for all method]
|-
|3
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
|
*Replaced 'edit' method with partial
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/criterion_spec.rb Created RSpec testing for all method, and different question scenarios]
|-
|4
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
|
*Replaced 'edit' method with partial
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/dropdown_spec.rb RSpec test - tests 4 methods]
|-
|5
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_checkbox_spec.rb RSpec test - all methods and different # of boxes selected]
|-
|6
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_radio_spec.rb RSpec test - different tests to make sure valid questions can be created]
|-
|7
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
|
*Replaced 'edit' method with partial
*Updated comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/scale_spec.rb RSpec test - tests all methods]
|-
|8
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_area_spec.rb RSpec test - tests all methods]
|-
|9
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_field_spec.rb RSpec test - tests all methods]
|-
|10
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]
|Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/upload_file.rb RSpec test - tests 2 methods]
|}

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
...
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
...
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
...
end

Overall, we met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T22:32:10Z

Kjones15: /* Tasks Completed */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made !! Test
|-
|1
|questionnaires_controller.rb
|
|-
|2
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
|Added comments - Provided functionality detail in the comments for all methods
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/checkbox_spec.rb Created RSpec testing for all method]
|-
|3
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
|
*Replaced 'edit' method with partial
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/criterion_spec.rb Created RSpec testing for all method, and different question scenarios]
|-
|4
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
|
*Replaced 'edit' method with partial
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/dropdown_spec.rb RSpec test - tests 4 methods]
|-
|5
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_checkbox_spec.rb RSpec test - all methods and different # of boxes selected]
|-
|6
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_radio_spec.rb RSpec test - different tests to make sure valid questions can be created]
|-
|7
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/scale_spec.rb RSpec test - tests all methods]
|-
|8
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_area_spec.rb RSpec test - tests all methods]
|-
|9
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_field_spec.rb RSpec test - tests all methods]
|-
|10
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]
|Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/upload_file.rb RSpec test - tests 2 methods]
|}

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
...
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
...
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
...
end

Overall, we met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T15:06:27Z

Kjones15: /* Tests */ Removed list (added to table)

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made !! Test
|-
|1
|questionnaires_controller.rb
|
|-
|2
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
|Added comments - Provided functionality detail in the comments for all methods
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/checkbox_spec.rb Created RSpec testing for all method]
|-
|3
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
|
*Replaced 'edit' method with partial
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/criterion_spec.rb Created RSpec testing for all method, and different question scenarios]
|-
|4
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
|
*Replaced 'edit' method with partial
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/dropdown_spec.rb RSpec test]
|-
|5
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_checkbox_spec.rb RSpec test]
|-
|6
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_radio_spec.rb RSpec test]
|-
|7
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/scale_spec.rb RSpec test]
|-
|8
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_area_spec.rb RSpec test]
|-
|9
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_field_spec.rb RSpec test]
|-
|10
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]
|Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/upload_file.rb RSpec test]
|}

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
...
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
...
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
...
end

Overall, we met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T15:05:56Z

Kjones15: /* Tasks Completed */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made !! Test
|-
|1
|questionnaires_controller.rb
|
|-
|2
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
|Added comments - Provided functionality detail in the comments for all methods
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/checkbox_spec.rb Created RSpec testing for all method]
|-
|3
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
|
*Replaced 'edit' method with partial
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/criterion_spec.rb Created RSpec testing for all method, and different question scenarios]
|-
|4
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
|
*Replaced 'edit' method with partial
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/dropdown_spec.rb RSpec test]
|-
|5
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_checkbox_spec.rb RSpec test]
|-
|6
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/multiple_choice_radio_spec.rb RSpec test]
|-
|7
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/scale_spec.rb RSpec test]
|-
|8
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_area_spec.rb RSpec test]
|-
|9
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/text_field_spec.rb RSpec test]
|-
|10
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]
|Added comments - none existed previously
|[https://github.com/pparghod/reimplementation-back-end/blob/main/spec/models/upload_file.rb RSpec test]
|}

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
...
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
...
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
...
end

Overall, we met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T14:56:08Z

Kjones15: /* Tasks Completed */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made
|-
|1
|questionnaires_controller.rb
|
|-
|2
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
|Added comments - Provided functionality detail in the comments for all methods
|-
|3
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
|
*Replaced 'edit' method with partial
|-
|4
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
|
*Replaced 'edit' method with partial
*Added comments - none existed previously
|-
|5
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|-
|6
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|-
|7
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|-
|8
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|-
|9
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|-
|10
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]
|Added comments - none existed previously
|}

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
...
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
...
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
...
end

Overall, we met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T14:55:45Z

Kjones15: /* Tasks Completed */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made
|-
|1
|questionnaires_controller.rb
|
|-
|2
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
|Added comments - Provided functionality detail in the comments for all methods
|-
|3
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
|
*Replaced 'edit' method with partial
|-
|4
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
|
*Replaced 'edit' method with partial
*Added comments - none existed previously
|-
|5
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|-
|6
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|-
|7
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|-
|8
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|-
|9
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|-
|10
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]
|Added comments - none existed previously
|}

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
...
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
...
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
...
end

We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T14:53:23Z

Kjones15: /* Design Goals */ Moving example comment to different section

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made
|-
|1
|questionnaires_controller.rb
|
|-
|2
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
|Added comments - Provided functionality detail in the comments for all methods
|-
|3
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
|
*Replaced 'edit' method with partial
|-
|4
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
|
*Replaced 'edit' method with partial
*Added comments - none existed previously
|-
|5
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|-
|6
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|-
|7
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|-
|8
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|-
|9
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|-
|10
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]
|Added comments - none existed previously
|}

We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T14:52:05Z

Kjones15: /* Tasks Completed */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made
|-
|1
|questionnaires_controller.rb
|
|-
|2
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
|Added comments - Provided functionality detail in the comments for all methods
|-
|3
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
|
*Replaced 'edit' method with partial
|-
|4
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
|
*Replaced 'edit' method with partial
*Added comments - none existed previously
|-
|5
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|-
|6
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|-
|7
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
|
*Replaced 'edit' method with partial
*Update comments - more details in how all functions work
|-
|8
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|-
|9
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
|
*Added partial to 'complete' method
*Added comments - none existed previously
|-
|10
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]
|Added comments - none existed previously
|}

We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T14:41:07Z

Kjones15: /* Tasks Completed */ Added table for all of the changes

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made
|-
|1
|questionnaires_controller.rb
|
|-
|2
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
|Updated comments
|-
|3
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
|
*Replaced 'edit' method with partial
*Updated comments
|-
|4
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
|
*Replaced 'edit' method with partial
*Updated comments
|-
|5
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
|
*Replaced 'edit' method with partial
*Updated comments
|-
|6
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
|
*Replaced 'edit' method with partial
*Updated comments
|-
|7
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
|
*Replaced 'edit' method with partial
*Updated comments
|-
|8
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
|
*Added partial to 'complete' method
*Updated comments
|-
|9
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
|
*Added partial to 'complete' method
*Updated comments
|-
|10
|[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]
|Updated comments
|}

We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T14:22:35Z

Kjones15: /* Design Goals */ removed links from design goal section

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made !! Purpose
|-
|1
|questionnaires_controller.rb
|
|
|-
|2
|checkbox.rb
|All the methods were given in depth comments
|Better explain functionality
|}

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T14:21:53Z

Kjones15: /* Tasks Completed */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

The list shown below shows the current files where we have updated comments:
*questionnaires_controller.rb
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made !! Purpose
|-
|1
|questionnaires_controller.rb
|
|
|-
|2
|checkbox.rb
|All the methods were given in depth comments
|Better explain functionality
|}

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-12T14:21:30Z

Kjones15: /* Tasks Completed */ Started making table for changes

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

The list shown below shows the current files where we have updated comments:
*questionnaires_controller.rb
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

The table below highlights the work we have completed so far:

{| class="wikitable" style="width: 100%;
!  #  !! File !! Changes Made !! Purpose
|-
|1
|questionnaires_controller.rb
|
|
|-
|2
|checkbox.rb
|All the methods were given in depth comments
|Better explain functionality

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-11T21:16:26Z

Kjones15: /* Design Goals */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

The list shown below shows the current files where we have updated comments:
*questionnaires_controller.rb
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass. An example of a partial we created can be seen [https://github.com/pparghod/reimplementation-back-end/blob/main/app/views/questionnaire/edit/_edit_dropdown.erb here], where we made a partial for code that displays an edit input for dropdown questions. Thanks to this partial, in the future if we ever need to call this code again we can just [https://github.com/pparghod/reimplementation-back-end/blob/20093dcb23750c94a9c32803914e1506c9ae556e/app/models/dropdown.rb#L7 call the partial], reducing the number of lines of code and reducing redundancy.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls and overlap. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-11T21:03:24Z

Kjones15: /* Design Goals */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

The list shown below shows the current files where we have updated comments:
*questionnaires_controller.rb
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass.

Moving forward for program 4 we plan on making a question controller to further consolidate the changes, since there currently remain some redundant calls. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-11T21:01:45Z

Kjones15: /* Plan of work */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

The list shown below shows the current files where we have updated comments:
*questionnaires_controller.rb
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass.

Moving forward for program 4 we plan on making a a question controller to further consolidate the changes, since there currently remain some redundant calls. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-11T20:59:02Z

Kjones15: /* UML Diagram */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and also peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

The list shown below shows the current files where we have updated comments:
*questionnaires_controller.rb
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass.

Moving forward for program 4 we plan on making a a question controller to further consolidate the changes, since there currently remain some redundant calls. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1200px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-11T20:58:06Z

Kjones15: /* Explanation of Feature - Question Hierarchy */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and also peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

The list shown below shows the current files where we have updated comments:
*questionnaires_controller.rb
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass.

Moving forward for program 4 we plan on making a a question controller to further consolidate the changes, since there currently remain some redundant calls. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1400px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-11T20:57:39Z

Kjones15: /* Explanation of Feature - Question Hierarchy */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Below is a written explanation of the hierarchy. For a visual reference, refer to the [[#UML_Diagram UML Diagram]]:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and also peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

The list shown below shows the current files where we have updated comments:
*questionnaires_controller.rb
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass.

Moving forward for program 4 we plan on making a a question controller to further consolidate the changes, since there currently remain some redundant calls. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1400px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-11T20:51:09Z

Kjones15: /* Plan of work */ Added links for code references

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Here is the hierarchy:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and also peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments before this project, and any existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

The list shown below shows the current files where we have updated comments:
*questionnaires_controller.rb
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/criterion.rb criterion.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/dropdown.rb dropdown.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_checkbox.rb multiple_choice_checkbox.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/multiple_choice_radio.rb multiple_choice_radio.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/scale.rb scale.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_area.rb text_area.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/text_field.rb text_field.rb]
*[https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/upload_file.rb upload_file.rb]

Given below is an example of the comments we've added to clarify what the methods are doing, because the method name alone can be confusing. These changes give specifics into the methods functionality.

From [https://github.com/pparghod/reimplementation-back-end/blob/main/app/models/checkbox.rb checkbox.rb]:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we started adding partials by looking at the similarities between all three question types and pulling out the similarities into partials which we stored in [https://github.com/pparghod/reimplementation-back-end/tree/main/app/views 'app/views']. Then we made calls to these partials from within each subclass.

Moving forward for program 4 we plan on making a a question controller to further consolidate the changes, since there currently remain some redundant calls. More information is explained below:
* We plan on making a class with a name like: 'Question_Controller'.
* This class will store all of the partials we have made so far and any additional partials we need to create.
* Then we will update any calls to a partial to just call the singular 'Question_Controller' - this will keep all the partials in once central location and DRY out the code to follow better design.

'''3. Test Edge Cases'''

The last goal we have for program 4 is to include additional tests to cover any edge cases we missed in program 3. This will help us ensure that we can merge our changes successfully with Expertiza.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy to better give an idea of it's structure. This diagram reflects all of the recent changes we have made after program 3. (Click on the image to zoom in)

[[File:E2320-UML.png|1400px]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-11T20:25:22Z

Kjones15: /* UML Diagram */ Size adjustment

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Here is the hierarchy:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and also peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments, and existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

The files listed below have been updated with new comments:
*questionnaires_controller.rb
*checkbox.rb
*criterion.rb
*dropdown.rb
*multiple_choice_checkbox.rb
*multiple_choice_radio.rb
*scale.rb
*text_area.rb
*text_field.rb
*text_response.rb
*upload_file.rb

Given below is an example of the comments we've added to clarify what the methods are doing because the method name alone can be confusing.
From checkbox.rb:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we added partials by looking at the similarities between all three question types and pulling out the similarities into new classes.

Moving forward for program 4 we plan on making a a question controller to further consolidate the changes.
*Ex: Question_Controller - Since all of the sub-categories inherit from the Question class we plan to make a question controller to hold all of the common functionality.

One example of this can be seen with the method call 'edit' which exists in many of the subclasses like text_response.rb, text_area.rb, scale.rb, and criterion.rb. The partials will be moved into the question controller.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy. (Click on the image to zoom in)

[[File:E2320-UML.png|1000px]]

A few notes about the hierarchy:
*

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-11T20:24:41Z

Kjones15: /* UML Diagram */ Added the diagram

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Here is the hierarchy:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and also peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments, and existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

The files listed below have been updated with new comments:
*questionnaires_controller.rb
*checkbox.rb
*criterion.rb
*dropdown.rb
*multiple_choice_checkbox.rb
*multiple_choice_radio.rb
*scale.rb
*text_area.rb
*text_field.rb
*text_response.rb
*upload_file.rb

Given below is an example of the comments we've added to clarify what the methods are doing because the method name alone can be confusing.
From checkbox.rb:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we added partials by looking at the similarities between all three question types and pulling out the similarities into new classes.

Moving forward for program 4 we plan on making a a question controller to further consolidate the changes.
*Ex: Question_Controller - Since all of the sub-categories inherit from the Question class we plan to make a question controller to hold all of the common functionality.

One example of this can be seen with the method call 'edit' which exists in many of the subclasses like text_response.rb, text_area.rb, scale.rb, and criterion.rb. The partials will be moved into the question controller.

=== UML Diagram ===
Below is a diagram showing the overall Question hierarchy. (Click on the image to zoom in)

[[File:E2320-UML.png|850px]]

A few notes about the hierarchy:
*

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

File:E2320-UML.png

2023-04-11T20:18:43Z

Kjones15: A png of E2320 UML diagram for the design doc

A png of E2320 UML diagram for the design doc

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-11T17:03:52Z

Kjones15:

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Here is the hierarchy:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and also peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments, and existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

The files listed below have been updated with new comments:
*questionnaires_controller.rb
*checkbox.rb
*criterion.rb
*dropdown.rb
*multiple_choice_checkbox.rb
*multiple_choice_radio.rb
*scale.rb
*text_area.rb
*text_field.rb
*text_response.rb
*upload_file.rb

Given below is an example of the comments we've added to clarify what the methods are doing because the method name alone can be confusing.
From checkbox.rb:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we added partials by looking at the similarities between all three question types and pulling out the similarities into new classes.

Moving forward for program 4 we plan on making a a question controller to further consolidate the changes.
*Ex: Question_Controller - Since all of the sub-categories inherit from the Question class we plan to make a question controller to hold all of the common functionality.

One example of this can be seen with the method call 'edit' which exists in many of the subclasses like text_response.rb, text_area.rb, scale.rb, and criterion.rb. The partials will be moved into the question controller.

=== UML Diagram ===
[[File:Example.jpg]]

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-11T15:54:57Z

Kjones15: /* Design Goals */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Here is the hierarchy:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and also peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments, and existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

The files listed below have been updated with new comments:
*questionnaires_controller.rb
*checkbox.rb
*criterion.rb
*dropdown.rb
*multiple_choice_checkbox.rb
*multiple_choice_radio.rb
*scale.rb
*text_area.rb
*text_field.rb
*text_response.rb
*upload_file.rb

Given below is an example of the comments we've added to clarify what the methods are doing because the method name alone can be confusing.
From checkbox.rb:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. For program 3 we added partials by looking at the similarities between all three question types and pulling out the similarities into new classes.

Moving forward for program 4 we plan on making a a question controller to further consolidate the changes.
*Ex: Question_Controller - Since all of the sub-categories inherit from the Question class we plan to make a question controller to hold all of the common functionality.

One example of this can be seen with the method call 'edit' which exists in many of the subclasses like text_response.rb, text_area.rb, scale.rb, and criterion.rb. The partials will be moved into the question controller.

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-11T15:43:38Z

Kjones15: /* Problem Statement */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Here is the hierarchy:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code.
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and also peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments, and existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

The files listed below have been updated with new comments:
*questionnaires_controller.rb
*checkbox.rb
*criterion.rb
*dropdown.rb
*multiple_choice_checkbox.rb
*multiple_choice_radio.rb
*scale.rb
*text_area.rb
*text_field.rb
*text_response.rb
*upload_file.rb

Given below is an example of the comments we've added to clarify what the methods are doing because the method name alone can be confusing.
From checkbox.rb:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. We added partials by looking at the similarities between all three question types and pull out the similarities into a new class.
*Ex: Question_Controller - Since all of the sub-categories inherit from the Question class we plan to make a question controller to hold all of the common functionality. One example of this can be seen with the method call 'edit' which exists in many of the subclasses like text_response.rb, text_area.rb, scale.rb, and criterion.rb. The partials will be moved into the question controller.

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-11T15:42:59Z

Kjones15: /* Goals */

Design Doc

==Problem Statement==
The current implementation of the question hierarchy is not very clean and contains confusing variable and method names. Also, many methods return long HTML strings which are difficult to read. The goal of this project is to reimplement this part of the application to make it more readable, understandable and maintainable.

===Explanation of Feature - Question Hierarchy===
The Question class and its sub-classes are used to implement all rubric items, quiz questions, and survey questions in Expertiza. For example, a professor could use this feature to make up a review quiz for their class. There are 3 main types of questions in Experitza: scored, unscored, and upload file.

Here is the hierarchy:

'''1. Choice question''' - Choice questions are types of questions that give the quiz taker a list of answers to choose from. It is broken into two subcategories scored and unscored.
* Scored question - will give a number value depending upon if a user clicks on a particular answer.
** Scale
** Criterion
* Unscored question - Do not have a score associated with them and come in 3 styles.
** Dropdown - only shows the answer choices after the user clicks on the dropdown arrow and clicks on an answer.
** Multiple Choice - Presents all the answers choices with a selectable bubble beside them. The user clicks on the bubble to indicate their answer.
** Check Box - The user must click on a certain number of check boxes beside the answers they think are correct.

'''2. Text Response''' - Allow the user to actually type in their answer instead of just being provided answers.
* Text Area - Question box has a height and width associated with it that can be adjusted.
* Text Field - 1 input line that does not change shape.

'''3. Upload File''' -
The last type of question is upload file which allows the user to upload a file to use as a quiz (as the name suggests). This option allows a person to upload a pre-made quiz document to be which will be converted into a quiz. So, a professor could type up their quiz questions and answers in a text file then choose upload and have Expertiza convert it into a quiz for them.

===Purpose & Goals===
The overall purpose of this project is to clean up the existing classes so that future developers will have an easy time picking up the existing code, be able to understand it, and be able to add additional functionality with no problem.

The goals of the project include:
* Improvement of variables and methods names - to give accurate representation of their functionality.
* Included comments for further clarification - we want someone who didn't work on this project to be able to pick up the code and understand what is going on.
* Implement partials to deal with the HTML strings - this will DRY up the code
* Add RSpec test cases - ensure existing tests work and also account for edge cases.

==Plan of work==

Based on the feedback provided to us by both our mentors and also peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
'''1. Update code comments'''

Some methods and classes had little to no comments, and existing comments were not in depth enough to give proper context for functionality. One of our design goals is to write more in depth comments that better explain functionality for the code.

The files listed below have been updated with new comments:
*questionnaires_controller.rb
*checkbox.rb
*criterion.rb
*dropdown.rb
*multiple_choice_checkbox.rb
*multiple_choice_radio.rb
*scale.rb
*text_area.rb
*text_field.rb
*text_response.rb
*upload_file.rb

Given below is an example of the comments we've added to clarify what the methods are doing because the method name alone can be confusing.
From checkbox.rb:

'''# Returns what to display for the first and second inputs (comments and scores).'''
def complete_first_second_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_comments\" name=\"responses[#{count.to_s}][comment]\" type=\"hidden\" value=\"\">"
html += "<input id=\"responses_#{count.to_s}_score\" name=\"responses[#{count.to_s}][score]\" type=\"hidden\""
html += if !answer.nil? && (answer.answer == 1)
'value="1"'
else
'value="0"'
end
html += '>'
html
end

'''# Returns what to display for the third input (the checkbox itself).'''
def complete_third_input(count, answer = nil)
html = "<input id=\"responses_#{count.to_s}_checkbox\" type=\"checkbox\" onchange=\"checkbox#{count.to_s}Changed()\""
html += 'checked="checked"' if !answer.nil? && (answer.answer == 1)
html += '>'
html
end

'''# Create the executable script for client-side interaction on the checkbox'''
def complete_script(count)
html = "<script>function checkbox#{count.to_s}Changed() {"
html += " var checkbox = jQuery(\"#responses_#{count.to_s}_checkbox\");"
html += " var response_score = jQuery(\"#responses_#{count.to_s}_score\");"
html += 'if (checkbox.is(":checked")) {'
html += 'response_score.val("1");'
html += '} else {'
html += 'response_score.val("0");}}</script>'
html
end

'''2. DRY out code with partials'''

Another one of our design goals is to implement additional partials for the question types. We added partials by looking at the similarities between all three question types and pull out the similarities into a new class.
*Ex: Question_Controller - Since all of the sub-categories inherit from the Question class we plan to make a question controller to hold all of the common functionality. One example of this can be seen with the method call 'edit' which exists in many of the subclasses like text_response.rb, text_area.rb, scale.rb, and criterion.rb. The partials will be moved into the question controller.

== Tests ==

'''RSpec'''

We reimplemented the test cases to match the changes we've made to the question-related models. Front-end testing wasn't necessary because our project doesn't involve changing any controller.

The most notable models that were tested are:
checkbox.rb
criterion.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
scale.rb
text_area.rb
text_field.rb
text_response.rb
upload_file.rb

One of the primary goals we had were to make sure that the existing tests still passed. Several tests were removed for the edit methods in a few of the models (such as checkbox_spec.rb and dropdown_spec.rb) because those methods were replaced with partials. Partials have not been fully implemented which is why we did not include tests for them. However, this is something that should be revisited in the future.

Given below is an example of the tests we've written:
describe Dropdown do
let!(:dropdown) { Dropdown.create(id: 4, type: 'Dropdown', seq: 4.0, txt: 'Test text', weight: 13) }
let!(:answer) { Answer.create(id: 1, question_id: 4, questionnaire_type_id: 1, answer: 1, comments: "Test comment") }
describe '#view_question_text' do
it 'returns the html' do
html = dropdown.view_question_text
expect(html).to eq('<TR><TD align="left"> Test text </TD><TD align="left">Dropdown</TD><td align="center">13</TD><TD align="center">—</TD></TR>')
end
end
describe '#view_completed_question' do
it 'returns the html' do
html = dropdown.view_completed_question(1, answer)
expect(html).to eq('<nowiki><b></nowiki>1. Test text<nowiki></b><BR></nowiki>&nbsp&nbsp&nbsp&nbspTest comment')
end
end
describe '#complete_for_alternatives' do
it 'returns the html' do
alternatives = ['Alternative 1', 'Alternative 2', 'Alternative 3']
html = dropdown.complete_for_alternatives(alternatives, answer)
expect(html).to eq('<option value="Alternative 1">Alternative 1</option><option value="Alternative 2">Alternative 2</option><option value="Alternative 3">Alternative 3</option>')
end
end
describe '#complete' do
it 'returns the html' do
alternatives = ['Alternative 1|Alternative 2|Alternative 3']
allow(dropdown).to receive(:alternatives).and_return(alternatives)
allow(dropdown).to receive(:complete_for_alternatives).and_return('')
html = dropdown.complete(1, answer)
<nowiki>expect(html).to eq('<p style="width: 80%;"><label for="responses_1"">Test text  </label>'
+ '<input id="responses_1_score" name="responses[1][score]" type="hidden" value="" style="min-width: 100px;">'
+ '<select id="responses_1_comments" label=Test text name="responses[1][comment]"></select></p>')</nowiki>
end
end
end

Given below is the full list of tests:

[[File:E2320-RSpec.png]]

==Conclusions==
===Tasks Completed===
We met our goals of adding comments and improving the names of methods and variables to make the code easily understandable to the user. We implemented several partials to handle the HTML strings and added RSpec test cases. We cleaned up the unused comments/code to make the code readable and understandable.

===Next Steps===
In the future, we would like to fully implement partials and thoroughly test them. We believe partials will improve the code by making it more readable and reusable.

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode
==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]
#[https://github.com/expertiza/reimplementation-back-end/pull/10 Link to initial pull request]
#[https://github.com/users/pparghod/projects/2/views/1 GitHub Project Board]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-11T15:32:10Z

Kjones15: /* Explanation of Feature - Question Hierarchy */

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-10T23:15:32Z

Kjones15: /* Problem Statement */

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-07T21:46:33Z

Kjones15: /* Tests */

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-07T21:20:12Z

Kjones15: /* Design Goals */ Added more detail for the goals

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-07T20:46:09Z

Kjones15: /* Explanation of Feature - Question Hierarchy */ Added more detail for feature

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-07T16:54:34Z

Kjones15: /* Explanation of Feature - Question Hierarchy */

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-05T22:10:05Z

Kjones15: Added ack. and references

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-05T22:08:43Z

Kjones15: /* Problem Statement */

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-05T22:08:03Z

Kjones15: /* Explanation of Feature */

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-05T22:06:40Z

Kjones15: /* Statement Problem */

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-05T22:05:59Z

Kjones15: /* Design Goals */

Design Doc

===Statement Problem===

===Explanation of Feature===

===List of Work Done so Far===

==Plan of work==

Based on the feedback provided to us by both our mentors and also peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
* Update code comments - Some methods and classes currently do not have any code comments, while other comments are not in depth enough to give proper context for functionality. One of our design goals will be to write more in depth comments that better explain functionality for the code.
* DRY out code with partials - Implement additional partials for certain classes. Ex: Question_Controller

===Tests===

==Conclusions / Future Work==
===Specific Tasks Completed===
[Will be updated near final submission deadline]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-05T22:03:14Z

Kjones15: /* Plan of work */

Design Doc

===Statement Problem===

===Explanation of Feature===

===List of Work Done so Far===

==Plan of work==

Based on the feedback provided to us by both our mentors and also peer reviews our team has decided upon a few key design goals to work on for the continuation of our work into Program 4. These goals are outlined below.

===Design Goals===
* Update code comments - Write more in depth comments which better explain functionality for the code.
* DRY out code with partials - Implement additional partials for certain classes. Ex: Question_Controller

===Tests===

==Conclusions / Future Work==
===Specific Tasks Completed===
[Will be updated near final submission deadline]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-05T22:01:46Z

Kjones15: /* Conclusions / Future Work */

Design Doc

===Statement Problem===

===Explanation of Feature===

===List of Work Done so Far===

==Plan of work==
===Design Goals===
* Update code comments - Write more in depth comments which better explain functionality for the code.
* DRY out code with partials - Implement additional partials for certain classes. Ex: Question_Controller

===Tests===

==Conclusions / Future Work==
===Specific Tasks Completed===
[Will be updated near final submission deadline]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-05T22:00:37Z

Kjones15: /* Plan of work */ starting to add goals

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-05T21:57:14Z

Kjones15: Fixed heading

Design Doc

===Statement Problem===

===Explanation of Feature===

===List of Work Done so Far===

===Plan of work===

===Tests===

===Conclusions / Future Work===

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-05T21:56:52Z

Kjones15: Added outline of key topics

Design Doc

===Statement Problem===

===Explanation of Feature===

===List of Work Done so Far===

===Plan of work===

==Tests===

===Conclusions / Future Work===

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question Hierarchy

2023-04-05T21:51:46Z

Kjones15: Created page with "Design Doc"

Design Doc

CSC/ECE 517 Spring 2023

2023-04-05T21:50:27Z

Kjones15: Added E2320 link

== OSS Projects ==
[[CSC/ECE 517 Spring_2023 -E2306. Refactor user_controller.rb, user.rb and its child classes]]

[[CSC/ECE 517 Spring_2023 - E2320. Reimplement the Question hierarchy]]

[[CSC/ECE 517 Spring_2023 - E2312 + E2313. Reimplement response.rb and responses_controller.rb]]

[[CSC/ECE 517 Spring_2023 - NTNX-1. Support provisioning MongoDb via NDB Kubernetes Operator]]

[[CSC/ECE 517 Spring_2023 - E2316. Reimplement sign_up_sheet_controller.rb]]

[[CSC/ECE 517 Spring_2023 - E2315. Reimplement signed_up_team.rb, sign_up_topic.rb, sign_up_sheet.rb]]

[[CSC/ECE 517 Spring_2023 - E2339. Reimplement signed_up_team.rb, sign_up_topic.rb, sign_up_sheet.rb (Project 4)]]

[[CSC/ECE 517 Spring_2023 - E2323. Refactor DueDate functionality from assignment.rb]]

[[CSC/ECE 517 Spring 2023 - E2317: Reimplement participant.rb]]

[[CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy]]

[[CSC/ECE 517 Spring 2023- NTNX-4. Extend NDB operator provision postregresql aws]]

[[CSC/ECE 517 Spring 2023 - E2321. Reimplement QuestionnairesController and QuestionsController]]

[[CSC/ECE 517 Spring 2023 - E2305. Grading audit trail]]

[[CSC/ECE 517 Spring 2023 - E2309. Refactor Node model and its subclasses]]

[[CSC/ECE 517 Spring 2023 - NTNX-2. Support provisioning mySQL databases via NDB Kubernetes Operator]]

[[CSC/ECE 517 Spring 2023 - E2300. Refactor E1858. Github metrics integration]]

[[CSC/ECE 517 Sping 2023 - E2322: Refactor Questionnaire View to display Bookmark Rating]]

[[CSC/ECE 517 Spring 2023 - NTNX-3. Refactor models to keep profiles (software, compute, network, etc) as optional and use default if not specified]]

[[CSC/ECE_517_Spring_2023_-_E2301._Refactor_review_maping_helper]]

[[CSC/ECE_517_Spring_2023_-_E2337._Reimplement_node_hierarchy]]

[[CSC/ECE_517_Spring_2023_-_E2320._Reimplement the Question Hierarchy]]