Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2023 - E2343. Questionnaire UI

2023-04-26T02:46:52Z

Mefergio: /* Testing & Test Plan */

= Project Overview and Justification =

The major crux of the reimplementation of Expertiza is the splitting of Expertiza into a [https://github.com/expertiza/reimplementation-front-end React Front-End] with a [https://github.com/expertiza/reimplementation-back-end Ruby Back-End]. This split should yield a simplification of the code base, and make it easier for developers to make changes if the Expertiza environment isn’t as tightly coupled as before the split. The two ends should interact in terms of the RESTful endpoints, thus separating the implementation of the back-end from the front-end makes both ends more flexible.

Later, when the reimplemented [https://github.com/expertiza/reimplementation-back-end Ruby Back-End] is production-ready, it will be connected to the [https://github.com/expertiza/reimplementation-front-end React Front-End].

React is sound choice for the Expertiza front-end to be reimplemented with because it is flexible, allows reusing components, and is easy for multiple developers to work on at once which boosts the speed of development. Additionally, React was designed with high performance in mind leveraging a framework that allows complex applications run incredibly fast. Due to these benefits, and the bonus that it is easy to learn, a strong interface can be developed quickly for the back-end to integrate with.

The goal of this project is to re-implement the front-end for Questionnaires in React for it to later be connected to the back-end questionnaires_controller and questionnaire model when these back-end reimplementations are production-ready.

'''Important note: This project does not have any back-end functionality whatsoever. There are no controllers or methods implemented. This is a reimplementation of the questionnaire user interface intended for the back-end questionnaire reimplementation that other project teams are working on to eventually connect to. Since there is no back-end with a database, this UI implementation will use dummy JSON objects to replicate the behavior of a back-end database.'''

= UI Flow =

The below diagram shows how users will interact and move through the questionnaire user interface:

[[File:Questionnaire_UI_flow.png||700px]]

= RESTful Endpoints =

The Questionnaire user interface built with React will respond to following HTTP methods and RESTful endpoints. In each section, you will see that the already re-implemented 'Users' UI is used as the mock-up plan for our design. Since Users has already been reimplemented to create the base UI, we will work off of this and continue this design in our implementation to ensure consistency and ease of use of the application as a whole.

== GET /questionnaires ==

GET /questionnaires will return all questionnaires in the system. The user interface built by React will mimic the existing Expertiza UI to list these returned questionnaires in a table. Table columns will display values for the following Questionnaire attributes: ''Name, Type, Updated At, Instructor Id, Min Question Score, Max Question Score, and Private.''

This will look similar in design to the GET /users page which has already been reimplemented using React shown below:

[[File:Index_user_design2.png||800px]]

Columns 'Name,' 'Type', and 'Updated At' will be searchable and sortable like the first three columns in the image above.

=== Implementation ===

This has now been implemented according to plan, as shown below, with dummy JSON objects to populate the table:

[[File:Index_questionnaire_implemented.png||800px]]

== POST /questionnaires ==

From the /questionnaires page described in an earlier section, users will have the option to create a new questionnaire. In order to create a questionnaire, a pop-up will display to capture values for the following fields: ''Name, Type, Min Question Score, Max Question Score, and Private.''

Validations will display upon inputting values into the form. Once valid values are entered, users will click the 'Create Questionnaire' button found on the form to call the POST HTTP method. Messages will display to indicate a successful or unsuccessful creation. Upon successful creation, a dummy JSON object will be created to mimic the behavior of a record being created in a database.

This will look similar in design to the POST /users page which has already been reimplemented using React shown below:

[[File:Index_user_design_create.png||800px]]
[[File:Create_user_design2.png||800px]]

=== Implementation ===

This has now been implemented according to plan, as shown below, with a dummy JSON object being created with valid inputs:

[[File:Index_questionnaire_implemented_create.png||800px]]

[[File:Create_questionnaire_implemented.png||800px]]

==== Validations implemented: ====

* Name, Minimum Question Score, and Maximum Question Score are required.
[[File:Validations1.png||600px]]
* Minimum Question Score must be 0 or greater.
[[File:Validations2.png||600px]]
* Maximum Question Score must be greater than the Minimum Question Score.
[[File:Validations3.png||600px]]

These validations are the same on the Update Questionnaire form.

== PUT /questionnaires/{id} ==

From the /questionnaires page described in an earlier section, users will have the option to update an existing questionnaire. In order to edit a questionnaire, a pop-up will display to capture changed values for the following fields: ''Name, Type, Min Question Score, Max Question Score, and Private.''

Validations will display upon inputting values into the form. Once desired values are changed, users will click the 'Update Questionnaire' button found on the form to call the PUT /questionnaires/{id} REST endpoint. Messages will display to indicate a successful or unsuccessful update. Upon successful update, the matching dummy JSON object will be updated to mimic the behavior of a backend database.

This will look similar in design to the PUT /users/{id} page which has already been reimplemented using React shown below:

[[File:Index_user_design_edit.png||800px]]

[[File:Update_user_design2.png||800px]]

=== Implementation ===

This has now been implemented according to plan, as shown below, with the appropriate dummy JSON object being updated upon successful save:

[[File:Index_questionnaire_implemented_edit.png||800px]]

[[File:Edit_questionnaire_implemented.png||800px]]

==== Validations implemented: ====

See [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2343._Questionnaire_UI#Validations_implemented: "Validations implemented" section under POST /questionnaires].

== DELETE /questionnaires/{id} ==

From the /questionnaires and /questionnaires/{id} pages described in earlier sections, users will have the option to delete an existing record.

When a user chooses this option, they will be presented with a pop-up to confirm that the user wants to delete the record to prevent any accidental deletions. If the user is certain they would like to delete the record, they will then click the 'Delete' button found on this confirmation pop-up. Messages will display to indicate a successful or unsuccessful deletion. Upon successful creation, the matching dummy JSON object will be deleted to mimic the behavior of a record being removed from a database.

This will look similar in design to DELETE /users/{id} which has already been reimplemented using React shown below:

[[File:Index_user_design_delete.png||800px]]

[[File:Delete_user_design2.png||800px]]

=== Implementation ===

This has now been implemented according to plan, as shown below, with the correct dummy JSON object being deleted upon confirmation:

[[File:Index_questionnaire_implemented_delete.png||800px]]

[[File:Delete_questionnaire_implemented.png||800px]]

= React Components =

The following image shows how the files will be organized to create the necessary components of the Questionnaire UI:

[[File:ReactComponentFiles.png||700px]]

Our main focus will be to ensure that the different tasks in Questionnaires.js are clearly defined since this will be the main component file. Here is a snippet of how the create action will be implemented as an example for how we plan to ensure single responsibility and prevent design smells:

const onCreateQuestionnaireHandler = useCallback(
(questionnaire) => {
if (questionnaire && questionnaire.name) {
console.log(questionnaire);
setQuestionnaireData((prevData) => [...prevData, questionnaire]);
dispatch(alertActions.showAlert({
variant: "success",
message: `Questionnaire ${questionnaire.name} created successfully!`
}));
}
setShowCreate(false);
},
[setQuestionnaireData, dispatch]
);

= Testing & Test Plan =

Testing for the UI is done via a json server acting as stand-in for the backend, this stand-in does not have all the features of a true back-end but can adequately test the GET, POST, and DELETE restful actions. The json can be hosted by running the following commands:

npm instal -g json-server
json-server --watch db.json --port 3030

The data in db.json can then be accessed through the normal API calls by redirecting them to the base axios API URL in src/hooks/use-api.js to localhost:3030 from localhost:3030.

[[file: questionnaire_api_explaner.png]]

By making this change we redirect all API requests to our json server.

 

[[file: q_api_diagram.png]]

[[file: db_json_image.png]]

The axios request will then search the JSON object for the array elements under "questionnaires" populating the table with the array elements. To change the UI back to production all that is needed is to change the axios base URL back to localhost:3000.

CSC/ECE 517 Spring 2023 - E2343. Questionnaire UI

2023-04-26T02:43:24Z

Mefergio: /* Testing & Test Plan */

= Project Overview and Justification =

The major crux of the reimplementation of Expertiza is the splitting of Expertiza into a [https://github.com/expertiza/reimplementation-front-end React Front-End] with a [https://github.com/expertiza/reimplementation-back-end Ruby Back-End]. This split should yield a simplification of the code base, and make it easier for developers to make changes if the Expertiza environment isn’t as tightly coupled as before the split. The two ends should interact in terms of the RESTful endpoints, thus separating the implementation of the back-end from the front-end makes both ends more flexible.

Later, when the reimplemented [https://github.com/expertiza/reimplementation-back-end Ruby Back-End] is production-ready, it will be connected to the [https://github.com/expertiza/reimplementation-front-end React Front-End].

React is sound choice for the Expertiza front-end to be reimplemented with because it is flexible, allows reusing components, and is easy for multiple developers to work on at once which boosts the speed of development. Additionally, React was designed with high performance in mind leveraging a framework that allows complex applications run incredibly fast. Due to these benefits, and the bonus that it is easy to learn, a strong interface can be developed quickly for the back-end to integrate with.

The goal of this project is to re-implement the front-end for Questionnaires in React for it to later be connected to the back-end questionnaires_controller and questionnaire model when these back-end reimplementations are production-ready.

'''Important note: This project does not have any back-end functionality whatsoever. There are no controllers or methods implemented. This is a reimplementation of the questionnaire user interface intended for the back-end questionnaire reimplementation that other project teams are working on to eventually connect to. Since there is no back-end with a database, this UI implementation will use dummy JSON objects to replicate the behavior of a back-end database.'''

= UI Flow =

The below diagram shows how users will interact and move through the questionnaire user interface:

[[File:Questionnaire_UI_flow.png||700px]]

= RESTful Endpoints =

The Questionnaire user interface built with React will respond to following HTTP methods and RESTful endpoints. In each section, you will see that the already re-implemented 'Users' UI is used as the mock-up plan for our design. Since Users has already been reimplemented to create the base UI, we will work off of this and continue this design in our implementation to ensure consistency and ease of use of the application as a whole.

== GET /questionnaires ==

GET /questionnaires will return all questionnaires in the system. The user interface built by React will mimic the existing Expertiza UI to list these returned questionnaires in a table. Table columns will display values for the following Questionnaire attributes: ''Name, Type, Updated At, Instructor Id, Min Question Score, Max Question Score, and Private.''

This will look similar in design to the GET /users page which has already been reimplemented using React shown below:

[[File:Index_user_design2.png||800px]]

Columns 'Name,' 'Type', and 'Updated At' will be searchable and sortable like the first three columns in the image above.

=== Implementation ===

This has now been implemented according to plan, as shown below, with dummy JSON objects to populate the table:

[[File:Index_questionnaire_implemented.png||800px]]

== POST /questionnaires ==

From the /questionnaires page described in an earlier section, users will have the option to create a new questionnaire. In order to create a questionnaire, a pop-up will display to capture values for the following fields: ''Name, Type, Min Question Score, Max Question Score, and Private.''

Validations will display upon inputting values into the form. Once valid values are entered, users will click the 'Create Questionnaire' button found on the form to call the POST HTTP method. Messages will display to indicate a successful or unsuccessful creation. Upon successful creation, a dummy JSON object will be created to mimic the behavior of a record being created in a database.

This will look similar in design to the POST /users page which has already been reimplemented using React shown below:

[[File:Index_user_design_create.png||800px]]
[[File:Create_user_design2.png||800px]]

=== Implementation ===

This has now been implemented according to plan, as shown below, with a dummy JSON object being created with valid inputs:

[[File:Index_questionnaire_implemented_create.png||800px]]

[[File:Create_questionnaire_implemented.png||800px]]

==== Validations implemented: ====

* Name, Minimum Question Score, and Maximum Question Score are required.
[[File:Validations1.png||600px]]
* Minimum Question Score must be 0 or greater.
[[File:Validations2.png||600px]]
* Maximum Question Score must be greater than the Minimum Question Score.
[[File:Validations3.png||600px]]

These validations are the same on the Update Questionnaire form.

== PUT /questionnaires/{id} ==

From the /questionnaires page described in an earlier section, users will have the option to update an existing questionnaire. In order to edit a questionnaire, a pop-up will display to capture changed values for the following fields: ''Name, Type, Min Question Score, Max Question Score, and Private.''

Validations will display upon inputting values into the form. Once desired values are changed, users will click the 'Update Questionnaire' button found on the form to call the PUT /questionnaires/{id} REST endpoint. Messages will display to indicate a successful or unsuccessful update. Upon successful update, the matching dummy JSON object will be updated to mimic the behavior of a backend database.

This will look similar in design to the PUT /users/{id} page which has already been reimplemented using React shown below:

[[File:Index_user_design_edit.png||800px]]

[[File:Update_user_design2.png||800px]]

=== Implementation ===

This has now been implemented according to plan, as shown below, with the appropriate dummy JSON object being updated upon successful save:

[[File:Index_questionnaire_implemented_edit.png||800px]]

[[File:Edit_questionnaire_implemented.png||800px]]

==== Validations implemented: ====

See [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2343._Questionnaire_UI#Validations_implemented: "Validations implemented" section under POST /questionnaires].

== DELETE /questionnaires/{id} ==

From the /questionnaires and /questionnaires/{id} pages described in earlier sections, users will have the option to delete an existing record.

When a user chooses this option, they will be presented with a pop-up to confirm that the user wants to delete the record to prevent any accidental deletions. If the user is certain they would like to delete the record, they will then click the 'Delete' button found on this confirmation pop-up. Messages will display to indicate a successful or unsuccessful deletion. Upon successful creation, the matching dummy JSON object will be deleted to mimic the behavior of a record being removed from a database.

This will look similar in design to DELETE /users/{id} which has already been reimplemented using React shown below:

[[File:Index_user_design_delete.png||800px]]

[[File:Delete_user_design2.png||800px]]

=== Implementation ===

This has now been implemented according to plan, as shown below, with the correct dummy JSON object being deleted upon confirmation:

[[File:Index_questionnaire_implemented_delete.png||800px]]

[[File:Delete_questionnaire_implemented.png||800px]]

= React Components =

The following image shows how the files will be organized to create the necessary components of the Questionnaire UI:

[[File:ReactComponentFiles.png||700px]]

Our main focus will be to ensure that the different tasks in Questionnaires.js are clearly defined since this will be the main component file. Here is a snippet of how the create action will be implemented as an example for how we plan to ensure single responsibility and prevent design smells:

const onCreateQuestionnaireHandler = useCallback(
(questionnaire) => {
if (questionnaire && questionnaire.name) {
console.log(questionnaire);
setQuestionnaireData((prevData) => [...prevData, questionnaire]);
dispatch(alertActions.showAlert({
variant: "success",
message: `Questionnaire ${questionnaire.name} created successfully!`
}));
}
setShowCreate(false);
},
[setQuestionnaireData, dispatch]
);

= Testing & Test Plan =

Testing for the UI is done via a json server acting as stand-in for the backend, this stand-in does not have all the features of a true back-end but can adequately test the GET, POST, and DELETE restful actions. The json can be hosted by running the following commands:

npm instal -g json-server
json-server --watch db.json --port 3030

The data in db.json can then be accessed through the normal API calls by redirecting them to the base axios API URL in src/hooks/use-api.js to localhost:3030.

[[file: questionnaire_api_explaner.png]]

[[file: q_api_diagram.png]]

[[file: db_json_image.png]]

Above are diagrams explaining how to set up the db test.

CSC/ECE 517 Spring 2023 - E2343. Questionnaire UI

2023-04-26T02:43:05Z

Mefergio: /* Testing & Test Plan */

= Project Overview and Justification =

The major crux of the reimplementation of Expertiza is the splitting of Expertiza into a [https://github.com/expertiza/reimplementation-front-end React Front-End] with a [https://github.com/expertiza/reimplementation-back-end Ruby Back-End]. This split should yield a simplification of the code base, and make it easier for developers to make changes if the Expertiza environment isn’t as tightly coupled as before the split. The two ends should interact in terms of the RESTful endpoints, thus separating the implementation of the back-end from the front-end makes both ends more flexible.

Later, when the reimplemented [https://github.com/expertiza/reimplementation-back-end Ruby Back-End] is production-ready, it will be connected to the [https://github.com/expertiza/reimplementation-front-end React Front-End].

React is sound choice for the Expertiza front-end to be reimplemented with because it is flexible, allows reusing components, and is easy for multiple developers to work on at once which boosts the speed of development. Additionally, React was designed with high performance in mind leveraging a framework that allows complex applications run incredibly fast. Due to these benefits, and the bonus that it is easy to learn, a strong interface can be developed quickly for the back-end to integrate with.

The goal of this project is to re-implement the front-end for Questionnaires in React for it to later be connected to the back-end questionnaires_controller and questionnaire model when these back-end reimplementations are production-ready.

'''Important note: This project does not have any back-end functionality whatsoever. There are no controllers or methods implemented. This is a reimplementation of the questionnaire user interface intended for the back-end questionnaire reimplementation that other project teams are working on to eventually connect to. Since there is no back-end with a database, this UI implementation will use dummy JSON objects to replicate the behavior of a back-end database.'''

= UI Flow =

The below diagram shows how users will interact and move through the questionnaire user interface:

[[File:Questionnaire_UI_flow.png||700px]]

= RESTful Endpoints =

The Questionnaire user interface built with React will respond to following HTTP methods and RESTful endpoints. In each section, you will see that the already re-implemented 'Users' UI is used as the mock-up plan for our design. Since Users has already been reimplemented to create the base UI, we will work off of this and continue this design in our implementation to ensure consistency and ease of use of the application as a whole.

== GET /questionnaires ==

GET /questionnaires will return all questionnaires in the system. The user interface built by React will mimic the existing Expertiza UI to list these returned questionnaires in a table. Table columns will display values for the following Questionnaire attributes: ''Name, Type, Updated At, Instructor Id, Min Question Score, Max Question Score, and Private.''

This will look similar in design to the GET /users page which has already been reimplemented using React shown below:

[[File:Index_user_design2.png||800px]]

Columns 'Name,' 'Type', and 'Updated At' will be searchable and sortable like the first three columns in the image above.

=== Implementation ===

This has now been implemented according to plan, as shown below, with dummy JSON objects to populate the table:

[[File:Index_questionnaire_implemented.png||800px]]

== POST /questionnaires ==

From the /questionnaires page described in an earlier section, users will have the option to create a new questionnaire. In order to create a questionnaire, a pop-up will display to capture values for the following fields: ''Name, Type, Min Question Score, Max Question Score, and Private.''

Validations will display upon inputting values into the form. Once valid values are entered, users will click the 'Create Questionnaire' button found on the form to call the POST HTTP method. Messages will display to indicate a successful or unsuccessful creation. Upon successful creation, a dummy JSON object will be created to mimic the behavior of a record being created in a database.

This will look similar in design to the POST /users page which has already been reimplemented using React shown below:

[[File:Index_user_design_create.png||800px]]
[[File:Create_user_design2.png||800px]]

=== Implementation ===

This has now been implemented according to plan, as shown below, with a dummy JSON object being created with valid inputs:

[[File:Index_questionnaire_implemented_create.png||800px]]

[[File:Create_questionnaire_implemented.png||800px]]

==== Validations implemented: ====

* Name, Minimum Question Score, and Maximum Question Score are required.
[[File:Validations1.png||600px]]
* Minimum Question Score must be 0 or greater.
[[File:Validations2.png||600px]]
* Maximum Question Score must be greater than the Minimum Question Score.
[[File:Validations3.png||600px]]

These validations are the same on the Update Questionnaire form.

== PUT /questionnaires/{id} ==

From the /questionnaires page described in an earlier section, users will have the option to update an existing questionnaire. In order to edit a questionnaire, a pop-up will display to capture changed values for the following fields: ''Name, Type, Min Question Score, Max Question Score, and Private.''

Validations will display upon inputting values into the form. Once desired values are changed, users will click the 'Update Questionnaire' button found on the form to call the PUT /questionnaires/{id} REST endpoint. Messages will display to indicate a successful or unsuccessful update. Upon successful update, the matching dummy JSON object will be updated to mimic the behavior of a backend database.

This will look similar in design to the PUT /users/{id} page which has already been reimplemented using React shown below:

[[File:Index_user_design_edit.png||800px]]

[[File:Update_user_design2.png||800px]]

=== Implementation ===

This has now been implemented according to plan, as shown below, with the appropriate dummy JSON object being updated upon successful save:

[[File:Index_questionnaire_implemented_edit.png||800px]]

[[File:Edit_questionnaire_implemented.png||800px]]

==== Validations implemented: ====

See [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2343._Questionnaire_UI#Validations_implemented: "Validations implemented" section under POST /questionnaires].

== DELETE /questionnaires/{id} ==

From the /questionnaires and /questionnaires/{id} pages described in earlier sections, users will have the option to delete an existing record.

When a user chooses this option, they will be presented with a pop-up to confirm that the user wants to delete the record to prevent any accidental deletions. If the user is certain they would like to delete the record, they will then click the 'Delete' button found on this confirmation pop-up. Messages will display to indicate a successful or unsuccessful deletion. Upon successful creation, the matching dummy JSON object will be deleted to mimic the behavior of a record being removed from a database.

This will look similar in design to DELETE /users/{id} which has already been reimplemented using React shown below:

[[File:Index_user_design_delete.png||800px]]

[[File:Delete_user_design2.png||800px]]

=== Implementation ===

This has now been implemented according to plan, as shown below, with the correct dummy JSON object being deleted upon confirmation:

[[File:Index_questionnaire_implemented_delete.png||800px]]

[[File:Delete_questionnaire_implemented.png||800px]]

= React Components =

The following image shows how the files will be organized to create the necessary components of the Questionnaire UI:

[[File:ReactComponentFiles.png||700px]]

Our main focus will be to ensure that the different tasks in Questionnaires.js are clearly defined since this will be the main component file. Here is a snippet of how the create action will be implemented as an example for how we plan to ensure single responsibility and prevent design smells:

const onCreateQuestionnaireHandler = useCallback(
(questionnaire) => {
if (questionnaire && questionnaire.name) {
console.log(questionnaire);
setQuestionnaireData((prevData) => [...prevData, questionnaire]);
dispatch(alertActions.showAlert({
variant: "success",
message: `Questionnaire ${questionnaire.name} created successfully!`
}));
}
setShowCreate(false);
},
[setQuestionnaireData, dispatch]
);

= Testing & Test Plan =

Testing for the UI is done via a json server acting as stand-in for the backend, this stand-in does not have all the features of a true back-end but can adequately test the GET, POST, and DELETE restful actions. The json can be hosted by running the following commands:

npm instal -g json-server
json-server --watch db.json --port 3030

The data in db.json can then be accessed through the normal API calls by redirecting them to the base axios API URL in src/hooks/use-api.js to localhost:3030.

[[file: questionnaire_api_explaner.png]]

[[file: q_api_diagram.png]]

[[file: Db_json_image]]

Above are diagrams explaining how to set up the db test.

2023-04-25T01:36:57Z

Mefergio: /* Testing */

= Project Overview and Justification =

The major crux of the reimplementation of Expertiza is the splitting of Expertiza into a [https://github.com/expertiza/reimplementation-front-end React Front-End] with a [https://github.com/expertiza/reimplementation-back-end Ruby Back-End]. This split should yield a simplification of the code base, and make it easier for developers to make changes if the Expertiza environment isn’t as tightly coupled as before the split. The two ends should interact in terms of the RESTful endpoints, thus separating the implementation of the back-end from the front-end makes both ends more flexible.

Later, when the reimplemented [https://github.com/expertiza/reimplementation-back-end Ruby Back-End] is production-ready, it will be connected to the [https://github.com/expertiza/reimplementation-front-end React Front-End].

React is sound choice for the Expertiza front-end to be reimplemented with because it is flexible, allows reusing components, and is easy for multiple developers to work on at once which boosts the speed of development. Additionally, React was designed with high performance in mind leveraging a framework that allows complex applications run incredibly fast. Due to these benefits, and the bonus that it is easy to learn, a strong interface can be developed quickly for the back-end to integrate with.

The goal of this project is to re-implement the front-end for Questionnaires in React for it to later be connected to the back-end questionnaires_controller and questionnaire model when these back-end reimplementations are production-ready.

'''Important note: This project does not have any back-end functionality whatsoever. There are no controllers or methods implemented. This is a reimplementation of the questionnaire user interface intended for the back-end questionnaire reimplementation that other project teams are working on to eventually connect to. No records will be created, modified, or deleted since there is no database or back-end code to perform these actions.'''

= UI Flow =

The below diagram shows how users will interact and move through the questionnaire user interface:

[[File:Questionnaire_UI_flow.png||700px]]

= RESTful Endpoints =

The Questionnaire user interface built with React will respond to following HTTP methods and RESTful endpoints. In each section, you will see that the already re-implemented 'Users' UI is used as the mock-up plan for our design. Since Users has already been reimplemented to create the base UI, we will work off of this and continue this design in our implementation to ensure consistency and ease of use of the application as a whole.

== GET /questionnaires ==

GET /questionnaires will return all questionnaires in the system. The user interface built by React will mimic the existing Expertiza UI to list these returned questionnaires in a table. Table columns will display values for the following Questionnaire attributes: ''Name, Type, Updated At, Instructor, Min Question Score, Max Question Score, and Private.''

This will look similar in design to the GET /users page which has already been reimplemented using React shown below:

[[File:Index_user_design2.png||800px]]

Columns 'Name,' 'Type', and 'Updated At' will be searchable and sortable like the first three columns in the image above.

=== Implementation ===

This has now been implemented according to plan, as shown below:

[[File:Index_questionnaire_implemented.png||800px]]

Since there is no back-end, this page has been spawned with dummy JSON objects. The proper API call is being made in the background, which can be successfully returned upon linking to a back-end with a database server:

[[File:Get_apicall.png||800px]]

== GET /questionnaires/{id} ==

GET /questionnaires/{id} returns details of a particular questionnaire found by its id. From the /questionnaires page described in the previous section, users will have the option to view a specific questionnaire, which will give a more detailed view of that single record. This page will include the following Questionnaire attributes: ''Name, Type, Updated At, Instructor, Min Question Score, Max Question Score, and Private.'' This page will also display a list of question records related to the questionnaire selected.

=== Implementation ===

In the scope of this project, since there is no back-end, the API response to GET /questionnaires/{id} does not return successfully. Once the back-end is implemented to join the front-end, the API will be able to properly render the questionnaire record.

== POST /questionnaires ==

From the /questionnaires page described in an earlier section, users will have the option to create a new questionnaire. In order to create a questionnaire, a pop-up will display to capture values for the following fields: ''Name, Type, Min Question Score, Max Question Score, and Private.''

Validations will display upon inputting values into the form. Once valid values are entered, users will click the 'Create Questionnaire' button found on the form to call the POST HTTP method. Once the back-end is connected, messages will then display to indicate a successful or unsuccessful creation.

This will look similar in design to the POST /users page which has already been reimplemented using React shown below:

[[File:Index_user_design_create.png||800px]]
[[File:Create_user_design2.png||800px]]

=== Implementation ===

This has now been implemented according to plan, as shown below:

[[File:Index_questionnaire_implemented_create.png||800px]]

[[File:Create_questionnaire_implemented.png||800px]]

Additionally, the API makes the proper call when the 'Create Questionnaire' button is clicked. This currently returns with a '404 (Not Found)' error due to the lack of a back-end:

[[File:Create_apicall.png||800px]]

Once the back-end is implemented to connect with the front-end, the API will be able to return successfully since a database server will be found in the back-end.

==== Validations implemented: ====

* Name, Minimum Question Score, and Maximum Question Score are required.
[[File:Validations1.png||600px]]
* Minimum Question Score must be 0 or greater.
[[File:Validations2.png||600px]]
* Maximum Question Score must be greater than the Minimum Question Score.
[[File:Validations3.png||600px]]

These validations are the same on the Update Questionnaire form.

== PUT /questionnaires/{id} ==

From the /questionnaires page described in an earlier section, users will have the option to update an existing questionnaire. In order to edit a questionnaire, a pop-up will display to capture changed values for the following fields: ''Name, Type, Min Question Score, Max Question Score, and Private.''

Validations will display upon inputting values into the form. Once desired values are changed, users will click the 'Update Questionnaire' button found on the form to call the PUT /questionnaires/{id} REST endpoint. Once the back-end is connected, messages will then display to indicate a successful or unsuccessful creation.

This will look similar in design to the PUT /users/{id} page which has already been reimplemented using React shown below:

[[File:Index_user_design_edit.png||800px]]

[[File:Update_user_design2.png||800px]]

=== Implementation ===

This has now been implemented according to plan, as shown below:

[[File:Index_questionnaire_implemented_edit.png||800px]]

[[File:Edit_questionnaire_implemented.png||800px]]

Additionally, the API makes the proper call when the 'Update Questionnaire' button is clicked. This currently returns with a '404 (Not Found)' error due to the lack of a back-end:

[[File:Update_apicall.png||800px]]

Once the back-end is implemented to connect with the front-end, the API will be able to return successfully since a database server will be found in the back-end.

==== Validations implemented: ====

See [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2343._Questionnaire_UI#Validations_implemented: "Validations implemented" section under POST /questionnaires].

== DELETE /questionnaires/{id} ==

From the /questionnaires and /questionnaires/{id} pages described in earlier sections, users will have the option to delete an existing record.

When a user chooses this option, they will be presented with a pop-up to confirm that the user wants to delete the record to prevent any accidental deletions. If the user is certain they would like to delete the record, they will then click the 'Delete' button found on this confirmation pop-up. Once the back-end is connected, messages will then display to indicate a successful or unsuccessful deletion.

This will look similar in design to DELETE /users/{id} which has already been reimplemented using React shown below:

[[File:Index_user_design_delete.png||800px]]

[[File:Delete_user_design2.png||800px]]

=== Implementation ===

This has now been implemented according to plan, as shown below:

[[File:Index_questionnaire_implemented_delete.png||800px]]

[[File:Delete_questionnaire_implemented.png||800px]]

Additionally, the API makes the proper call when the 'Delete' button is clicked. This currently returns with a '404 (Not Found)' error due to the lack of a back-end:

[[File:Delete_apicall.png||800px]]

Once the back-end is implemented to connect with the front-end, the API will be able to return successfully since a database server will be found in the back-end.

= React Components =

The following image shows how the files will be organized to create the necessary components of the Questionnaire UI:

[[File:ReactComponentFiles.png||700px]]

Our main focus will be to ensure that the different tasks in Questionnaires.js are clearly defined since this will be the main component file. Here is a snippet of how the create action will be implemented as an example for how we plan to ensure single responsibility and prevent design smells:

const onCreateQuestionnaireHandler = useCallback(
(questionnaire) => {
if (questionnaire && questionnaire.name) {
console.log(questionnaire);
setQuestionnaireData((prevData) => [...prevData, questionnaire]);
dispatch(alertActions.showAlert({
variant: "success",
message: `Questionnaire ${questionnaire.name} created successfully!`
}));
}
setShowCreate(false);
},
[setQuestionnaireData, dispatch]
);

= Testing & Test Plan =

Testing of these functions with the actual API cannot be done as the back-end is not yet implemented. The request promises never receive acknowledgment form the back-end, so we test the request by logging the objects in the console to display that the objects being sent are in the correct format.

[[file: console_logging.png]]

To display and test the edit and delete functions, a json filled with test data is used to mimic the initial get request to the back-end. To display this json change line 146 form "data={tableData}" to "data={DATA}".

[[file: table_data.png]]

File:Delete user design.png

2023-04-24T01:10:38Z

Mefergio: Mefergio uploaded a new version of File:Delete user design.png

File:Update user design.png

2023-04-24T01:09:25Z

Mefergio: Mefergio uploaded a new version of File:Update user design.png

File:Create user design.png

2023-04-24T01:09:07Z

Mefergio: Mefergio uploaded a new version of File:Create user design.png

File:Create user design.png

2023-04-24T01:08:55Z

Mefergio: Mefergio uploaded a new version of File:Create user design.png

File:Create user design.png

2023-04-24T01:07:53Z

Mefergio: Mefergio uploaded a new version of File:Create user design.png

File:Index user design.png

2023-04-24T01:05:20Z

Mefergio: Mefergio uploaded a new version of File:Index user design.png

CSC/ECE 517 Spring 2023 - E2323. Refactor DueDate functionality from assignment.rb

2023-03-28T01:27:52Z

Mefergio: /* Creating a method to find topic_id from current user */

== E2323. Refactor DueDate functionality from assignment.rb ==

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

=== Project Overview and Mission ===

The goal of this project was to: reduce the length of assignment.rb by removing some related methods into a mixin, refactor several methods using topic_id and check_condition to be more readable, and reduce the use of complex data structures in these methods. The methods removed from assignment.rb include:

*check_condition(column, topic_id)
*submission_allowed(topic_id)
*can_review(topic_id)
*quiz_allowed(topic_id)
*metareview_allowed(topic_id)
*next_due_date(topic_id)
*current_stage(topic_id)
*num_review_rounds
*number_of_current_round(topic_id)

Additionally, the check_conditon method was removed.

----
=== Refactoring Subjects===
==== Creating MixIn of Methods ====

All of the methods in this project take topic_id as an argument and therefore could be moved into a mixin. This serves the dual purpose of reducing the length of assignment.rb and allowing other parts of the project to access the due_date functionality.

The methods in the scope of this project were moved from app/models/assignment.rb to lib/due_date_mix_in.rb and placed within the module "DueDateMixIn".

==== Creating a method to find topic_id from current user ====
One of the unifying themes of the current implementation of these methods is their use of the topic_id argument. The topic_id can be easily found using the assignment id and the participant's id,
and we can increase reliability and usability by changing the argument for these classes into participant id.
Below is the implementation of the find_topic_id class.
 
<pre>
def find_topic_id(participant_id)
topic_id = if participant_id.nil?
nil
else
SignedUpTeam.topic_id(id, participant_id)
end
end
</pre>
 
This method invokes the SingedUpTeam class' topic_id method and gives it the assignment id and the participant id.
Additionally, the function will return nil, if a nil participant id is given to the function. This is to retain some of the functionality of the student_task view page without changing the view page too much.

==== Refactoring *_allowed Methods ====
===== Current Functions =====
The following methods all used the check_condition method using a topic_id argument:
*submission_allowed(topic_id)
*can_review(topic_id)
*quiz_allowed(topic_id)
*metareview_allowed(topic_id)

This method can thus be refactored as a group into a more readable and understandable form.

<pre>
# Check whether review, metareview, etc.. is allowed
# The permissions of TopicDueDate is the same as AssignmentDueDate.
# Here, column is usually something like 'review_allowed_id'
def check_condition(column, topic_id = nil)
next_due_date = DueDate.get_next_due_date(id, topic_id)
return false if next_due_date.nil?

right_id = next_due_date.send column
right = DeadlineRight.find(right_id)
right && (right.name == 'OK' || right.name == 'Late')
end
</pre>
This was implemented in the other methods like in the example below:
<pre>
# Determine if the next due date from now allows for submissions
def submission_allowed(topic_id = nil)
check_condition('submission_allowed_id', topic_id)
end
</pre>

This implementation can be confusing as it relies on passing a string and topic_id, which are not immediately evident in their function.

===== Refactor =====

This method was refactored into the form below. Majorly the argument was changed from topic_id to participant_id in order to make the code more readable, and therefore the function of this method can be parsed more quickly.
<pre>
# Determine if the next due date from now allows for submissions
def submission_allowed(participant_id = nil)
# Find topic id for given participant for selected assignment
# Return nil if no participant is given
topic_id = find_topic_id(participant_id)
# only need to pass @particpiant to search, can this be done locally
next_due_date = DueDate.get_next_due_date(id, topic_id)
return false if next_due_date.nil?

# find the quiz allowed id, then check if that deadline is passed
right_id = next_due_date.submission_allowed_id
right = DeadlineRight.find(right_id)
# check is assignment action deadline is ok or late (i.e. not no)
right && (right.name != 'No')
end
</pre>
In order to search for a due date, we need to have the assignment id and the topic_id. The assignment id is given by the params.
So if we refactor the method to accept the current participant as an argument, we need to add methods to find the topic_id.
Below is a text diff run on the current implementation of check_condition and the updated refactoring of submission allowed to compare the functionality.

 
[[File:e2323_check_condition_dif.PNG]]
 Major Changes Include:
*Argument is now the participant user_id and not topic_id
*Finding right_id no longer invokes the send method.
*The conditional statement at the end of the method was also simplified as Deadline is tristate and an additional "or" statement is not needed.

=== Updating Tests ===

A new rspec file was created in the spec/lib/ folder called due_date_mix_in_spec.rb

The tests for the *_allowed methods were written in the following manor as exemplified by the submission_allowed method.
<pre>
describe '#submission_allowed' do
it 'returns true when the next topic due date is allowed to submit sth' do
#allow(assignment).to receive(:check_condition).with('submission_allowed_id', 123).and_return(true)
#expect(assignment.submission_allowed(123)).to be true
assignment_due_date = double('AssignmentDueDate')
assignment_topic_id = double('AssignmentTopicId')
allow(SignedUpTeam).to receive(:topic_id).with(1, 1).and_return(assignment_topic_id) # 1,1
allow(DueDate).to receive(:get_next_due_date).with(1, assignment_topic_id).and_return(assignment_due_date)
allow(assignment_due_date).to receive(:submission_allowed_id).and_return(1)
allow(DeadlineRight).to receive(:find).with(1).and_return(double('DeadlineRight', name: 'OK'))
expect(assignment.submission_allowed(1)).to be true
end
end
</pre>

These tests were modified to allow for the tests to access the methods and objects now being used within the methods.

CSC/ECE 517 Spring 2023 - E2323. Refactor DueDate functionality from assignment.rb

2023-03-23T00:23:21Z

Mefergio: /* Updating Tests */

CSC/ECE 517 Spring 2023 - E2323. Refactor DueDate functionality from assignment.rb

2023-03-22T22:53:29Z

Mefergio:

File:E2323 check condition dif.PNG

2023-03-22T22:45:51Z

Mefergio: Mefergio uploaded a new version of File:E2323 check condition dif.PNG