Expertiza_Wiki - User contributions [en]

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

2016-12-13T08:48:44Z

Zxiao2: /* UML Class Diagram */

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<ref>https://github.com/servo/servo/wiki/Form-validation-student-project</ref>

=='''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_validity_state_uml.png]]
<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_M1601_Implement_HTML5_form_validation</ref>

UML plot for HTML elements are shown below:

[[File:Servo_html_element_uml.png]]
<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_M1601_Implement_HTML5_form_validation</ref>

===Implement the checkValidity===
The major part of the design is to complete the implementation of ValidityStateMethods in servo/components/script/dom/validitystate.rs. The current existing codes are listed as follow:

<code>

impl ValidityStateMethods for ValidityState {
// https://html.spec.whatwg.org/multipage/#dom-validitystate-valuemissing
fn ValueMissing(&self) -> bool {
false
}

// https://html.spec.whatwg.org/multipage/#dom-validitystate-typemismatch
fn TypeMismatch(&self) -> bool {
false
}

// https://html.spec.whatwg.org/multipage/#dom-validitystate-patternmismatch
fn PatternMismatch(&self) -> bool {
false
}

// https://html.spec.whatwg.org/multipage/#dom-validitystate-toolong
fn TooLong(&self) -> bool {
false
}

// https://html.spec.whatwg.org/multipage/#dom-validitystate-tooshort
fn TooShort(&self) -> bool {
false
}

// https://html.spec.whatwg.org/multipage/#dom-validitystate-rangeunderflow
fn RangeUnderflow(&self) -> bool {
false
}

// https://html.spec.whatwg.org/multipage/#dom-validitystate-rangeoverflow
fn RangeOverflow(&self) -> bool {
false
}

// https://html.spec.whatwg.org/multipage/#dom-validitystate-stepmismatch
fn StepMismatch(&self) -> bool {
false
}

// https://html.spec.whatwg.org/multipage/#dom-validitystate-badinput
fn BadInput(&self) -> bool {
false
}

// https://html.spec.whatwg.org/multipage/#dom-validitystate-customerror
fn CustomError(&self) -> bool {
false
}

// https://html.spec.whatwg.org/multipage/#dom-validitystate-valid
fn Valid(&self) -> bool {
false
}
}

</code>

==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===
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:Servo html element uml.png

2016-12-13T08:45:57Z

Zxiao2:

File:Servo validity state uml.png

2016-12-13T08:45:32Z

Zxiao2:

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

2016-11-10T03:15:44Z

Zxiao2: /* Design Patterns & OO Practices */

=='''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 continueing projecy 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 bitflag change proposed last time. We will also follow servo project work flow as well as DRY priciple in OO design.

=='''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:32:17Z

Zxiao2: /* Test from UI */

=='''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

./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

2016-11-10T02:20:20Z

Zxiao2: /* Writing Assignments 2 */

[http://www.example.com link title]==Calibration Assignment Submissions==
*[[Calibration Assignment Submission (Firebrick JS)]]
*[[Calibration Assignment Submission (Active Job)]]
==Writing Assignments 2==
*[[CSC/ECE 517 Fall 2016/E1666. Test team functionality]]
*[[CSC/ECE 517 Fall 2016/E1643. Refactor Suggestion controller]]
*[[CSC/ECE 517 Fall 2016/E1631. Refactoring Bidding Interface]]
*[[CSC/ECE 517 Fall 2016/E1674.Refactor leaderboard.rb and write unit tests]]
*[[CSC/ECE 517 Fall 2016/E1671. Unit Tests for participants.rb Hierarchy]]
*[[CSC/ECE 517 Fall 2016/E1668.Test e-mailing functionality]]
*[[CSC/ECE 517 Fall 2016/E1658. Refractor lottery_controller.rb and write integration tests]]
*[[CSC/ECE 517 Fall 2016/E1660. Review requirements and thresholds]]
*[[CSC/ECE 517 Fall 2016/E1650. Sort instructor views alphabetically by default]]
*[[CSC/ECE 517 Fall 2016/E1644. Refactor and test Teams Controller]]
*[[CSC/ECE 517 Fall 2016/E1645. Refactoring Tree Display Controller]]
*[[CSC/ECE 517 Fall 2016/E1659. Refactor on_the_fly_calc.rb]]
*[[CSC/ECE 517 Fall 2016/E1657. Introduce a Student View for instructors]]
*[[CSC/ECE 517 Fall 2016/E1653. Fix and improve rubric criteria]]
*[[CSC/ECE 517 Fall 2016/E1642. Refactor review_response_map.rb]]
*[[CSC/ECE 517 Fall 2016/E1633. Refactor different question types from quiz feature]]
*[[CSC/ECE_517_Fall_2016/E1664:_Feature_Test_Assignment_Creation]]
*[[CSC/ECE 517 Fall 2016/E1666. Test team functionality]]
*[[CSC/ECE_517_Fall_2016/E1654. Improve_date-picker_and_deadlines]]
*[[CSC/ECE_517_Fall_2016/E1652 Fix teammate advertisements and requests to join a team ]]
*[[CSC/ECE_517_Fall_2016/E1662. UI issues/fixes]]
*[[CSC/ECE_517_Fall_2016/E1673. Refactor question_type.rb]]
*[[CSC/ECE_517_Fall_2016/E1675. Timestamp for student file & hyperlink submissions]]
*[[CSC/ECE_517_Fall_2016/E1640. Refactor response.rb and response_helper.rb]]
*[[CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due_date.rb and deadline_helper.rb]]
*[[CSC/ECE_517_Fall_2016/M1654._Improve_network_security_features]]
*[[CSC/ECE_517_Fall_2016/E1670._Unit_tests_for_answers.rb]]
*[[CSC/ECE_517_Fall_2016/E1641. Refactor review_mapping_controller.rb]]
*[[CSC/ECE_517_Fall_2016/M1652_Implement_ImageMap_Support_Servo]]
*[[CSC/ECE_517_Fall_2016/E1648/Add_past_due_assignment]]
*[[CSC/ECE 517 Fall 2016/E1656. Improve imports]]
*[[CSC/ECE_517_Fall_2016/M1653_Implement_HTML_form_validation]]
*[[CSC/ECE_517_Fall_2016/E1635._Refactor_join_team_requests_controller.rb_and_invitation_controller.rb]]

==Final Project Design Document==
*[[CSC/ECE 517 Fall 2016 E1696 Improve Self-Review]]
*[[CSC/ECE 517 Fall 2016 E1676 Role-based reviewing]]
*[[CSC/ECE 517 Fall 2016/E1680. Improve survey functionality]]
*[[CSC/ECE 517 Fall 2016/E1693. Drag-and-drop interface for creating rubrics]]
*[[CSC/ECE 517 Fall 2016/E1701. Accelerate RSpec testing]]
*[[CSC/ECE 517 Fall 2016/E1705. Tracking the time students look at the others' submissions]]
*[[CSC/ECE 517 Fall 2016/E1688. Send feedback to support + tree display improvement]]
*[[CSC/ECE 517 Fall 2016 E1707: Top trading cycles to exclude previous teammates]]
*[[CSC/ECE 517 Fall 2016 E1678: Review configuration options]]
*[[CSC/ECE 517 Fall 2016 E1682: Improve score calculation]]
*[[CSC/ECE 517 Fall 2016 E1684: Feature Test for Assignment Submission]]
*[[CSC/ECE 517 Fall 2016 E1689: Anonymous Chat Between Author and Reviewer]]
*[[CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza]]
*[[CSC/ECE 517 Fall 2016 E1708: Improvements to staggered-deadline assignments]]
*[[CSC/ECE 517 Fall 2016 E1685: UI changes for review and score reports]]
*[[CSC/ECE 517 Fall 2016/ M1653 Implement HTML form validation]]
*[[CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer]]
*[[CSC/ECE_517_Fall_2016/M1652_ImageMap_Support_Servo]]

CSC/ECE 517 Fall 2016/E1635. Refactor join team requests controller.rb and invitation controller.rb

2016-10-30T08:34:24Z

Zxiao2: /* Problem Statement */

== E1635. Refactor invitations controller.rb ==
This page provides a description of the Expertiza based OSS project.
===About Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.
===Problem Statement===
The following tasks were accomplished in this project:
* Renamed the "invitation_controller.rb" to "invitation_controller.rb"
* For simple if nested in else, we changed it to elsif and thus decreased number of layers in the if nest.
* For added comments to explains what each method does and explaining important variables
* refactored the create and update methods
* changed the wordings of the flash messages to make them more meaningful

== InvitationController==

* Rename to invitations_controller.rb, in accordance with current naming convention.
* Convert if nested inside else to elsif.
* Add comments explaining what each method does, and comments on how important variables are used.
* Refactor create and accept methods. Shorten and clarify them by adding private methods (e.g. extract a ready_to_join? method and call it from accept method)
* Change awkward flash messages.

== JoinTeamRequestsController==

* Add comments on some important variables.
* Convert if nested inside else to elsif
* Remove duplicate code: Common code in index, show and new method are moved into a private method.
* Create and update do not share any code. This raises the spectre of DRY problems. Make sure that all functionality used in creating a request is available when editing a request, and that no code is duplicated.
* Fix wording of message.

CSC/ECE 517 Fall 2016/E1635. Refactor join team requests controller.rb and invitation controller.rb

2016-10-30T06:37:29Z

Zxiao2: /* Problem Statement */