Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2016/ M1653 Implement HTML form validation

2016-11-12T19:33:52Z

Ycheng15:

Servo is a newly developed browser by Mozilla and the source code of Servo is written in the Rust programming language<ref>https://doc.rust-lang.org/book/</ref>, which is a system level programming language. The advantages of Rust language are preventing segfaults and thread safety. This project implements form validation feature to the Servo using Rust language.

=='''Introduction'''==
The browser Servo currently can not validate different kinds of form elements before submitting, and might lead to errors such as null input or wrong length of input. The [https://github.com/servo/servo/wiki/Form-validation-student-project issue] we are working on is intended to implement the validation process which is extendable to validate other elements that support such mechanism. This is a long-term project and the last two groups finished initial steps, including basic configuration, structure building, trait implementation. In our project, we will continue to complete validation methods and focus on defining the “validatable” elements across the whole webpage.<ref>https://github.com/servo/servo/wiki/Form-validation-student-project</ref>.

==='''Servo'''===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source prototype web browser layout engine that is being developed by Mozilla Research. Its source code can be found [https://github.com/servo/servo here]. Current browser engines are mostly based on the single-thread model. The motivation behind building servo web browser is to build a highly parallel and reliable environment, where different components (such as rendering, layout, HTML parsing, image decoding, etc.) can be handled by fine-grained, isolated tasks.

==='''Rust'''===
[http://doc.rust-lang.org/book/README.html Rust] is an open source system programming language developed by Mozilla. Rust is a language suited for creating a highly concurrent and safe system. In performance and syntax, rust is similar to C++ but semantically it is very different. Rust emphasis is on speed, safety and control of memory layout<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>.

==='''Example'''===
It is important to take security seriously when building the web application, especially trying to collect data from users. For example, in an email input field, the user might enter the wrong email address or incorrect email format, there should be certain notifications to remind user to change the input accordingly. The same mechanism should also be applied to radio button, multi choice button, text input, etc. In this project, we will implement such validation steps for the HTML5 “validatable” elements.

<form>
<input type="email" value="" placeholder="name@email.com" required />
<input type="submit" value="Submit" />
</form>

The following pictures show different kinds of errors when input email address is not the correct form.

1. Wrong position of '.'

[[File:1error.png]]

2. Missing @

[[File:2error.png]]

3. Missing part after @

[[File:3error.png]]

4. Null input

[[File:4error.png]]

=='''Project description'''==
==='''Initial steps'''===
*compile Servo and ensure that it runs on tests/html/about-mozilla.html

[[File:5.png]]

*email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions
*uncomment the attributes in ValidityState.webidl and fix the resulting build errors by implementing appropriate stub methods in validitystate.rs
*make the ValidityState constructor take an &Element argument and store it as a JS<Element> member in ValidityState
*add a new enum that represents each possible validity check in ValidityState
*define a Validatable trait that contains a method which accepts this enum as an argument (see the Activatable trait for inspiration)
*implement this trait for the form element types (HTMLInputElement, HTMLSelectElement, HTMLButtonElement, etc.), and define an as_maybe_validatable *method on Element which returns an &Validatable value if the element implements the trait (see as_maybe_activatable for inspiration)
*Use the newly-added JS<Element> member to call these new methods as appropriate in each of the stub methods in ValidityState
==='''Subsequent steps'''===
*a method to HTMLFormElement that implements the steps to interactively validate the constraints of a form element
*Implement the checkValidity API for HTMLFormElement
*Implement the reportValidity API for HTMLFormElement
*Implement each validity state defined in the spec as applicable. This can include implementing support for attributes such as min, max, minlength, etc.
*Modify the implementation of the form submission algorithm to include constraint validation
=='''Design Patterns & OO Practices'''==

===Validation Workflow===

The following is a flow chart that depicts the flow of code once the form is submitted and the validation begins -

[[File:OSSimg.png]]

===UML Class Diagram===
Following is the class diagram of the class which are involved in this project. For readability purpose few details are omitted. Only relevant information is captured in this diagram
[[File:Servo_Class.png]]
<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_M1601_Implement_HTML5_form_validation</ref>

==Files to be modified==
*servo/components/script/dom/validitystate.rs
*servo/components/script/dom/validitation.rs
*servo/components/script/dom/htmlformelements.rs
*servo/components/script/dom/htmlinputelements.rs
*servo/components/script/dom/htmlbuttonelements.rs
*servo/components/script/dom/htmltextareaelements.rs
*servo/components/script/dom/htmlselectelements.rs

=='''Testing'''==
===Test with tidy===
Servo has its own code standard. We managed to meet its code standard by using the following command to run code style check.

cd servo
./mach test-tidy

When we ran tidy we got 20 code style errors and we fixed all the errors.

===Compile test===
After adding code, we compiled the servo by the following command

cd servo
./mach build -d

No error showed up, servo worked as expected with the new code.
===Test from UI===
At this stage, the project can't be tested from UI. There are still some subsequent steps to be implemented after this.
The default way to test web page tests/html/form_html5_validations.html following command will be used

./mach run tests/html/form_html5_validations.html

===For reviewers===
In addition to the reasons mentioned above, the servo is a web browser and not a web application. Therefore it can't be deployed on the cloud server. All these would make it hard for reviewers to test the correctness of code at this time.
=='''References'''==
<references />

File:5.png

2016-11-12T19:32:59Z

Ycheng15: uploaded a new version of "File:5.png"

CSC/ECE 517 Fall 2016/ M1653 Implement HTML form validation

2016-11-12T19:11:52Z

Ycheng15: /* Example */

Servo is a newly developed browser by Mozilla and the source code of Servo is written in the Rust programming language<ref>https://doc.rust-lang.org/book/</ref>, which is a system level programming language. The advantages of Rust language are preventing segfaults and thread safety. This project implements form validation feature to the Servo using Rust language.

=='''Introduction'''==
The browser Servo currently can not validate different kinds of form elements before submitting, and might lead to errors such as null input or wrong length of input. The [https://github.com/servo/servo/wiki/Form-validation-student-project issue] we are working on is intended to implement the validation process which is extendable to validate other elements that support such mechanism. This is a long-term project and the last two groups finished initial steps, including basic configuration, structure building, trait implementation. In our project, we will continue to complete validation methods and focus on defining the “validatable” elements across the whole webpage.<ref>https://github.com/servo/servo/wiki/Form-validation-student-project</ref>.

==='''Servo'''===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source prototype web browser layout engine that is being developed by Mozilla Research. Its source code can be found [https://github.com/servo/servo here]. Current browser engines are mostly based on the single-thread model. The motivation behind building servo web browser is to build a highly parallel and reliable environment, where different components (such as rendering, layout, HTML parsing, image decoding, etc.) can be handled by fine-grained, isolated tasks.

==='''Rust'''===
[http://doc.rust-lang.org/book/README.html Rust] is an open source system programming language developed by Mozilla. Rust is a language suited for creating a highly concurrent and safe system. In performance and syntax, rust is similar to C++ but semantically it is very different. Rust emphasis is on speed, safety and control of memory layout<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>.

==='''Example'''===
It is important to take security seriously when building the web application, especially trying to collect data from users. For example, in an email input field, the user might enter the wrong email address or incorrect email format, there should be certain notifications to remind user to change the input accordingly. The same mechanism should also be applied to radio button, multi choice button, text input, etc. In this project, we will implement such validation steps for the HTML5 “validatable” elements.

<form>
<input type="email" value="" placeholder="name@email.com" required />
<input type="submit" value="Submit" />
</form>

The following pictures show different kinds of errors when input email address is not the correct form.

1. Wrong position of '.'

[[File:1error.png]]

2. Missing @

[[File:2error.png]]

3. Missing part after @

[[File:3error.png]]

4. Null input

[[File:4error.png]]

=='''Project description'''==
==='''Initial steps'''===
*compile Servo and ensure that it runs on tests/html/about-mozilla.html
*email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions
*uncomment the attributes in ValidityState.webidl and fix the resulting build errors by implementing appropriate stub methods in validitystate.rs
*make the ValidityState constructor take an &Element argument and store it as a JS<Element> member in ValidityState
*add a new enum that represents each possible validity check in ValidityState
*define a Validatable trait that contains a method which accepts this enum as an argument (see the Activatable trait for inspiration)
*implement this trait for the form element types (HTMLInputElement, HTMLSelectElement, HTMLButtonElement, etc.), and define an as_maybe_validatable *method on Element which returns an &Validatable value if the element implements the trait (see as_maybe_activatable for inspiration)
*Use the newly-added JS<Element> member to call these new methods as appropriate in each of the stub methods in ValidityState
==='''Subsequent steps'''===
*a method to HTMLFormElement that implements the steps to interactively validate the constraints of a form element
*Implement the checkValidity API for HTMLFormElement
*Implement the reportValidity API for HTMLFormElement
*Implement each validity state defined in the spec as applicable. This can include implementing support for attributes such as min, max, minlength, etc.
*Modify the implementation of the form submission algorithm to include constraint validation
=='''Design Patterns & OO Practices'''==

===Validation Workflow===

The following is a flow chart that depicts the flow of code once the form is submitted and the validation begins -

[[File:OSSimg.png]]

===UML Class Diagram===
Following is the class diagram of the class which are involved in this project. For readability purpose few details are omitted. Only relevant information is captured in this diagram
[[File:Servo_Class.png]]
<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_M1601_Implement_HTML5_form_validation</ref>

==Files to be modified==
*servo/components/script/dom/validitystate.rs
*servo/components/script/dom/validitation.rs
*servo/components/script/dom/htmlformelements.rs
*servo/components/script/dom/htmlinputelements.rs
*servo/components/script/dom/htmlbuttonelements.rs
*servo/components/script/dom/htmltextareaelements.rs
*servo/components/script/dom/htmlselectelements.rs

=='''Testing'''==
===Test with tidy===
Servo has its own code standard. We managed to meet its code standard by using the following command to run code style check.

cd servo
./mach test-tidy

When we ran tidy we got 20 code style errors and we fixed all the errors.

===Compile test===
After adding code, we compiled the servo by the following command

cd servo
./mach build -d

No error showed up, servo worked as expected with the new code.
===Test from UI===
At this stage, the project can't be tested from UI. There are still some subsequent steps to be implemented after this.
The default way to test web page tests/html/form_html5_validations.html following command will be used

./mach run tests/html/form_html5_validations.html

===For reviewers===
In addition to the reasons mentioned above, the servo is a web browser and not a web application. Therefore it can't be deployed on the cloud server. All these would make it hard for reviewers to test the correctness of code at this time.
=='''References'''==
<references />

CSC/ECE 517 Fall 2016/ M1653 Implement HTML form validation

2016-11-12T19:09:51Z

Ycheng15: /* Example */

Servo is a newly developed browser by Mozilla and the source code of Servo is written in the Rust programming language<ref>https://doc.rust-lang.org/book/</ref>, which is a system level programming language. The advantages of Rust language are preventing segfaults and thread safety. This project implements form validation feature to the Servo using Rust language.

=='''Introduction'''==
The browser Servo currently can not validate different kinds of form elements before submitting, and might lead to errors such as null input or wrong length of input. The [https://github.com/servo/servo/wiki/Form-validation-student-project issue] we are working on is intended to implement the validation process which is extendable to validate other elements that support such mechanism. This is a long-term project and the last two groups finished initial steps, including basic configuration, structure building, trait implementation. In our project, we will continue to complete validation methods and focus on defining the “validatable” elements across the whole webpage.<ref>https://github.com/servo/servo/wiki/Form-validation-student-project</ref>.

==='''Servo'''===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source prototype web browser layout engine that is being developed by Mozilla Research. Its source code can be found [https://github.com/servo/servo here]. Current browser engines are mostly based on the single-thread model. The motivation behind building servo web browser is to build a highly parallel and reliable environment, where different components (such as rendering, layout, HTML parsing, image decoding, etc.) can be handled by fine-grained, isolated tasks.

==='''Rust'''===
[http://doc.rust-lang.org/book/README.html Rust] is an open source system programming language developed by Mozilla. Rust is a language suited for creating a highly concurrent and safe system. In performance and syntax, rust is similar to C++ but semantically it is very different. Rust emphasis is on speed, safety and control of memory layout<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>.

==='''Example'''===
It is important to take security seriously when building the web application, especially trying to collect data from users. For example, in an email input field, the user might enter the wrong email address or incorrect email format, there should be certain notifications to remind user to change the input accordingly. The same mechanism should also be applied to radio button, multi choice button, text input, etc. In this project, we will implement such validation steps for the HTML5 “validatable” elements.

<form>
<input type="email" value="" placeholder="name@email.com" required />
<input type="submit" value="Submit" />
</form>

The following pictures show different kinds of errors when input email address is not the correct form.
[[File:1error.png]]
[[File:2error.png]]
[[File:3error.png]]
[[File:4error.png]]

=='''Project description'''==
==='''Initial steps'''===
*compile Servo and ensure that it runs on tests/html/about-mozilla.html
*email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions
*uncomment the attributes in ValidityState.webidl and fix the resulting build errors by implementing appropriate stub methods in validitystate.rs
*make the ValidityState constructor take an &Element argument and store it as a JS<Element> member in ValidityState
*add a new enum that represents each possible validity check in ValidityState
*define a Validatable trait that contains a method which accepts this enum as an argument (see the Activatable trait for inspiration)
*implement this trait for the form element types (HTMLInputElement, HTMLSelectElement, HTMLButtonElement, etc.), and define an as_maybe_validatable *method on Element which returns an &Validatable value if the element implements the trait (see as_maybe_activatable for inspiration)
*Use the newly-added JS<Element> member to call these new methods as appropriate in each of the stub methods in ValidityState
==='''Subsequent steps'''===
*a method to HTMLFormElement that implements the steps to interactively validate the constraints of a form element
*Implement the checkValidity API for HTMLFormElement
*Implement the reportValidity API for HTMLFormElement
*Implement each validity state defined in the spec as applicable. This can include implementing support for attributes such as min, max, minlength, etc.
*Modify the implementation of the form submission algorithm to include constraint validation
=='''Design Patterns & OO Practices'''==

===Validation Workflow===

The following is a flow chart that depicts the flow of code once the form is submitted and the validation begins -

[[File:OSSimg.png]]

===UML Class Diagram===
Following is the class diagram of the class which are involved in this project. For readability purpose few details are omitted. Only relevant information is captured in this diagram
[[File:Servo_Class.png]]
<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_M1601_Implement_HTML5_form_validation</ref>

==Files to be modified==
*servo/components/script/dom/validitystate.rs
*servo/components/script/dom/validitation.rs
*servo/components/script/dom/htmlformelements.rs
*servo/components/script/dom/htmlinputelements.rs
*servo/components/script/dom/htmlbuttonelements.rs
*servo/components/script/dom/htmltextareaelements.rs
*servo/components/script/dom/htmlselectelements.rs

=='''Testing'''==
===Test with tidy===
Servo has its own code standard. We managed to meet its code standard by using the following command to run code style check.

cd servo
./mach test-tidy

When we ran tidy we got 20 code style errors and we fixed all the errors.

===Compile test===
After adding code, we compiled the servo by the following command

cd servo
./mach build -d

No error showed up, servo worked as expected with the new code.
===Test from UI===
At this stage, the project can't be tested from UI. There are still some subsequent steps to be implemented after this.
The default way to test web page tests/html/form_html5_validations.html following command will be used

./mach run tests/html/form_html5_validations.html

===For reviewers===
In addition to the reasons mentioned above, the servo is a web browser and not a web application. Therefore it can't be deployed on the cloud server. All these would make it hard for reviewers to test the correctness of code at this time.
=='''References'''==
<references />

File:4error.png

2016-11-12T19:06:40Z

Ycheng15:

File:3error.png

2016-11-12T19:05:37Z

Ycheng15:

File:2error.png

2016-11-12T19:05:25Z

Ycheng15:

File:1error.png

2016-11-12T19:05:11Z

Ycheng15:

CSC/ECE 517 Fall 2016/ M1653 Implement HTML form validation

2016-11-11T22:28:32Z

Ycheng15: /* Example */

Servo is a newly developed browser by Mozilla and the source code of Servo is written in the Rust programming language<ref>https://doc.rust-lang.org/book/</ref>, which is a system level programming language. The advantages of Rust language are preventing segfaults and thread safety. This project implements form validation feature to the Servo using Rust language.

=='''Introduction'''==
The browser Servo currently can not validate different kinds of form elements before submitting, and might lead to errors such as null input or wrong length of input. The [https://github.com/servo/servo/wiki/Form-validation-student-project issue] we are working on is intended to implement the validation process which is extendable to validate other elements that support such mechanism. This is a long-term project and the last two groups finished initial steps, including basic configuration, structure building, trait implementation. In our project, we will continue to complete validation methods and focus on defining the “validatable” elements across the whole webpage.<ref>https://github.com/servo/servo/wiki/Form-validation-student-project</ref>.

==='''Servo'''===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source prototype web browser layout engine that is being developed by Mozilla Research. Its source code can be found [https://github.com/servo/servo here]. Current browser engines are mostly based on the single-thread model. The motivation behind building servo web browser is to build a highly parallel and reliable environment, where different components (such as rendering, layout, HTML parsing, image decoding, etc.) can be handled by fine-grained, isolated tasks.

==='''Rust'''===
[http://doc.rust-lang.org/book/README.html Rust] is an open source system programming language developed by Mozilla. Rust is a language suited for creating a highly concurrent and safe system. In performance and syntax, rust is similar to C++ but semantically it is very different. Rust emphasis is on speed, safety and control of memory layout<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>.

==='''Example'''===
It is important to take security seriously when building the web application, especially trying to collect data from users. For example, in an email input field, the user might enter the wrong email address or incorrect email format, there should be certain notifications to remind user to change the input accordingly. The same mechanism should also be applied to radio button, multi choice button, text input, etc. In this project, we will implement such validation steps for the HTML5 “validatable” elements.

<form>
<input type="email" value="" placeholder="name@email.com" required />
<input type="submit" value="Submit" />
</form>

The following pictures show different kinds of errors when input email address is not the correct form.
[[File:1.png]]

=='''Project description'''==
==='''Initial steps'''===
*compile Servo and ensure that it runs on tests/html/about-mozilla.html
*email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions
*uncomment the attributes in ValidityState.webidl and fix the resulting build errors by implementing appropriate stub methods in validitystate.rs
*make the ValidityState constructor take an &Element argument and store it as a JS<Element> member in ValidityState
*add a new enum that represents each possible validity check in ValidityState
*define a Validatable trait that contains a method which accepts this enum as an argument (see the Activatable trait for inspiration)
*implement this trait for the form element types (HTMLInputElement, HTMLSelectElement, HTMLButtonElement, etc.), and define an as_maybe_validatable *method on Element which returns an &Validatable value if the element implements the trait (see as_maybe_activatable for inspiration)
*Use the newly-added JS<Element> member to call these new methods as appropriate in each of the stub methods in ValidityState
==='''Subsequent steps'''===
*a method to HTMLFormElement that implements the steps to interactively validate the constraints of a form element
*Implement the checkValidity API for HTMLFormElement
*Implement the reportValidity API for HTMLFormElement
*Implement each validity state defined in the spec as applicable. This can include implementing support for attributes such as min, max, minlength, etc.
*Modify the implementation of the form submission algorithm to include constraint validation
=='''Design Patterns & OO Practices'''==

===Validation Workflow===

The following is a flow chart that depicts the flow of code once the form is submitted and the validation begins -

[[File:OSSimg.png]]

===UML Class Diagram===
Following is the class diagram of the class which are involved in this project. For readability purpose few details are omitted. Only relevant information is captured in this diagram
[[File:Servo_Class.png]]
<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_M1601_Implement_HTML5_form_validation</ref>

==Files to be modified==
*servo/components/script/dom/validitystate.rs
*servo/components/script/dom/validitation.rs
*servo/components/script/dom/htmlformelements.rs
*servo/components/script/dom/htmlinputelements.rs
*servo/components/script/dom/htmlbuttonelements.rs
*servo/components/script/dom/htmltextareaelements.rs
*servo/components/script/dom/htmlselectelements.rs

=='''Testing'''==
===Test with tidy===
Servo has its own code standard. We managed to meet its code standard by using the following command to run code style check.

cd servo
./mach test-tidy

When we ran tidy we got 20 code style errors and we fixed all the errors.

===Compile test===
After adding code, we compiled the servo by the following command

cd servo
./mach build -d

No error showed up, servo worked as expected with the new code.
===Test from UI===
At this stage, the project can't be tested from UI. There are still some subsequent steps to be implemented after this.
The default way to test web page tests/html/form_html5_validations.html following command will be used

./mach run tests/html/form_html5_validations.html

===For reviewers===
In addition to the reasons mentioned above, the servo is a web browser and not a web application. Therefore it can't be deployed on the cloud server. All these would make it hard for reviewers to test the correctness of code at this time.
=='''References'''==
<references />

CSC/ECE 517 Fall 2016/ M1653 Implement HTML form validation

2016-11-11T22:27:09Z

Ycheng15: /* Example */

Servo is a newly developed browser by Mozilla and the source code of Servo is written in the Rust programming language<ref>https://doc.rust-lang.org/book/</ref>, which is a system level programming language. The advantages of Rust language are preventing segfaults and thread safety. This project implements form validation feature to the Servo using Rust language.

=='''Introduction'''==
The browser Servo currently can not validate different kinds of form elements before submitting, and might lead to errors such as null input or wrong length of input. The [https://github.com/servo/servo/wiki/Form-validation-student-project issue] we are working on is intended to implement the validation process which is extendable to validate other elements that support such mechanism. This is a long-term project and the last two groups finished initial steps, including basic configuration, structure building, trait implementation. In our project, we will continue to complete validation methods and focus on defining the “validatable” elements across the whole webpage.<ref>https://github.com/servo/servo/wiki/Form-validation-student-project</ref>.

==='''Servo'''===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source prototype web browser layout engine that is being developed by Mozilla Research. Its source code can be found [https://github.com/servo/servo here]. Current browser engines are mostly based on the single-thread model. The motivation behind building servo web browser is to build a highly parallel and reliable environment, where different components (such as rendering, layout, HTML parsing, image decoding, etc.) can be handled by fine-grained, isolated tasks.

==='''Rust'''===
[http://doc.rust-lang.org/book/README.html Rust] is an open source system programming language developed by Mozilla. Rust is a language suited for creating a highly concurrent and safe system. In performance and syntax, rust is similar to C++ but semantically it is very different. Rust emphasis is on speed, safety and control of memory layout<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>.

==='''Example'''===
It is important to take security seriously when building the web application, especially trying to collect data from users. For example, in an email input field, the user might enter the wrong email address or incorrect email format, there should be certain notifications to remind user to change the input accordingly. The same mechanism should also be applied to radio button, multi choice button, text input, etc. In this project, we will implement such validation steps for the HTML5 “validatable” elements.

<form>
<input type="email" value="" placeholder="name@email.com" required />
<input type="submit" value="Submit" />
</form>

The following pictures show different kinds of errors when input email address is not the correct form.

=='''Project description'''==
==='''Initial steps'''===
*compile Servo and ensure that it runs on tests/html/about-mozilla.html
*email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions
*uncomment the attributes in ValidityState.webidl and fix the resulting build errors by implementing appropriate stub methods in validitystate.rs
*make the ValidityState constructor take an &Element argument and store it as a JS<Element> member in ValidityState
*add a new enum that represents each possible validity check in ValidityState
*define a Validatable trait that contains a method which accepts this enum as an argument (see the Activatable trait for inspiration)
*implement this trait for the form element types (HTMLInputElement, HTMLSelectElement, HTMLButtonElement, etc.), and define an as_maybe_validatable *method on Element which returns an &Validatable value if the element implements the trait (see as_maybe_activatable for inspiration)
*Use the newly-added JS<Element> member to call these new methods as appropriate in each of the stub methods in ValidityState
==='''Subsequent steps'''===
*a method to HTMLFormElement that implements the steps to interactively validate the constraints of a form element
*Implement the checkValidity API for HTMLFormElement
*Implement the reportValidity API for HTMLFormElement
*Implement each validity state defined in the spec as applicable. This can include implementing support for attributes such as min, max, minlength, etc.
*Modify the implementation of the form submission algorithm to include constraint validation
=='''Design Patterns & OO Practices'''==

===Validation Workflow===

The following is a flow chart that depicts the flow of code once the form is submitted and the validation begins -

[[File:OSSimg.png]]

===UML Class Diagram===
Following is the class diagram of the class which are involved in this project. For readability purpose few details are omitted. Only relevant information is captured in this diagram
[[File:Servo_Class.png]]
<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_M1601_Implement_HTML5_form_validation</ref>

==Files to be modified==
*servo/components/script/dom/validitystate.rs
*servo/components/script/dom/validitation.rs
*servo/components/script/dom/htmlformelements.rs
*servo/components/script/dom/htmlinputelements.rs
*servo/components/script/dom/htmlbuttonelements.rs
*servo/components/script/dom/htmltextareaelements.rs
*servo/components/script/dom/htmlselectelements.rs

=='''Testing'''==
===Test with tidy===
Servo has its own code standard. We managed to meet its code standard by using the following command to run code style check.

cd servo
./mach test-tidy

When we ran tidy we got 20 code style errors and we fixed all the errors.

===Compile test===
After adding code, we compiled the servo by the following command

cd servo
./mach build -d

No error showed up, servo worked as expected with the new code.
===Test from UI===
At this stage, the project can't be tested from UI. There are still some subsequent steps to be implemented after this.
The default way to test web page tests/html/form_html5_validations.html following command will be used

./mach run tests/html/form_html5_validations.html

===For reviewers===
In addition to the reasons mentioned above, the servo is a web browser and not a web application. Therefore it can't be deployed on the cloud server. All these would make it hard for reviewers to test the correctness of code at this time.
=='''References'''==
<references />

CSC/ECE 517 Fall 2016/ M1653 Implement HTML form validation

2016-11-11T22:26:59Z

Ycheng15: /* Example */

Servo is a newly developed browser by Mozilla and the source code of Servo is written in the Rust programming language<ref>https://doc.rust-lang.org/book/</ref>, which is a system level programming language. The advantages of Rust language are preventing segfaults and thread safety. This project implements form validation feature to the Servo using Rust language.

=='''Introduction'''==
The browser Servo currently can not validate different kinds of form elements before submitting, and might lead to errors such as null input or wrong length of input. The [https://github.com/servo/servo/wiki/Form-validation-student-project issue] we are working on is intended to implement the validation process which is extendable to validate other elements that support such mechanism. This is a long-term project and the last two groups finished initial steps, including basic configuration, structure building, trait implementation. In our project, we will continue to complete validation methods and focus on defining the “validatable” elements across the whole webpage.<ref>https://github.com/servo/servo/wiki/Form-validation-student-project</ref>.

==='''Servo'''===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source prototype web browser layout engine that is being developed by Mozilla Research. Its source code can be found [https://github.com/servo/servo here]. Current browser engines are mostly based on the single-thread model. The motivation behind building servo web browser is to build a highly parallel and reliable environment, where different components (such as rendering, layout, HTML parsing, image decoding, etc.) can be handled by fine-grained, isolated tasks.

==='''Rust'''===
[http://doc.rust-lang.org/book/README.html Rust] is an open source system programming language developed by Mozilla. Rust is a language suited for creating a highly concurrent and safe system. In performance and syntax, rust is similar to C++ but semantically it is very different. Rust emphasis is on speed, safety and control of memory layout<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>.

==='''Example'''===
It is important to take security seriously when building the web application, especially trying to collect data from users. For example, in an email input field, the user might enter the wrong email address or incorrect email format, there should be certain notifications to remind user to change the input accordingly. The same mechanism should also be applied to radio button, multi choice button, text input, etc. In this project, we will implement such validation steps for the HTML5 “validatable” elements.

<form>
<input type="email" value="" placeholder="name@email.com" required />
<input type="submit" value="Submit" />
</form>

The following pictures show different kinds of errors when input email address is not the correct form.
[[File:1.jpg]]

=='''Project description'''==
==='''Initial steps'''===
*compile Servo and ensure that it runs on tests/html/about-mozilla.html
*email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions
*uncomment the attributes in ValidityState.webidl and fix the resulting build errors by implementing appropriate stub methods in validitystate.rs
*make the ValidityState constructor take an &Element argument and store it as a JS<Element> member in ValidityState
*add a new enum that represents each possible validity check in ValidityState
*define a Validatable trait that contains a method which accepts this enum as an argument (see the Activatable trait for inspiration)
*implement this trait for the form element types (HTMLInputElement, HTMLSelectElement, HTMLButtonElement, etc.), and define an as_maybe_validatable *method on Element which returns an &Validatable value if the element implements the trait (see as_maybe_activatable for inspiration)
*Use the newly-added JS<Element> member to call these new methods as appropriate in each of the stub methods in ValidityState
==='''Subsequent steps'''===
*a method to HTMLFormElement that implements the steps to interactively validate the constraints of a form element
*Implement the checkValidity API for HTMLFormElement
*Implement the reportValidity API for HTMLFormElement
*Implement each validity state defined in the spec as applicable. This can include implementing support for attributes such as min, max, minlength, etc.
*Modify the implementation of the form submission algorithm to include constraint validation
=='''Design Patterns & OO Practices'''==

===Validation Workflow===

The following is a flow chart that depicts the flow of code once the form is submitted and the validation begins -

[[File:OSSimg.png]]

===UML Class Diagram===
Following is the class diagram of the class which are involved in this project. For readability purpose few details are omitted. Only relevant information is captured in this diagram
[[File:Servo_Class.png]]
<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_M1601_Implement_HTML5_form_validation</ref>

==Files to be modified==
*servo/components/script/dom/validitystate.rs
*servo/components/script/dom/validitation.rs
*servo/components/script/dom/htmlformelements.rs
*servo/components/script/dom/htmlinputelements.rs
*servo/components/script/dom/htmlbuttonelements.rs
*servo/components/script/dom/htmltextareaelements.rs
*servo/components/script/dom/htmlselectelements.rs

=='''Testing'''==
===Test with tidy===
Servo has its own code standard. We managed to meet its code standard by using the following command to run code style check.

cd servo
./mach test-tidy

When we ran tidy we got 20 code style errors and we fixed all the errors.

===Compile test===
After adding code, we compiled the servo by the following command

cd servo
./mach build -d

No error showed up, servo worked as expected with the new code.
===Test from UI===
At this stage, the project can't be tested from UI. There are still some subsequent steps to be implemented after this.
The default way to test web page tests/html/form_html5_validations.html following command will be used

./mach run tests/html/form_html5_validations.html

===For reviewers===
In addition to the reasons mentioned above, the servo is a web browser and not a web application. Therefore it can't be deployed on the cloud server. All these would make it hard for reviewers to test the correctness of code at this time.
=='''References'''==
<references />

CSC/ECE 517 Fall 2016/ M1653 Implement HTML form validation

2016-11-11T22:24:12Z

Ycheng15: /* Example */

Servo is a newly developed browser by Mozilla and the source code of Servo is written in the Rust programming language<ref>https://doc.rust-lang.org/book/</ref>, which is a system level programming language. The advantages of Rust language are preventing segfaults and thread safety. This project implements form validation feature to the Servo using Rust language.

=='''Introduction'''==
The browser Servo currently can not validate different kinds of form elements before submitting, and might lead to errors such as null input or wrong length of input. The [https://github.com/servo/servo/wiki/Form-validation-student-project issue] we are working on is intended to implement the validation process which is extendable to validate other elements that support such mechanism. This is a long-term project and the last two groups finished initial steps, including basic configuration, structure building, trait implementation. In our project, we will continue to complete validation methods and focus on defining the “validatable” elements across the whole webpage.<ref>https://github.com/servo/servo/wiki/Form-validation-student-project</ref>.

==='''Servo'''===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source prototype web browser layout engine that is being developed by Mozilla Research. Its source code can be found [https://github.com/servo/servo here]. Current browser engines are mostly based on the single-thread model. The motivation behind building servo web browser is to build a highly parallel and reliable environment, where different components (such as rendering, layout, HTML parsing, image decoding, etc.) can be handled by fine-grained, isolated tasks.

==='''Rust'''===
[http://doc.rust-lang.org/book/README.html Rust] is an open source system programming language developed by Mozilla. Rust is a language suited for creating a highly concurrent and safe system. In performance and syntax, rust is similar to C++ but semantically it is very different. Rust emphasis is on speed, safety and control of memory layout<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>.

==='''Example'''===
It is important to take security seriously when building the web application, especially trying to collect data from users. For example, in an email input field, the user might enter the wrong email address or incorrect email format, there should be certain notifications to remind user to change the input accordingly. The same mechanism should also be applied to radio button, multi choice button, text input, etc. In this project, we will implement such validation steps for the HTML5 “validatable” elements.

<form>
<input type="email" value="" placeholder="name@email.com" required />
<input type="submit" value="Submit" />
</form>

The following pictures show different kinds of errors when input email address is not the correct form.

=='''Project description'''==
==='''Initial steps'''===
*compile Servo and ensure that it runs on tests/html/about-mozilla.html
*email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions
*uncomment the attributes in ValidityState.webidl and fix the resulting build errors by implementing appropriate stub methods in validitystate.rs
*make the ValidityState constructor take an &Element argument and store it as a JS<Element> member in ValidityState
*add a new enum that represents each possible validity check in ValidityState
*define a Validatable trait that contains a method which accepts this enum as an argument (see the Activatable trait for inspiration)
*implement this trait for the form element types (HTMLInputElement, HTMLSelectElement, HTMLButtonElement, etc.), and define an as_maybe_validatable *method on Element which returns an &Validatable value if the element implements the trait (see as_maybe_activatable for inspiration)
*Use the newly-added JS<Element> member to call these new methods as appropriate in each of the stub methods in ValidityState
==='''Subsequent steps'''===
*a method to HTMLFormElement that implements the steps to interactively validate the constraints of a form element
*Implement the checkValidity API for HTMLFormElement
*Implement the reportValidity API for HTMLFormElement
*Implement each validity state defined in the spec as applicable. This can include implementing support for attributes such as min, max, minlength, etc.
*Modify the implementation of the form submission algorithm to include constraint validation
=='''Design Patterns & OO Practices'''==

===Validation Workflow===

The following is a flow chart that depicts the flow of code once the form is submitted and the validation begins -

[[File:OSSimg.png]]

===UML Class Diagram===
Following is the class diagram of the class which are involved in this project. For readability purpose few details are omitted. Only relevant information is captured in this diagram
[[File:Servo_Class.png]]
<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_M1601_Implement_HTML5_form_validation</ref>

==Files to be modified==
*servo/components/script/dom/validitystate.rs
*servo/components/script/dom/validitation.rs
*servo/components/script/dom/htmlformelements.rs
*servo/components/script/dom/htmlinputelements.rs
*servo/components/script/dom/htmlbuttonelements.rs
*servo/components/script/dom/htmltextareaelements.rs
*servo/components/script/dom/htmlselectelements.rs

=='''Testing'''==
===Test with tidy===
Servo has its own code standard. We managed to meet its code standard by using the following command to run code style check.

cd servo
./mach test-tidy

When we ran tidy we got 20 code style errors and we fixed all the errors.

===Compile test===
After adding code, we compiled the servo by the following command

cd servo
./mach build -d

No error showed up, servo worked as expected with the new code.
===Test from UI===
At this stage, the project can't be tested from UI. There are still some subsequent steps to be implemented after this.
The default way to test web page tests/html/form_html5_validations.html following command will be used

./mach run tests/html/form_html5_validations.html

===For reviewers===
In addition to the reasons mentioned above, the servo is a web browser and not a web application. Therefore it can't be deployed on the cloud server. All these would make it hard for reviewers to test the correctness of code at this time.
=='''References'''==
<references />

File:4.png

2016-11-11T22:21:14Z

Ycheng15: uploaded a new version of "File:4.png"

File:3.png

2016-11-11T22:21:02Z

Ycheng15: uploaded a new version of "File:3.png"

IS-A and HAS-A Rules of Inheritance

File:2.png

2016-11-11T22:20:52Z

Ycheng15: uploaded a new version of "File:2.png"

Double diamond problem

File:1.png

2016-11-11T22:20:35Z

Ycheng15: uploaded a new version of "File:1.png"

Distributed Version Control System

CSC/ECE 517 Fall 2016/ M1653 Implement HTML form validation

2016-11-11T21:59:37Z

Ycheng15:

Servo is a newly developed browser by Mozilla and the source code of Servo is written in the Rust programming language<ref>https://doc.rust-lang.org/book/</ref>, which is a system level programming language. The advantages of Rust language are preventing segfaults and thread safety. This project implements form validation feature to the Servo using Rust language.

=='''Introduction'''==
The browser Servo currently can not validate different kinds of form elements before submitting, and might lead to errors such as null input or wrong length of input. The [https://github.com/servo/servo/wiki/Form-validation-student-project issue] we are working on is intended to implement the validation process which is extendable to validate other elements that support such mechanism. This is a long-term project and the last two groups finished initial steps, including basic configuration, structure building, trait implementation. In our project, we will continue to complete validation methods and focus on defining the “validatable” elements across the whole webpage.<ref>https://github.com/servo/servo/wiki/Form-validation-student-project</ref>.

==='''Servo'''===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source prototype web browser layout engine that is being developed by Mozilla Research. Its source code can be found [https://github.com/servo/servo here]. Current browser engines are mostly based on the single-thread model. The motivation behind building servo web browser is to build a highly parallel and reliable environment, where different components (such as rendering, layout, HTML parsing, image decoding, etc.) can be handled by fine-grained, isolated tasks.

==='''Rust'''===
[http://doc.rust-lang.org/book/README.html Rust] is an open source system programming language developed by Mozilla. Rust is a language suited for creating a highly concurrent and safe system. In performance and syntax, rust is similar to C++ but semantically it is very different. Rust emphasis is on speed, safety and control of memory layout<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>.

==='''Example'''===
It is important to take security seriously when building the web application, especially trying to collect data from users. For example, in an email input field, the user might enter the wrong email address or incorrect email format, there should be certain notifications to remind user to change the input accordingly. The same mechanism should also be applied to radio button, multi choice button, text input, etc. In this project, we will implement such validation steps for the HTML5 “validatable” elements.

=='''Project description'''==
==='''Initial steps'''===
*compile Servo and ensure that it runs on tests/html/about-mozilla.html
*email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions
*uncomment the attributes in ValidityState.webidl and fix the resulting build errors by implementing appropriate stub methods in validitystate.rs
*make the ValidityState constructor take an &Element argument and store it as a JS<Element> member in ValidityState
*add a new enum that represents each possible validity check in ValidityState
*define a Validatable trait that contains a method which accepts this enum as an argument (see the Activatable trait for inspiration)
*implement this trait for the form element types (HTMLInputElement, HTMLSelectElement, HTMLButtonElement, etc.), and define an as_maybe_validatable *method on Element which returns an &Validatable value if the element implements the trait (see as_maybe_activatable for inspiration)
*Use the newly-added JS<Element> member to call these new methods as appropriate in each of the stub methods in ValidityState
==='''Subsequent steps'''===
*a method to HTMLFormElement that implements the steps to interactively validate the constraints of a form element
*Implement the checkValidity API for HTMLFormElement
*Implement the reportValidity API for HTMLFormElement
*Implement each validity state defined in the spec as applicable. This can include implementing support for attributes such as min, max, minlength, etc.
*Modify the implementation of the form submission algorithm to include constraint validation
=='''Design Patterns & OO Practices'''==

The following is a flow chart that depicts the flow of code once the form is submitted and the validation begins -

[[File:OSSimg.png]]

===UML Class Diagram===
Following is the class diagram of the class which are involved in this project. For readability purpose few details are omitted. Only relevant information is captured in this diagram
[[File:Servo_Class.png]]

==Files to be modified==
*servo/components/script/dom/validitystate.rs
*servo/components/script/dom/validitation.rs
*servo/components/script/dom/htmlformelements.rs
*servo/components/script/dom/htmlinputelements.rs
*servo/components/script/dom/htmlbuttonelements.rs
*servo/components/script/dom/htmltextareaelements.rs
*servo/components/script/dom/htmlselectelements.rs

=='''Testing'''==
===Test with tidy===
Servo has its own code standard. We managed to meet its code standard by using the following command to run code style check.

cd servo
./mach test-tidy

When we ran tidy we got 20 code style errors and we fixed all the errors.

===Compile test===
After adding code, we compiled the servo by the following command

cd servo
./mach build -d

No error showed up, servo worked as expected with the new code.
===Test from UI===
At this stage, the project can't be tested from UI. There are still some subsequent steps to be implemented after this.
The default way to test web page tests/html/form_html5_validations.html following command will be used

./mach run tests/html/form_html5_validations.html

===For reviewers===
In addition to the reasons mentioned above, the servo is a web browser and not a web application. Therefore it can't be deployed on the cloud server. All these would make it hard for reviewers to test the correctness of code at this time.
=='''References'''==
<references />

CSC/ECE 517 Fall 2016/ M1653 Implement HTML form validation

2016-11-11T21:24:06Z

Ycheng15:

Servo is a newly developed browser by Mozilla and the source code of Servo is written in the Rust programming language<ref>https://doc.rust-lang.org/book/</ref>, which is a system level programming language. The advantages of Rust language are preventing segfaults and thread safety. This project implements form validation feature to the Servo using Rust language.

=='''Introduction'''==
The browser Servo currently can not validate different kinds of form elements before submitting, and might lead to errors such as null input or wrong length of input. The [https://github.com/servo/servo/wiki/Form-validation-student-project issue] we are working on is intended to implement the validation process which is extendable to validate other elements that support such mechanism. This is a long-term project and the last two groups finished initial steps, including basic configuration, structure building, trait implementation. In our project, we will continue to complete validation methods and focus on defining the “validatable” elements across the whole webpage.<ref>https://github.com/servo/servo/wiki/Form-validation-student-project</ref>.

==='''Servo'''===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source prototype web browser layout engine that is being developed by Mozilla Research. Its source code can be found [https://github.com/servo/servo here]. Current browser engines are mostly based on the single-thread model. The motivation behind building servo web browser is to build a highly parallel and reliable environment, where different components (such as rendering, layout, HTML parsing, image decoding, etc.) can be handled by fine-grained, isolated tasks.

==='''Rust'''===
[http://doc.rust-lang.org/book/README.html Rust] is an open source system programming language developed by Mozilla. Rust is a language suited for creating a highly concurrent and safe system. In performance and syntax, rust is similar to C++ but semantically it is very different. Rust emphasis is on speed, safety and control of memory layout<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>.

=='''Project description'''==
==='''Initial steps'''===
*compile Servo and ensure that it runs on tests/html/about-mozilla.html
*email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions
*uncomment the attributes in ValidityState.webidl and fix the resulting build errors by implementing appropriate stub methods in validitystate.rs
*make the ValidityState constructor take an &Element argument and store it as a JS<Element> member in ValidityState
*add a new enum that represents each possible validity check in ValidityState
*define a Validatable trait that contains a method which accepts this enum as an argument (see the Activatable trait for inspiration)
*implement this trait for the form element types (HTMLInputElement, HTMLSelectElement, HTMLButtonElement, etc.), and define an as_maybe_validatable *method on Element which returns an &Validatable value if the element implements the trait (see as_maybe_activatable for inspiration)
*Use the newly-added JS<Element> member to call these new methods as appropriate in each of the stub methods in ValidityState
==='''Subsequent steps'''===
*a method to HTMLFormElement that implements the steps to interactively validate the constraints of a form element
*Implement the checkValidity API for HTMLFormElement
*Implement the reportValidity API for HTMLFormElement
*Implement each validity state defined in the spec as applicable. This can include implementing support for attributes such as min, max, minlength, etc.
*Modify the implementation of the form submission algorithm to include constraint validation
=='''Design Patterns & OO Practices'''==

Since this project is a continuing project from OSS M1653, and we are taking over from the previous group, we are not going to modify the design pattern from previous project. So we will still keep the enum to bit flag change proposed last time. We will also follow servo project work flow as well as DRY principle in OO design.

==Files to be modified==
*servo/components/script/dom/validitystate.rs
*servo/components/script/dom/validitation.rs
*servo/components/script/dom/htmlformelements.rs
*servo/components/script/dom/htmlinputelements.rs
*servo/components/script/dom/htmlbuttonelements.rs
*servo/components/script/dom/htmltextareaelements.rs
*servo/components/script/dom/htmlselectelements.rs

=='''Testing'''==
===Test with tidy===
Servo has its own code standard. We managed to meet its code standard by using the following command to run code style check.

cd servo
./mach test-tidy

When we ran tidy we got 20 code style errors and we fixed all the errors.

===Compile test===
After adding code, we compiled the servo by the following command

cd servo
./mach build -d

No error showed up, servo worked as expected with the new code.
===Test from UI===
At this stage, the project can't be tested from UI. There are still some subsequent steps to be implemented after this.
The default way to test web page tests/html/form_html5_validations.html following command will be used

./mach run tests/html/form_html5_validations.html

===For reviewers===
In addition to the reasons mentioned above, the servo is a web browser and not a web application. Therefore it can't be deployed on the cloud server. All these would make it hard for reviewers to test the correctness of code at this time.
=='''References'''==
<references />

CSC/ECE 517 Fall 2016/ M1653 Implement HTML form validation

2016-11-11T21:22:53Z

Ycheng15:

Servo is a newly developed browser by Mozilla and the source code of Servo is written in the Rust programming language, which is a system level programming language. The advantages of Rust language are preventing segfaults and thread safety. This project implements form validation feature to the Servo using Rust language.

=='''Introduction'''==
The browser Servo currently can not validate different kinds of form elements before submitting, and might lead to errors such as null input or wrong length of input. The [https://github.com/servo/servo/wiki/Form-validation-student-project issue] we are working on is intended to implement the validation process which is extendable to validate other elements that support such mechanism. This is a long-term project and the last two groups finished initial steps, including basic configuration, structure building, trait implementation. In our project, we will continue to complete validation methods and focus on defining the “validatable” elements across the whole webpage.<ref>https://github.com/servo/servo/wiki/Form-validation-student-project</ref>.

==='''Servo'''===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source prototype web browser layout engine that is being developed by Mozilla Research. Its source code can be found [https://github.com/servo/servo here]. Current browser engines are mostly based on the single-thread model. The motivation behind building servo web browser is to build a highly parallel and reliable environment, where different components (such as rendering, layout, HTML parsing, image decoding, etc.) can be handled by fine-grained, isolated tasks.

==='''Rust'''===
[http://doc.rust-lang.org/book/README.html Rust] is an open source system programming language developed by Mozilla. Rust is a language suited for creating a highly concurrent and safe system. In performance and syntax, rust is similar to C++ but semantically it is very different. Rust emphasis is on speed, safety and control of memory layout<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>.

=='''Project description'''==
==='''Initial steps'''===
*compile Servo and ensure that it runs on tests/html/about-mozilla.html
*email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions
*uncomment the attributes in ValidityState.webidl and fix the resulting build errors by implementing appropriate stub methods in validitystate.rs
*make the ValidityState constructor take an &Element argument and store it as a JS<Element> member in ValidityState
*add a new enum that represents each possible validity check in ValidityState
*define a Validatable trait that contains a method which accepts this enum as an argument (see the Activatable trait for inspiration)
*implement this trait for the form element types (HTMLInputElement, HTMLSelectElement, HTMLButtonElement, etc.), and define an as_maybe_validatable *method on Element which returns an &Validatable value if the element implements the trait (see as_maybe_activatable for inspiration)
*Use the newly-added JS<Element> member to call these new methods as appropriate in each of the stub methods in ValidityState
==='''Subsequent steps'''===
*a method to HTMLFormElement that implements the steps to interactively validate the constraints of a form element
*Implement the checkValidity API for HTMLFormElement
*Implement the reportValidity API for HTMLFormElement
*Implement each validity state defined in the spec as applicable. This can include implementing support for attributes such as min, max, minlength, etc.
*Modify the implementation of the form submission algorithm to include constraint validation
=='''Design Patterns & OO Practices'''==

Since this project is a continuing project from OSS M1653, and we are taking over from the previous group, we are not going to modify the design pattern from previous project. So we will still keep the enum to bit flag change proposed last time. We will also follow servo project work flow as well as DRY principle in OO design.

==Files to be modified==
*servo/components/script/dom/validitystate.rs
*servo/components/script/dom/validitation.rs
*servo/components/script/dom/htmlformelements.rs
*servo/components/script/dom/htmlinputelements.rs
*servo/components/script/dom/htmlbuttonelements.rs
*servo/components/script/dom/htmltextareaelements.rs
*servo/components/script/dom/htmlselectelements.rs

=='''Testing'''==
===Test with tidy===
Servo has its own code standard. We managed to meet its code standard by using the following command to run code style check.

cd servo
./mach test-tidy

When we ran tidy we got 20 code style errors and we fixed all the errors.

===Compile test===
After adding code, we compiled the servo by the following command

cd servo
./mach build -d

No error showed up, servo worked as expected with the new code.
===Test from UI===
At this stage, the project can't be tested from UI. There are still some subsequent steps to be implemented after this.
The default way to test web page tests/html/form_html5_validations.html following command will be used

./mach run tests/html/form_html5_validations.html

===For reviewers===
In addition to the reasons mentioned above, the servo is a web browser and not a web application. Therefore it can't be deployed on the cloud server. All these would make it hard for reviewers to test the correctness of code at this time.
=='''References'''==
<references />

CSC/ECE 517 Fall 2016/ M1653 Implement HTML form validation

2016-11-10T02:30:55Z

Ycheng15: /* Introduction */

=='''Introduction'''==
The browser Servo currently can not validate different kinds of form elements before submitting, and might lead to errors such as null input or wrong length of input. The [https://github.com/servo/servo/wiki/Form-validation-student-project issue] we are working on is intended to implement the validation process which is extendable to validate other elements that support such mechanism. This is a long-term project and the last two groups finished initial steps, including basic configuration, structure building, trait implementation. In our project, we will continue to complete validation methods and focus on defining the “validatable” elements across the whole webpage.

==='''Servo'''===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source prototype web browser layout engine that is being developed by Mozilla Research. Its source code can be found [https://github.com/servo/servo here]. Current browser engines are mostly based on the single-thread model. The motivation behind building servo web browser is to build a highly parallel and reliable environment, where different components (such as rendering, layout, HTML parsing, image decoding, etc.) can be handled by fine-grained, isolated tasks.

==='''Rust'''===
[http://doc.rust-lang.org/book/README.html Rust] is an open source system programming language developed by Mozilla. Rust is a language suited for creating a highly concurrent and safe system. In performance and syntax, rust is similar to C++ but semantically it is very different. Rust emphasis is on speed, safety and control of memory layout<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>.

=='''Project description'''==
==='''Initial steps'''===
*compile Servo and ensure that it runs on tests/html/about-mozilla.html
*email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions
*uncomment the attributes in ValidityState.webidl and fix the resulting build errors by implementing appropriate stub methods in validitystate.rs
*make the ValidityState constructor take an &Element argument and store it as a JS<Element> member in ValidityState
*add a new enum that represents each possible validity check in ValidityState
*define a Validatable trait that contains a method which accepts this enum as an argument (see the Activatable trait for inspiration)
*implement this trait for the form element types (HTMLInputElement, HTMLSelectElement, HTMLButtonElement, etc.), and define an as_maybe_validatable *method on Element which returns an &Validatable value if the element implements the trait (see as_maybe_activatable for inspiration)
*Use the newly-added JS<Element> member to call these new methods as appropriate in each of the stub methods in ValidityState
==='''Subsequent steps'''===
*a method to HTMLFormElement that implements the steps to interactively validate the constraints of a form element
*Implement the checkValidity API for HTMLFormElement
*Implement the reportValidity API for HTMLFormElement
*Implement each validity state defined in the spec as applicable. This can include implementing support for attributes such as min, max, minlength, etc.
*Modify the implementation of the form submission algorithm to include constraint validation
=='''Design Patterns & OO Practices'''==
=='''Testing'''==
===Test with tidy===
Servo has its own code standard. We managed to meet its code standard by using the following command to run code style check.

cd servo
./mach test-tidy

When we ran tidy we got 20 code style errors and we fixed all the errors.

===Compile test===
After adding code, we compiled the servo by the following command

cd servo
./mach build -d

No error showed up, servo worked as expected with the new code.
===Test from UI===
At this stage, the project can't be tested from UI. There are still some subsequent steps to be implemented after this.
The default way to test web page tests/html/form_html5_validations.html following command will be used

<code>
./mach run tests/html/form_html5_validations.html
</code>

===For reviewers===
In addition to the reasons mentioned above, the servo is a web browser and not a web application. Therefore it can't be deployed on the cloud server. All these would make it hard for reviewers to test the correctness of code at this time.

=='''References'''==
<references />

CSC/ECE 517 Fall 2016/ M1653 Implement HTML form validation

2016-11-10T02:30:01Z

Ycheng15: /* Introduction */

=='''Introduction'''==
The browser Servo currently can not validate different kinds of form elements before submitting, and might lead to errors such as null input or wrong length of input. The issue we are working on is intended to implement the validation process which is extendable to validate other elements that support such mechanism. This is a long-term project and the last two groups finished initial steps, including basic configuration, structure building, trait implementation. In our project, we will continue to complete validation methods and focus on defining the “validatable” elements across the whole webpage.

==='''Servo'''===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source prototype web browser layout engine that is being developed by Mozilla Research. Its source code can be found [https://github.com/servo/servo here]. Current browser engines are mostly based on the single-thread model. The motivation behind building servo web browser is to build a highly parallel and reliable environment, where different components (such as rendering, layout, HTML parsing, image decoding, etc.) can be handled by fine-grained, isolated tasks.

==='''Rust'''===
[http://doc.rust-lang.org/book/README.html Rust] is an open source system programming language developed by Mozilla. Rust is a language suited for creating a highly concurrent and safe system. In performance and syntax, rust is similar to C++ but semantically it is very different. Rust emphasis is on speed, safety and control of memory layout<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>.

=='''Project description'''==
==='''Initial steps'''===
*compile Servo and ensure that it runs on tests/html/about-mozilla.html
*email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions
*uncomment the attributes in ValidityState.webidl and fix the resulting build errors by implementing appropriate stub methods in validitystate.rs
*make the ValidityState constructor take an &Element argument and store it as a JS<Element> member in ValidityState
*add a new enum that represents each possible validity check in ValidityState
*define a Validatable trait that contains a method which accepts this enum as an argument (see the Activatable trait for inspiration)
*implement this trait for the form element types (HTMLInputElement, HTMLSelectElement, HTMLButtonElement, etc.), and define an as_maybe_validatable *method on Element which returns an &Validatable value if the element implements the trait (see as_maybe_activatable for inspiration)
*Use the newly-added JS<Element> member to call these new methods as appropriate in each of the stub methods in ValidityState
==='''Subsequent steps'''===
*a method to HTMLFormElement that implements the steps to interactively validate the constraints of a form element
*Implement the checkValidity API for HTMLFormElement
*Implement the reportValidity API for HTMLFormElement
*Implement each validity state defined in the spec as applicable. This can include implementing support for attributes such as min, max, minlength, etc.
*Modify the implementation of the form submission algorithm to include constraint validation
=='''Design Patterns & OO Practices'''==
=='''Testing'''==
===Test with tidy===
Servo has its own code standard. We managed to meet its code standard by using the following command to run code style check.

cd servo
./mach test-tidy

When we ran tidy we got 20 code style errors and we fixed all the errors.

===Compile test===
After adding code, we compiled the servo by the following command

cd servo
./mach build -d

No error showed up, servo worked as expected with the new code.
===Test from UI===
At this stage, the project can't be tested from UI. There are still some subsequent steps to be implemented after this.
The default way to test web page tests/html/form_html5_validations.html following command will be used

<code>
./mach run tests/html/form_html5_validations.html
</code>

===For reviewers===
In addition to the reasons mentioned above, the servo is a web browser and not a web application. Therefore it can't be deployed on the cloud server. All these would make it hard for reviewers to test the correctness of code at this time.

=='''References'''==
<references />

CSC/ECE 517 Fall 2016/ M1653 Implement HTML form validation

2016-11-10T02:29:22Z

Ycheng15:

=='''Introduction'''==
The browser Servo currently can not validate different kinds of form elements before submitting, and might lead to errors such as null input or wrong length of input. The project is intended to implement the validation process which is extendable to validate other elements that support such mechanism. This is a long-term project and the last two groups finished initial steps, including basic configuration, structure building, trait implementation. In our project, we will continue to complete validation methods and focus on defining the “validatable” elements across the whole webpage.

==='''Servo'''===
[https://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is an open source prototype web browser layout engine that is being developed by Mozilla Research. Its source code can be found [https://github.com/servo/servo here]. Current browser engines are mostly based on the single-thread model. The motivation behind building servo web browser is to build a highly parallel and reliable environment, where different components (such as rendering, layout, HTML parsing, image decoding, etc.) can be handled by fine-grained, isolated tasks.

==='''Rust'''===
[http://doc.rust-lang.org/book/README.html Rust] is an open source system programming language developed by Mozilla. Rust is a language suited for creating a highly concurrent and safe system. In performance and syntax, rust is similar to C++ but semantically it is very different. Rust emphasis is on speed, safety and control of memory layout<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>.

=='''Project description'''==
==='''Initial steps'''===
*compile Servo and ensure that it runs on tests/html/about-mozilla.html
*email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions
*uncomment the attributes in ValidityState.webidl and fix the resulting build errors by implementing appropriate stub methods in validitystate.rs
*make the ValidityState constructor take an &Element argument and store it as a JS<Element> member in ValidityState
*add a new enum that represents each possible validity check in ValidityState
*define a Validatable trait that contains a method which accepts this enum as an argument (see the Activatable trait for inspiration)
*implement this trait for the form element types (HTMLInputElement, HTMLSelectElement, HTMLButtonElement, etc.), and define an as_maybe_validatable *method on Element which returns an &Validatable value if the element implements the trait (see as_maybe_activatable for inspiration)
*Use the newly-added JS<Element> member to call these new methods as appropriate in each of the stub methods in ValidityState
==='''Subsequent steps'''===
*a method to HTMLFormElement that implements the steps to interactively validate the constraints of a form element
*Implement the checkValidity API for HTMLFormElement
*Implement the reportValidity API for HTMLFormElement
*Implement each validity state defined in the spec as applicable. This can include implementing support for attributes such as min, max, minlength, etc.
*Modify the implementation of the form submission algorithm to include constraint validation
=='''Design Patterns & OO Practices'''==
=='''Testing'''==
===Test with tidy===
Servo has its own code standard. We managed to meet its code standard by using the following command to run code style check.

cd servo
./mach test-tidy

When we ran tidy we got 20 code style errors and we fixed all the errors.

===Compile test===
After adding code, we compiled the servo by the following command

cd servo
./mach build -d

No error showed up, servo worked as expected with the new code.
===Test from UI===
At this stage, the project can't be tested from UI. There are still some subsequent steps to be implemented after this.
The default way to test web page tests/html/form_html5_validations.html following command will be used

<code>
./mach run tests/html/form_html5_validations.html
</code>

===For reviewers===
In addition to the reasons mentioned above, the servo is a web browser and not a web application. Therefore it can't be deployed on the cloud server. All these would make it hard for reviewers to test the correctness of code at this time.

=='''References'''==
<references />

CSC/ECE 517 Fall 2016/E1660. Review requirements and thresholds

2016-11-01T04:17:43Z

Ycheng15:

<font size="4"><b>E1660. Review requirements and thresholds</b></font>

== Background ==
In Expertiza, there are two ways of assigning reviews to reviewers: either the instructor decides who reviews whom (“instructor-selected”), or “auto-selected,” in which case reviews are not assigned until a student seeks to choose something to review.
To allow reviewers a larger set of topics to choose from, the instructor can set the threshold (on the Review Strategy tab of assignment creation/editing) to some integer k > 0. Then any submission that has within k reviews of the fewest number can be chosen by a new reviewer. Let’s say that all submissions have at least 1 review. If k = 3, then the reviewer can choose any topic where there is a submission that has 4 or fewer reviews so far.
Suppose that the minimum number of reviews for any submission is 2, but that I have reviewed all the submissions that have only 2 reviews. Then I’m not allowed to review at all (unless k > 0). That’s wrong; I should always be allowed to review the work with the least reviews that I have not already reviewed. And that should generalize to situations in which k > 0.
Another issue is that there is no way for Expertiza to tell a reviewer how many reviews are required. In the case of instructor-selected reviewing, that’s not a problem, but for auto-selected reviewing, there is no way to specify how many reviews are required (or even how many are allowed, in case students are allowed to do extra reviews).

== Purpose ==
The purpose of this task is to solve the above mentioned issues collaboratively.
The assignments table now contains the Max reviews required and allowed field which can be set from Review strategy tab. This allows the admin to set the threshold value for required number of reviews for the assignment.
Another feature implemented is, now students can check how many reviews he/she needs to write which helps students determine how many reviews to write and also how many reviews he/she has already written.
Another issue resolved was the reviewer who finished reviewing all submissions with least number of reviews, should be able to review the next set of submissions with greater number of reviews. That is, the threshold rule was more relaxed.
Implemented the necessary test cases for the new features implemented.

== Modified File ==
* app/views/assignments/edit/_review_strategy.html.erb
* db/schema.rb
* Added two new unit tests in RSpec file in spec/models/assignment_form_spec.rb
* Added two new columns in Assignment table as shown below
* app/models/review_assignment.rb
* app/controllers/review_mapping_controller.rb
* added new file review_assignment_spec.rb in spec for testing the above functionality.
<pre>
ALTER TABLE assignments ADD COLUMN num_reviews_required INT DEFAULT 3;
ALTER TABLE assignments ADD COLUMN num_reviews_allowed INT DEFAULT 3;
</pre>

* add new RSpec tests in assignment_spec.rb
<pre>
describe "can not review own work", type: :feature do
before(:each) do
create(:assignment, name: "TestTeam", directory_path: 'test_team')
create_list(:participant, 3)
create(:assignment_node)
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create(:assignment_due_date, deadline_type: DeadlineType.where(name: 'review').first, due_at: Time.now + (100 * 24 * 60 * 60))
#create(:topic)
create(:topic, topic_name: "work1")
end

it "case1" do

#test log in as a student

user = User.find_by_name('student2064')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }

visit root_path
fill_in 'login_name', with: 'student2064'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

#expect(page).to have_content "Welcome!"
#expect(page).to have_content "Assignments"
#click_link "Assignments"

expect(page).to have_content "User: student2064"
expect(page).to have_content "TestTeam"

click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"

#test if the topic can be seen and chosen by a student

click_link "Signup sheet"
expect(page).to have_content "work1"
my_link = find(:xpath, "//a[contains(@href,'sign_up_sheet/sign_up?assignment_id=#{Assignment.last.id}&id=1')]")
my_link.click

#test after selecting a topic, a team formed
click_link "Assignments"
click_link "TestTeam"
click_link "Your work"

fill_in 'submission', with: 'www.google.com'
click_button 'Upload link'

click_link "Assignments"
click_link "TestTeam"
click_link "Others' work"

click_button "Request a new submission to review"

#If no link of view is on the page, then it means that no review is allowed for this user.
expect(page).to have_no_link "view"

#save_and_open_page
end
end
</pre>

=== RSpec testing ===
The new RSpec test added to the assignment_spec.rb is used to verify that the reviewer who submits their assignment should not be allowed to review their own work. The test mainly simulates mouse click on the webpage and tries to find certain content. One student account is created to submit the assignment which is stored by the system. Since this submission is the only one for the existed topic, the system is supposed to not to assign reviewer anything, which is equivalent to have the correct output for code, expect(page).to have_no_link "view". The test file shows desired result and the issue resolved.

== External Links ==
[https://github.com/rnambis/expertiza Link for forked repository]

CSC/ECE 517 Fall 2016/E1660. Review requirements and thresholds

2016-11-01T04:17:20Z

Ycheng15:

<font size="4"><b>E1660. Review requirements and thresholds</b></font>

== Background ==
In Expertiza, there are two ways of assigning reviews to reviewers: either the instructor decides who reviews whom (“instructor-selected”), or “auto-selected,” in which case reviews are not assigned until a student seeks to choose something to review.
To allow reviewers a larger set of topics to choose from, the instructor can set the threshold (on the Review Strategy tab of assignment creation/editing) to some integer k > 0. Then any submission that has within k reviews of the fewest number can be chosen by a new reviewer. Let’s say that all submissions have at least 1 review. If k = 3, then the reviewer can choose any topic where there is a submission that has 4 or fewer reviews so far.
Suppose that the minimum number of reviews for any submission is 2, but that I have reviewed all the submissions that have only 2 reviews. Then I’m not allowed to review at all (unless k > 0). That’s wrong; I should always be allowed to review the work with the least reviews that I have not already reviewed. And that should generalize to situations in which k > 0.
Another issue is that there is no way for Expertiza to tell a reviewer how many reviews are required. In the case of instructor-selected reviewing, that’s not a problem, but for auto-selected reviewing, there is no way to specify how many reviews are required (or even how many are allowed, in case students are allowed to do extra reviews).

== Purpose ==
The purpose of this task is to solve the above mentioned issues collaboratively.
The assignments table now contains the Max reviews required and allowed field which can be set from Review strategy tab. This allows the admin to set the threshold value for required number of reviews for the assignment.
Another feature implemented is, now students can check how many reviews he/she needs to write which helps students determine how many reviews to write and also how many reviews he/she has already written.
Another issue resolved was the reviewer who finished reviewing all submissions with least number of reviews, should be able to review the next set of submissions with greater number of reviews. That is, the threshold rule was more relaxed.
Implemented the necessary test cases for the new features implemented.

== Modified File ==
* app/views/assignments/edit/_review_strategy.html.erb
* db/schema.rb
* Added two new unit tests in RSpec file in spec/models/assignment_form_spec.rb
* Added two new columns in Assignment table as shown below
* app/models/review_assignment.rb
* app/controllers/review_mapping_controller.rb
* added new file review_assignment_spec.rb in spec for testing the above functionality.
<pre>
ALTER TABLE assignments ADD COLUMN num_reviews_required INT DEFAULT 3;
ALTER TABLE assignments ADD COLUMN num_reviews_allowed INT DEFAULT 3;
</pre>

* add new RSpec tests in assignment_spec.rb
<pre>
describe "can not review own work", type: :feature do
before(:each) do
create(:assignment, name: "TestTeam", directory_path: 'test_team')
create_list(:participant, 3)
create(:assignment_node)
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create(:assignment_due_date, deadline_type: DeadlineType.where(name: 'review').first, due_at: Time.now + (100 * 24 * 60 * 60))
#create(:topic)
create(:topic, topic_name: "work1")
end

it "case1" do

#test log in as a student

user = User.find_by_name('student2064')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }

visit root_path
fill_in 'login_name', with: 'student2064'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

#expect(page).to have_content "Welcome!"
#expect(page).to have_content "Assignments"
#click_link "Assignments"

expect(page).to have_content "User: student2064"
expect(page).to have_content "TestTeam"

click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"

#test if the topic can be seen and chosen by a student

click_link "Signup sheet"
expect(page).to have_content "work1"
my_link = find(:xpath, "//a[contains(@href,'sign_up_sheet/sign_up?assignment_id=#{Assignment.last.id}&id=1')]")
my_link.click

#test after selecting a topic, a team formed
click_link "Assignments"
click_link "TestTeam"
click_link "Your work"

fill_in 'submission', with: 'www.google.com'
click_button 'Upload link'

click_link "Assignments"
click_link "TestTeam"
click_link "Others' work"

click_button "Request a new submission to review"

#If no link of view is on the page, then it means that no review is allowed for this user.
expect(page).to have_no_link "view"

#save_and_open_page
end
end
</pre>

=== RSpec testing ===
The new RSpec test added to the assignment_spec.rb is used to verify that the reviewer who submits their assignment should not be allowed to review their own work. The test mainly simulates mouse click on the webpage and tries to find certain content. One student account is created to submit the assignment which is stored by the system. Since this submission is the only one for the existed topic, the system is supposed to not to assign reviewer anything, which is equivalent to have the correct output for code, expect(page).to have_no_link "view". The test file shows desired result and the issue resolved.

== External Links ==
# link for forked repository [https://github.com/rnambis/expertiza Link for forked repository]

CSC/ECE 517 Fall 2016/E1660. Review requirements and thresholds

2016-11-01T04:16:19Z

Ycheng15: /* External Links */

<font size="4"><b>E1660. Review requirements and thresholds</b></font>

== Background ==
In Expertiza, there are two ways of assigning reviews to reviewers: either the instructor decides who reviews whom (“instructor-selected”), or “auto-selected,” in which case reviews are not assigned until a student seeks to choose something to review.
To allow reviewers a larger set of topics to choose from, the instructor can set the threshold (on the Review Strategy tab of assignment creation/editing) to some integer k > 0. Then any submission that has within k reviews of the fewest number can be chosen by a new reviewer. Let’s say that all submissions have at least 1 review. If k = 3, then the reviewer can choose any topic where there is a submission that has 4 or fewer reviews so far.
Suppose that the minimum number of reviews for any submission is 2, but that I have reviewed all the submissions that have only 2 reviews. Then I’m not allowed to review at all (unless k > 0). That’s wrong; I should always be allowed to review the work with the least reviews that I have not already reviewed. And that should generalize to situations in which k > 0.
Another issue is that there is no way for Expertiza to tell a reviewer how many reviews are required. In the case of instructor-selected reviewing, that’s not a problem, but for auto-selected reviewing, there is no way to specify how many reviews are required (or even how many are allowed, in case students are allowed to do extra reviews).

== Purpose ==
The purpose of this task is to solve the above mentioned issues collaboratively.
The assignments table now contains the Max reviews required and allowed field which can be set from Review strategy tab. This allows the admin to set the threshold value for required number of reviews for the assignment.
Another feature implemented is, now students can check how many reviews he/she needs to write which helps students determine how many reviews to write and also how many reviews he/she has already written.
Another issue resolved was the reviewer who finished reviewing all submissions with least number of reviews, should be able to review the next set of submissions with greater number of reviews. That is, the threshold rule was more relaxed.
Implemented the necessary test cases for the new features implemented.

== Modified File ==
* app/views/assignments/edit/_review_strategy.html.erb
* db/schema.rb
* Added two new unit tests in RSpec file in spec/models/assignment_form_spec.rb
* Added two new columns in Assignment table as shown below
* app/models/review_assignment.rb
* app/controllers/review_mapping_controller.rb
* added new file review_assignment_spec.rb in spec for testing the above functionality.
<pre>
ALTER TABLE assignments ADD COLUMN num_reviews_required INT DEFAULT 3;
ALTER TABLE assignments ADD COLUMN num_reviews_allowed INT DEFAULT 3;
</pre>

* add new RSpec tests in assignment_spec.rb
<pre>
describe "can not review own work", type: :feature do
before(:each) do
create(:assignment, name: "TestTeam", directory_path: 'test_team')
create_list(:participant, 3)
create(:assignment_node)
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create(:assignment_due_date, deadline_type: DeadlineType.where(name: 'review').first, due_at: Time.now + (100 * 24 * 60 * 60))
#create(:topic)
create(:topic, topic_name: "work1")
end

it "case1" do

#test log in as a student

user = User.find_by_name('student2064')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }

visit root_path
fill_in 'login_name', with: 'student2064'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

#expect(page).to have_content "Welcome!"
#expect(page).to have_content "Assignments"
#click_link "Assignments"

expect(page).to have_content "User: student2064"
expect(page).to have_content "TestTeam"

click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"

#test if the topic can be seen and chosen by a student

click_link "Signup sheet"
expect(page).to have_content "work1"
my_link = find(:xpath, "//a[contains(@href,'sign_up_sheet/sign_up?assignment_id=#{Assignment.last.id}&id=1')]")
my_link.click

#test after selecting a topic, a team formed
click_link "Assignments"
click_link "TestTeam"
click_link "Your work"

fill_in 'submission', with: 'www.google.com'
click_button 'Upload link'

click_link "Assignments"
click_link "TestTeam"
click_link "Others' work"

click_button "Request a new submission to review"

#If no link of view is on the page, then it means that no review is allowed for this user.
expect(page).to have_no_link "view"

#save_and_open_page
end
end
</pre>

=== RSpec testing ===
The new RSpec test added to the assignment_spec.rb is used to verify that the reviewer who submits their assignment should not be allowed to review their own work. The test mainly simulates mouse click on the webpage and tries to find certain content. One student account is created to submit the assignment which is stored by the system. Since this submission is the only one for the existed topic, the system is supposed to not to assign reviewer anything, which is equivalent to have the correct output for code, expect(page).to have_no_link "view". The test file shows desired result and the issue resolved.

== External Links ==
# link for forked repository <ref>https://github.com/rnambis/expertiza</ref>

CSC/ECE 517 Fall 2016/E1660. Review requirements and thresholds

2016-11-01T04:12:37Z

Ycheng15:

CSC/ECE 517 Fall 2016/E1660. Review requirements and thresholds

2016-11-01T03:47:20Z

Ycheng15: /* Modified File */

= Review requirements and thresholds =

=== Background ===
In Expertiza, there are two ways of assigning reviews to reviewers: either the instructor decides who reviews whom (“instructor-selected”), or “auto-selected,” in which case reviews are not assigned until a student seeks to choose something to review.
To allow reviewers a larger set of topics to choose from, the instructor can set the threshold (on the Review Strategy tab of assignment creation/editing) to some integer k > 0. Then any submission that has within k reviews of the fewest number can be chosen by a new reviewer. Let’s say that all submissions have at least 1 review. If k = 3, then the reviewer can choose any topic where there is a submission that has 4 or fewer reviews so far.
Suppose that the minimum number of reviews for any submission is 2, but that I have reviewed all the submissions that have only 2 reviews. Then I’m not allowed to review at all (unless k > 0). That’s wrong; I should always be allowed to review the work with the least reviews that I have not already reviewed. And that should generalize to situations in which k > 0.
Another issue is that there is no way for Expertiza to tell a reviewer how many reviews are required. In the case of instructor-selected reviewing, that’s not a problem, but for auto-selected reviewing, there is no way to specify how many reviews are required (or even how many are allowed, in case students are allowed to do extra reviews).

=== Purpose ===
The purpose of this task is to solve the above mentioned issues collaboratively.
The assignments table now contains the Max reviews required and allowed field which can be set from Review strategy tab. This allows the admin to set the threshold value for required number of reviews for the assignment.
Another feature implemented is, now students can check how many reviews he/she needs to write which helps students determine how many reviews to write and also how many reviews he/she has already written.
Another issue resolved was the reviewer who finished reviewing all submissions with least number of reviews, should be able to review the next set of submissions with greater number of reviews. That is, the threshold rule was more relaxed.
Implemented the necessary test cases for the new features implemented.

== Modified File ==
* app/views/assignments/edit/_review_strategy.html.erb
* db/schema.rb
* Added two new unit tests in RSpec file in spec/models/assignment_form_spec.rb
* Added two new columns in Assignment table as shown below
* app/models/review_assignment.rb
* app/controllers/review_mapping_controller.rb
* added new file review_assignment_spec.rb in spec for testing the above functionality.
<pre>
ALTER TABLE assignments ADD COLUMN num_reviews_required INT DEFAULT 3;
ALTER TABLE assignments ADD COLUMN num_reviews_allowed INT DEFAULT 3;
</pre>

* add new RSpec tests in assignment_spec.rb
<pre>
describe "can not review own work", type: :feature do
before(:each) do
create(:assignment, name: "TestTeam", directory_path: 'test_team')
create_list(:participant, 3)
create(:assignment_node)
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create(:assignment_due_date, deadline_type: DeadlineType.where(name: 'review').first, due_at: Time.now + (100 * 24 * 60 * 60))
#create(:topic)
create(:topic, topic_name: "work1")
end

it "case1" do

#test log in as a student

user = User.find_by_name('student2064')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }

visit root_path
fill_in 'login_name', with: 'student2064'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

#expect(page).to have_content "Welcome!"
#expect(page).to have_content "Assignments"
#click_link "Assignments"

expect(page).to have_content "User: student2064"
expect(page).to have_content "TestTeam"

click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"

#test if the topic can be seen and chosen by a student

click_link "Signup sheet"
expect(page).to have_content "work1"
my_link = find(:xpath, "//a[contains(@href,'sign_up_sheet/sign_up?assignment_id=#{Assignment.last.id}&id=1')]")
my_link.click

#test after selecting a topic, a team formed
click_link "Assignments"
click_link "TestTeam"
click_link "Your work"

fill_in 'submission', with: 'www.google.com'
click_button 'Upload link'

click_link "Assignments"
click_link "TestTeam"
click_link "Others' work"

click_button "Request a new submission to review"

#If no link of view is on the page, then it means that no review is allowed for this user.
expect(page).to have_no_link "view"

#save_and_open_page
end
end
</pre>
=== External Links ===
# link for forked repository

CSC/ECE 517 Fall 2016/E1660. Review requirements and thresholds

2016-11-01T03:47:04Z

Ycheng15:

= Review requirements and thresholds =

=== Background ===
In Expertiza, there are two ways of assigning reviews to reviewers: either the instructor decides who reviews whom (“instructor-selected”), or “auto-selected,” in which case reviews are not assigned until a student seeks to choose something to review.
To allow reviewers a larger set of topics to choose from, the instructor can set the threshold (on the Review Strategy tab of assignment creation/editing) to some integer k > 0. Then any submission that has within k reviews of the fewest number can be chosen by a new reviewer. Let’s say that all submissions have at least 1 review. If k = 3, then the reviewer can choose any topic where there is a submission that has 4 or fewer reviews so far.
Suppose that the minimum number of reviews for any submission is 2, but that I have reviewed all the submissions that have only 2 reviews. Then I’m not allowed to review at all (unless k > 0). That’s wrong; I should always be allowed to review the work with the least reviews that I have not already reviewed. And that should generalize to situations in which k > 0.
Another issue is that there is no way for Expertiza to tell a reviewer how many reviews are required. In the case of instructor-selected reviewing, that’s not a problem, but for auto-selected reviewing, there is no way to specify how many reviews are required (or even how many are allowed, in case students are allowed to do extra reviews).

=== Purpose ===
The purpose of this task is to solve the above mentioned issues collaboratively.
The assignments table now contains the Max reviews required and allowed field which can be set from Review strategy tab. This allows the admin to set the threshold value for required number of reviews for the assignment.
Another feature implemented is, now students can check how many reviews he/she needs to write which helps students determine how many reviews to write and also how many reviews he/she has already written.
Another issue resolved was the reviewer who finished reviewing all submissions with least number of reviews, should be able to review the next set of submissions with greater number of reviews. That is, the threshold rule was more relaxed.
Implemented the necessary test cases for the new features implemented.

== Modified File ==
* app/views/assignments/edit/_review_strategy.html.erb
* db/schema.rb
* Added two new unit tests in RSpec file in spec/models/assignment_form_spec.rb
* Added two new columns in Assignment table as shown below
* app/models/review_assignment.rb
* app/controllers/review_mapping_controller.rb
* added new file review_assignment_spec.rb in spec for testing the above functionality.
* add new RSpec tests in assignment_spec.rb
<pre>
ALTER TABLE assignments ADD COLUMN num_reviews_required INT DEFAULT 3;
ALTER TABLE assignments ADD COLUMN num_reviews_allowed INT DEFAULT 3;
</pre>

<pre>
describe "can not review own work", type: :feature do
before(:each) do
create(:assignment, name: "TestTeam", directory_path: 'test_team')
create_list(:participant, 3)
create(:assignment_node)
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create(:assignment_due_date, deadline_type: DeadlineType.where(name: 'review').first, due_at: Time.now + (100 * 24 * 60 * 60))
#create(:topic)
create(:topic, topic_name: "work1")
end

it "case1" do

#test log in as a student

user = User.find_by_name('student2064')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }

visit root_path
fill_in 'login_name', with: 'student2064'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

#expect(page).to have_content "Welcome!"
#expect(page).to have_content "Assignments"
#click_link "Assignments"

expect(page).to have_content "User: student2064"
expect(page).to have_content "TestTeam"

click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"

#test if the topic can be seen and chosen by a student

click_link "Signup sheet"
expect(page).to have_content "work1"
my_link = find(:xpath, "//a[contains(@href,'sign_up_sheet/sign_up?assignment_id=#{Assignment.last.id}&id=1')]")
my_link.click

#test after selecting a topic, a team formed
click_link "Assignments"
click_link "TestTeam"
click_link "Your work"

fill_in 'submission', with: 'www.google.com'
click_button 'Upload link'

click_link "Assignments"
click_link "TestTeam"
click_link "Others' work"

click_button "Request a new submission to review"

#If no link of view is on the page, then it means that no review is allowed for this user.
expect(page).to have_no_link "view"

#save_and_open_page
end
end
</pre>
=== External Links ===
# link for forked repository