Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2016/Implement Common Parts of the CSSOM API

2016-04-08T22:22:10Z

Pkulkar5: /* Project Description */

=='''Introduction'''==

Cascading Style Sheets ([https://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS]) is a style sheet language used for describing the presentation of a document written in a markup language. Although most often used to set the visual style of web pages and user interfaces written in [https://en.wikipedia.org/wiki/HTML HTML] and [https://en.wikipedia.org/wiki/XHTML XHTML], the language can be applied to any [https://en.wikipedia.org/wiki/XML XML] document, including plain XML, [https://en.wikipedia.org/wiki/Scalable_Vector_Graphics SVG] and [https://en.wikipedia.org/wiki/XUL XUL], and is applicable to rendering in speech, or on other media. Along with HTML and [https://en.wikipedia.org/wiki/JavaScript JavaScript], CSS is a cornerstone technology used by most websites to create visually engaging webpages, user interfaces for web applications, and user interfaces for many mobile applications

==='''CSSOM'''===
CSSOM which is the CSS Object Model defines APIs (including generic parsing and serialization rules) for media queries, selectors, and CSS itself<ref>https://drafts.csswg.org/cssom/</ref>. The core features of the CSSOM are oriented towards providing basic capabilities to author-defined scripts to permit access to and manipulation of style related state information and processes. CSSOM aims at proving a way to access the CSS style classes and properties. One can even modify the CSS rules using this API. These changes can be targeted to affect individual elements or the whole webpage. <ref>https://github.com/servo/servo/wiki/CSSOM-student-project</ref>. CSSOM is actually a collection of all the CSS stylesheets found on a web page which is very similar to Document Object Model (DOM) but only stores collection of CSS instead of HTML. <ref>https://varvy.com/performance/cssom.html</ref>. CSSOM identifies which elements on your webpage require styling and modifies them. It is also used to optimize the speed at which webpages get loaded.
It is an integral part of the process that is used to display content on a webpage. The web browser first creates a DOM by examining the HTMLs, then creates a CSSOM by examining the CSS stylesheets. It then creates a render tree by comibining the DOM and the CSSOM and displays the webpage.<ref>https://varvy.com/performance/cssom.html</ref>.

==='''Rust'''===

We can organize different languages on a spectrum with control on one end and safety on the other. Languages like C and C++ fall on the end of the side of control, where as on the other side we have languages like Javascript, Ruby, Python, etc. What Rust does is stepping off this line. What it does is not a tradeoff between control and safety, but it provides you both the low level of control found in C and C++, and the high level of safety in JavaScript and Python. The three concepts that distinguish rust from other programming languages are: Ownership, Borrowing and lifetime. Ownership is how Rust achieves its largest goal, memory safety.<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>

==='''Servo'''===

Servo is a project in [https://en.wikipedia.org/wiki/Mozilla Mozilla] research to write a parallel layout engine in Rust. It aims to achieve better parallelism, security, modularity and performance. Servo is built with Cargo, the rust package manager. It currently supports 64bit OSX, 64bit Linux, Android, and Gonk(Firefox OS).<ref>https://servo.org</ref>

=='''Project Description'''==

The project is to go through the following steps in a somewhat linear order:
*Compiling servo on a machine and making sure it runs on a specific url. Then emailing the mozilla mailing list to introduce the group.
*Creating a StyleSheet interface which represents an abstract, base style sheet. This creation requires a couple of steps :
**Adding a new IDL file (which contains specifications)
**Creating the Rust file which has implementations of the things specified in IDL.
**Listing the Rust file in mod.rs file.
*After that comes the creation of a StyleSheetList interface. Which represents an ordered collection of CSS style sheets. And basically because it's another interface, again the .webidl and .rs files need to be implemented.
*Adding the attribute <code>stylesheets</code> to the <code>Document.webidl</code>.
*In the three steps just mentioned some guidelines about implementation must be followed, like the return types of certain methods.
*Run the tests specified by the mozilla team.
*Finally updating the interfaces.html, and adding the new interface names.

The Subsequent steps are:
*making the <code>stylesheets</code> member of <code>Document</code> store the associated <code>Element</code> along with the actual implementation of <code>Stylesheet</code> and adding a member to <code>StyleSheet</code> for the associated element, and implement the <code>ownerNode</code> attribute of <code>StyleSheet</code> using this.
*create the CSSStyleSheet interface, containing an <code>Arc<Stylesheet></code> member. Add a method to <code>Document</code> that returns a new <code>CSSStyleSheet</code> instance for a particular index in the <code>stylesheets</code> member.
*creating the CSSRule interface which represents an abstract, base CSS Rule. It is done using the Webidl format.
*creating the CSSRuleList interface and implementing <code>CSSStyleSheet.cssRules</code> which is an array like object containing an ordered collection of CSS rules.
*implementing the <code>insertRule</code> and <code>deleteRule</code> methods of <code>CSSStyleSheet</code> to allow mutation of the contents of the vector in the <code>rules</code> member of the <code>Stylesheet</code>.
*creating the CSSStyleRule interface that extends the CSSRule interface and making <code>cssRules</code> return <code>CSSStyleRule</code> values for appropriate rules.

=='''Implementation'''==
==='''Initial Steps'''===
The following steps were followed to meet the project requirements as per this github page.
===='''Step 1'''====
We had to implement the StyleSheet interface for which we had to create two file: stylesheet.rs and StyleSheet.webidl and included stylesheet interface in the mod.rs file.
In the StyleSheet interface we avoided the three methods: ownerNode, parentStyleSheet and media as they could not be trivially implemented and the instructions were clear to avoid such methods.

===='''Step 2'''====
We had to implement StyleSheetList interface for which we had to create two file: stylesheetlist.rs and StyleSheetList.webidl and included stylesheetlist interface in the mod.rs file.
We used JS<Document> instead of [ArrayClass] as [ArrayClass] is not yet supported by Servo.
In the StyleSheetList interface we did not implement the getter as we do not have a list of stylesheets/scripts/dom.

===='''Step 3'''====
We had to implement a partial interface Document with an attribute as styleSheets. The declaration of the interface was done in Document.webidl and its implementation was done in document.rs file. The implementation returned a new instance of StyleSheetList referencing the current document.

==='''Subsequent Steps'''===

===='''Step 1'''====

We will be making changes in the <code>Document.rs</code> file to make the <code>stylesheets</code> member store the associated <code>Element</code>. We're also going to implement the following:

===='''Step 2'''====

We will also implement the <code>.webidl</code> and <code>.rs</code> files for the following:

*CSSStyleSheet interface
*CSSRule interface
*CSSRuleList interface
*CSSStyleRule interface

=='''Design Principles'''==
In this mozilla project, we are asked to strictly follow the existing design patterns and coding conventions. The main aim of this project is to add and modify interfaces. Interfaces allow developers to follow a clean design principle wherein they do not have to program to classes. It is too easy to add a dependency on a class. In order to avoid that kind of dependency on the implementation i.e. classes, developers can program to interfaces. This type of design pattern is an architectural pattern and makes the code more modular and object oriented. Programming to an interface has a flavor of DRY principle because even if the underlying implementation changes, the handle to the implementation is an interface and that does not change. In this way, our mozilla project becomes more modular and object oriented. Servo has a utility of tests that checks the coding standards followed by Mozilla on this project. We will execute the following utility tests command.
<code>./mach test-tidy</code> Any issues encountered by executing this test can be flagged before generating the pull request. This ensures that the developers follow the coding standards.

=='''Testing'''==
Following are the steps to run all the tests:
1. Install the pre-requisites required for servo as mentioned here
2. Run the following commands
cd
git clone https://github.com/mohammed-alfatih/servo.git
cd servo
./mach build --release
'''Note''': It may take around 30 mins to build
./mach test-wpt /tests/wpt/html/dom/interfaces.html
You will see that all tests pass as expected.

'''Note''': There were no predefined test cases mentioned for our project. So now you will see 0 testcases. As far as we know there is no way to test this from UI.

=='''Conclusion'''==
We have tried to implement the most commonly-used portions of the CSSOM API specification to increase Servo's compatibility with existing webpages <ref>https://github.com/servo/servo/wiki/CSSOM-student-project</ref>. We have created two interfaces, StyleSheet and StyleSheetList in our initial steps. As a part of our subsequent steps, we would be adding 4 new interfaces: CSSStyleSheet, CSSRule, CSSRuleList and the CSSStyleRule interface. We have implemented only the obvious methods for these interfaces so that more advanced work can be done to make this CSSOM API fully functional keeping our work as the basis.

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

CSC/ECE 517 Spring 2016/Implement Common Parts of the CSSOM API

2016-04-08T22:21:00Z

Pkulkar5: /* Project Description */

=='''Introduction'''==

Cascading Style Sheets ([https://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS]) is a style sheet language used for describing the presentation of a document written in a markup language. Although most often used to set the visual style of web pages and user interfaces written in [https://en.wikipedia.org/wiki/HTML HTML] and [https://en.wikipedia.org/wiki/XHTML XHTML], the language can be applied to any [https://en.wikipedia.org/wiki/XML XML] document, including plain XML, [https://en.wikipedia.org/wiki/Scalable_Vector_Graphics SVG] and [https://en.wikipedia.org/wiki/XUL XUL], and is applicable to rendering in speech, or on other media. Along with HTML and [https://en.wikipedia.org/wiki/JavaScript JavaScript], CSS is a cornerstone technology used by most websites to create visually engaging webpages, user interfaces for web applications, and user interfaces for many mobile applications

==='''CSSOM'''===
CSSOM which is the CSS Object Model defines APIs (including generic parsing and serialization rules) for media queries, selectors, and CSS itself<ref>https://drafts.csswg.org/cssom/</ref>. The core features of the CSSOM are oriented towards providing basic capabilities to author-defined scripts to permit access to and manipulation of style related state information and processes. CSSOM aims at proving a way to access the CSS style classes and properties. One can even modify the CSS rules using this API. These changes can be targeted to affect individual elements or the whole webpage. <ref>https://github.com/servo/servo/wiki/CSSOM-student-project</ref>. CSSOM is actually a collection of all the CSS stylesheets found on a web page which is very similar to Document Object Model (DOM) but only stores collection of CSS instead of HTML. <ref>https://varvy.com/performance/cssom.html</ref>. CSSOM identifies which elements on your webpage require styling and modifies them. It is also used to optimize the speed at which webpages get loaded.
It is an integral part of the process that is used to display content on a webpage. The web browser first creates a DOM by examining the HTMLs, then creates a CSSOM by examining the CSS stylesheets. It then creates a render tree by comibining the DOM and the CSSOM and displays the webpage.<ref>https://varvy.com/performance/cssom.html</ref>.

==='''Rust'''===

We can organize different languages on a spectrum with control on one end and safety on the other. Languages like C and C++ fall on the end of the side of control, where as on the other side we have languages like Javascript, Ruby, Python, etc. What Rust does is stepping off this line. What it does is not a tradeoff between control and safety, but it provides you both the low level of control found in C and C++, and the high level of safety in JavaScript and Python. The three concepts that distinguish rust from other programming languages are: Ownership, Borrowing and lifetime. Ownership is how Rust achieves its largest goal, memory safety.<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>

==='''Servo'''===

Servo is a project in [https://en.wikipedia.org/wiki/Mozilla Mozilla] research to write a parallel layout engine in Rust. It aims to achieve better parallelism, security, modularity and performance. Servo is built with Cargo, the rust package manager. It currently supports 64bit OSX, 64bit Linux, Android, and Gonk(Firefox OS).<ref>https://servo.org</ref>

=='''Project Description'''==

The project is to go through the following steps in a somewhat linear order:
*Compiling servo on a machine and making sure it runs on a specific url. Then emailing the mozilla mailing list to introduce the group.
*Creating a StyleSheet interface which represents an abstract, base style sheet. This creation requires a couple of steps :
**Adding a new IDL file (which contains specifications)
**Creating the Rust file which has implementations of the things specified in IDL.
**Listing the Rust file in mod.rs file.
*After that comes the creation of a StyleSheetList interface. Which represents an ordered collection of CSS style sheets. And basically because it's another interface, again the .webidl and .rs files need to be implemented.
*Adding the attribute <code>stylesheets</code> to the <code>Document.webidl</code>.
*In the three steps just mentioned some guidelines about implementation must be followed, like the return types of certain methods.
*Run the tests specified by the mozilla team.
*Finally updating the interfaces.html, and adding the new interface names.

The Subsequent steps are:
*to make the <code>stylesheets</code> member of <code>Document</code> store the associated <code>Element</code> along with the actual <code>Stylesheet</code>. Add a member to <code>StyleSheet</code> for the associated element, and implement the <code>ownerNode</code> attribute of <code>StyleSheet</code> using this.
*create the CSSStyleSheet interface, containing an <code>Arc<Stylesheet></code> member. Add a method to <code>Document</code> that returns a new <code>CSSStyleSheet</code> instance for a particular index in the <code>stylesheets</code> member.
*creating the CSSRule interface which represents an abstract, base CSS Rule. It is done using the Webidl format.
*creating the CSSRuleList interface and implementing <code>CSSStyleSheet.cssRules</code> which is an array like object containing an ordered collection of CSS rules.
*implementing the <code>insertRule</code> and <code>deleteRule</code> methods of <code>CSSStyleSheet</code> to allow mutation of the contents of the vector in the <code>rules</code> member of the <code>Stylesheet</code>.
*creating the CSSStyleRule interface that extends the CSSRule interface and making <code>cssRules</code> return <code>CSSStyleRule</code> values for appropriate rules.

=='''Implementation'''==
==='''Initial Steps'''===
The following steps were followed to meet the project requirements as per this github page.
===='''Step 1'''====
We had to implement the StyleSheet interface for which we had to create two file: stylesheet.rs and StyleSheet.webidl and included stylesheet interface in the mod.rs file.
In the StyleSheet interface we avoided the three methods: ownerNode, parentStyleSheet and media as they could not be trivially implemented and the instructions were clear to avoid such methods.

===='''Step 2'''====
We had to implement StyleSheetList interface for which we had to create two file: stylesheetlist.rs and StyleSheetList.webidl and included stylesheetlist interface in the mod.rs file.
We used JS<Document> instead of [ArrayClass] as [ArrayClass] is not yet supported by Servo.
In the StyleSheetList interface we did not implement the getter as we do not have a list of stylesheets/scripts/dom.

===='''Step 3'''====
We had to implement a partial interface Document with an attribute as styleSheets. The declaration of the interface was done in Document.webidl and its implementation was done in document.rs file. The implementation returned a new instance of StyleSheetList referencing the current document.

==='''Subsequent Steps'''===

===='''Step 1'''====

We will be making changes in the <code>Document.rs</code> file to make the <code>stylesheets</code> member store the associated <code>Element</code>. We're also going to implement the following:

===='''Step 2'''====

We will also implement the <code>.webidl</code> and <code>.rs</code> files for the following:

*CSSStyleSheet interface
*CSSRule interface
*CSSRuleList interface
*CSSStyleRule interface

=='''Design Principles'''==
In this mozilla project, we are asked to strictly follow the existing design patterns and coding conventions. The main aim of this project is to add and modify interfaces. Interfaces allow developers to follow a clean design principle wherein they do not have to program to classes. It is too easy to add a dependency on a class. In order to avoid that kind of dependency on the implementation i.e. classes, developers can program to interfaces. This type of design pattern is an architectural pattern and makes the code more modular and object oriented. Programming to an interface has a flavor of DRY principle because even if the underlying implementation changes, the handle to the implementation is an interface and that does not change. In this way, our mozilla project becomes more modular and object oriented. Servo has a utility of tests that checks the coding standards followed by Mozilla on this project. We will execute the following utility tests command.
<code>./mach test-tidy</code> Any issues encountered by executing this test can be flagged before generating the pull request. This ensures that the developers follow the coding standards.

=='''Testing'''==
Following are the steps to run all the tests:
1. Install the pre-requisites required for servo as mentioned here
2. Run the following commands
cd
git clone https://github.com/mohammed-alfatih/servo.git
cd servo
./mach build --release
'''Note''': It may take around 30 mins to build
./mach test-wpt /tests/wpt/html/dom/interfaces.html
You will see that all tests pass as expected.

'''Note''': There were no predefined test cases mentioned for our project. So now you will see 0 testcases. As far as we know there is no way to test this from UI.

=='''Conclusion'''==
We have tried to implement the most commonly-used portions of the CSSOM API specification to increase Servo's compatibility with existing webpages <ref>https://github.com/servo/servo/wiki/CSSOM-student-project</ref>. We have created two interfaces, StyleSheet and StyleSheetList in our initial steps. As a part of our subsequent steps, we would be adding 4 new interfaces: CSSStyleSheet, CSSRule, CSSRuleList and the CSSStyleRule interface. We have implemented only the obvious methods for these interfaces so that more advanced work can be done to make this CSSOM API fully functional keeping our work as the basis.

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

CSC/ECE 517 Spring 2016/Implement Common Parts of the CSSOM API

2016-04-08T21:26:31Z

Pkulkar5:

=='''Introduction'''==

Cascading Style Sheets ([https://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS]) is a style sheet language used for describing the presentation of a document written in a markup language. Although most often used to set the visual style of web pages and user interfaces written in [https://en.wikipedia.org/wiki/HTML HTML] and [https://en.wikipedia.org/wiki/XHTML XHTML], the language can be applied to any [https://en.wikipedia.org/wiki/XML XML] document, including plain XML, [https://en.wikipedia.org/wiki/Scalable_Vector_Graphics SVG] and [https://en.wikipedia.org/wiki/XUL XUL], and is applicable to rendering in speech, or on other media. Along with HTML and [https://en.wikipedia.org/wiki/JavaScript JavaScript], CSS is a cornerstone technology used by most websites to create visually engaging webpages, user interfaces for web applications, and user interfaces for many mobile applications

==='''CSSOM'''===
CSSOM which is the CSS Object Model defines APIs (including generic parsing and serialization rules) for media queries, selectors, and CSS itself<ref>https://drafts.csswg.org/cssom/</ref>. The core features of the CSSOM are oriented towards providing basic capabilities to author-defined scripts to permit access to and manipulation of style related state information and processes. CSSOM aims at proving a way to access the CSS style classes and properties. One can even modify the CSS rules using this API. These changes can be targeted to affect individual elements or the whole webpage. <ref>https://github.com/servo/servo/wiki/CSSOM-student-project</ref>. CSSOM is actually a collection of all the CSS stylesheets found on a web page which is very similar to Document Object Model (DOM) but only stores collection of CSS instead of HTML. <ref>https://varvy.com/performance/cssom.html</ref>. CSSOM identifies which elements on your webpage require styling and modifies them. It is also used to optimize the speed at which webpages get loaded.
It is an integral part of the process that is used to display content on a webpage. The web browser first creates a DOM by examining the HTMLs, then creates a CSSOM by examining the CSS stylesheets. It then creates a render tree by comibining the DOM and the CSSOM and displays the webpage.<ref>https://varvy.com/performance/cssom.html</ref>.

==='''Rust'''===

We can organize different languages on a spectrum with control on one end and safety on the other. Languages like C and C++ fall on the end of the side of control, where as on the other side we have languages like Javascript, Ruby, Python, etc. What Rust does is stepping off this line. What it does is not a tradeoff between control and safety, but it provides you both the low level of control found in C and C++, and the high level of safety in JavaScript and Python. The three concepts that distinguish rust from other programming languages are: Ownership, Borrowing and lifetime. Ownership is how Rust achieves its largest goal, memory safety.<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>

==='''Servo'''===

Servo is a project in [https://en.wikipedia.org/wiki/Mozilla Mozilla] research to write a parallel layout engine in Rust. It aims to achieve better parallelism, security, modularity and performance. Servo is built with Cargo, the rust package manager. It currently supports 64bit OSX, 64bit Linux, Android, and Gonk(Firefox OS).<ref>https://servo.org</ref>

=='''Project Description'''==

The project is to go through the following steps in a somewhat linear order:
*Compiling servo on a machine and making sure it runs on a specific url. Then emailing the mozilla mailing list to introduce the group.
*Creating a StyleSheet interface which represents an abstract, base style sheet. This creation requires a couple of steps :
**Adding a new IDL file (which contains specifications)
**Creating the Rust file which has implementations of the things specified in IDL.
**Listing the Rust file in mod.rs file.
*After that comes the creation of a StyleSheetList interface. Which represents an ordered collection of CSS style sheets. And basically because it's another interface, again the .webidl and .rs files need to be implemented.
*Adding the attribute <code>stylesheets</code> to the <code>Document.webidl</code>.
*In the three steps just mentioned some guidelines about implementation must be followed, like the return types of certain methods.
*Run the tests specified by the mozilla team.
*Finally updating the interfaces.html, and adding the new interface names.

The Subsequent steps are:
*to make the <code>stylesheets</code> member of <code>Document</code> store the associated <code>Element</code> along with the actual <code>Stylesheet</code>. Add a member to <code>StyleSheet</code> for the associated element, and implement the <code>ownerNode</code> attribute of <code>StyleSheet</code> using this.
*create the CSSStyleSheet interface, containing an <code>Arc<Stylesheet></code> member. Add a method to <code>Document</code> that returns a new <code>CSSStyleSheet</code> instance for a particular index in the <code>stylesheets</code> member.
*create the CSSRule interface.
*create the CSSRuleList interface and implement <code>CSSStyleSheet.cssRules</code>.
*implement the <code>insertRule</code> and <code>deleteRule</code> methods of <code>CSSStyleSheet</code> by making the <code>rules</code> member of the <code>Stylesheet</code> type contain a RefCell, and using this to mutate the contents of the vector.
*create the CSSStyleRule interface and make <code>cssRules</code> return <code>CSSStyleRule</code> values for appropriate rules.

=='''Implementation'''==
==='''Initial Steps'''===
The following steps were followed to meet the project requirements as per this github page.
===='''Step 1'''====
We had to implement the StyleSheet interface for which we had to create two file: stylesheet.rs and StyleSheet.webidl and included stylesheet interface in the mod.rs file.
In the StyleSheet interface we avoided the three methods: ownerNode, parentStyleSheet and media as they could not be trivially implemented and the instructions were clear to avoid such methods.

===='''Step 2'''====
We had to implement StyleSheetList interface for which we had to create two file: stylesheetlist.rs and StyleSheetList.webidl and included stylesheetlist interface in the mod.rs file.
We used JS<Document> instead of [ArrayClass] as [ArrayClass] is not yet supported by Servo.
In the StyleSheetList interface we did not implement the getter as we do not have a list of stylesheets/scripts/dom.

===='''Step 3'''====
We had to implement a partial interface Document with an attribute as styleSheets. The declaration of the interface was done in Document.webidl and its implementation was done in document.rs file. The implementation returned a new instance of StyleSheetList referencing the current document.

==='''Subsequent Steps'''===

===='''Step 1'''====

We will be making changes in the <code>Document.rs</code> file to make the <code>stylesheets</code> member store the associated <code>Element</code>. We're also going to implement the following:

===='''Step 2'''====

We will also implement the <code>.webidl</code> and <code>.rs</code> files for the following:

*CSSStyleSheet interface
*CSSRule interface
*CSSRuleList interface
*CSSStyleRule interface

=='''Design Principles'''==
In this mozilla project, we are asked to strictly follow the existing design patterns and coding conventions. The main aim of this project is to add and modify interfaces. Interfaces allow developers to follow a clean design principle wherein they do not have to program to classes. It is too easy to add a dependency on a class. In order to avoid that kind of dependency on the implementation i.e. classes, developers can program to interfaces. This type of design pattern is an architectural pattern and makes the code more modular and object oriented. Programming to an interface has a flavor of DRY principle because even if the underlying implementation changes, the handle to the implementation is an interface and that does not change. In this way, our mozilla project becomes more modular and object oriented. Servo has a utility of tests that checks the coding standards followed by Mozilla on this project. We will execute the following utility tests command.
<code>./mach test-tidy</code> Any issues encountered by executing this test can be flagged before generating the pull request. This ensures that the developers follow the coding standards.

=='''Testing'''==
Following are the steps to run all the tests:
1. Install the pre-requisites required for servo as mentioned here
2. Run the following commands
cd
git clone https://github.com/mohammed-alfatih/servo.git
cd servo
./mach build --release
'''Note''': It may take around 30 mins to build
./mach test-wpt /tests/wpt/html/dom/interfaces.html
You will see that all tests pass as expected.

'''Note''': There were no predefined test cases mentioned for our project. So now you will see 0 testcases. As far as we know there is no way to test this from UI.

=='''Conclusion'''==
We have tried to implement the most commonly-used portions of the CSSOM API specification to increase Servo's compatibility with existing webpages <ref>https://github.com/servo/servo/wiki/CSSOM-student-project</ref>. We have created two interfaces, StyleSheet and StyleSheetList in our initial steps. As a part of our subsequent steps, we would be adding 4 new interfaces: CSSStyleSheet, CSSRule, CSSRuleList and the CSSStyleRule interface. We have implemented only the obvious methods for these interfaces so that more advanced work can be done to make this CSSOM API fully functional keeping our work as the basis.

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

CSC/ECE 517 Spring 2016/Implement Common Parts of the CSSOM API

2016-04-08T20:43:21Z

Pkulkar5: /* Rust */

=='''Introduction'''==

Cascading Style Sheets ([https://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS]) is a style sheet language used for describing the presentation of a document written in a markup language. Although most often used to set the visual style of web pages and user interfaces written in [https://en.wikipedia.org/wiki/HTML HTML] and [https://en.wikipedia.org/wiki/XHTML XHTML], the language can be applied to any [https://en.wikipedia.org/wiki/XML XML] document, including plain XML, [https://en.wikipedia.org/wiki/Scalable_Vector_Graphics SVG] and [https://en.wikipedia.org/wiki/XUL XUL], and is applicable to rendering in speech, or on other media. Along with HTML and [https://en.wikipedia.org/wiki/JavaScript JavaScript], CSS is a cornerstone technology used by most websites to create visually engaging webpages, user interfaces for web applications, and user interfaces for many mobile applications

=='''CSSOM'''==
CSSOM (CSS object model) defines [https://en.wikipedia.org/wiki/Application_programming_interface APIs] (including generic parsing and serialization rules) for media queries, selectors, and CSS itself.
The core features of the CSSOM are oriented towards providing basic capabilities to author-defined scripts to permit access to and manipulation of style related state information and processes.

=='''Rust'''==

We can organize different languages on a spectrum with control on one end and safety on the other. Languages like C and C++ fall on the end of the side of control, where as on the other side we have languages like Javascript, Ruby, Python, etc. What Rust does is stepping off this line. What it does is not a tradeoff between control and safety, but it provides you both the low level of control found in C and C++, and the high level of safety in JavaScript and Python. The three concepts that distinguish rust from other programming languages are: Ownership, Borrowing and lifetime. Ownership is how Rust achieves its largest goal, memory safety.<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>

=='''Servo'''==

Servo is a project in [https://en.wikipedia.org/wiki/Mozilla Mozilla] research to write a parallel layout engine in Rust. It aims to achieve better parallelism, security, modularity and performance. Servo is built with Cargo, the rust package manager. It currently supports 64bit OSX, 64bit Linux, Android, and Gonk(Firefox OS).<ref>https://servo.org</ref>

=='''Project Description'''==

The project initial steps were described as the following:
*compile Servo and ensure that it runs on <code>tests/html/about-mozilla.html</code>
*email the <code>mozilla.dev.servo</code> mailing list introducing your group and your progress
*create the <code>StyleSheet</code> interface. See the documentation for how to go about this. Comment out any method in the WebIDL that cannot be trivially implemented according to the specification.
*create the <code>StyleSheetList</code> interface. Leave <code>[ArrayClass]</code> commented out, since it is not yet supported by Servo. Store a <code>JS<Document></code> member to allow accessing a document's stylesheets.
*add the <code>styleSheets</code> attribute from the Document extension to <code>Document.webidl</code>, and make it return a new instance of <code>StyleSheetList</code> referencing the current document.
*run <code>./mach test-wpt</code> <code>/tests/wpt/html/dom/interfaces.html</code> and update the test result expectations according to the documentation
*update <code>tests/wpt/mozilla/tests/mozilla/interfaces.html</code> to add the new interface names and allow the test to pass

The Subsequent steps are:
*to make the <code>stylesheets</code> member of <code>Document</code> store the associated <code>Element</code> along with the actual <code>Stylesheet</code>. Add a member to <code>StyleSheet</code> for the associated element, and implement the <code>ownerNode</code> attribute of <code>StyleSheet</code> using this.
*create the CSSStyleSheet interface, containing an <code>Arc<Stylesheet></code> member. Add a method to <code>Document</code> that returns a new <code>CSSStyleSheet</code> instance for a particular index in the <code>stylesheets</code> member.
*create the CSSRule interface.
*create the CSSRuleList interface and implement <code>CSSStyleSheet.cssRules</code>.
*implement the <code>insertRule</code> and <code>deleteRule</code> methods of <code>CSSStyleSheet</code> by making the <code>rules</code> member of the <code>Stylesheet</code> type contain a RefCell, and using this to mutate the contents of the vector.
*create the CSSStyleRule interface and make <code>cssRules</code> return <code>CSSStyleRule</code> values for appropriate rules.

=='''Implementation'''==
==='''Initial Steps'''===
The following steps were followed to meet the project requirements as per this github page.
===='''Step 1'''====
We had to implement the StyleSheet interface for which we had to create two file: stylesheet.rs and StyleSheet.webidl and included stylesheet interface in the mod.rs file.
In the StyleSheet interface we avoided the three methods: ownerNode, parentStyleSheet and media as they could not be trivially implemented and the instructions were clear to avoid such methods.

===='''Step 2'''====
We had to implement StyleSheetList interface for which we had to create two file: stylesheetlist.rs and StyleSheetList.webidl and included stylesheetlist interface in the mod.rs file.
We used JS<Document> instead of [ArrayClass] as [ArrayClass] is not yet supported by Servo.
In the StyleSheetList interface we did not implement the getter as we do not have a list of stylesheets/scripts/dom.

===='''Step 3'''====
We had to implement a partial interface Document with an attribute as styleSheets. The declaration of the interface was done in Document.webidl and its implementation was done in document.rs file. The implementation returned a new instance of StyleSheetList referencing the current document.

==='''Subsequent Steps'''===

===='''Step 1'''====

We will be making changes in the <code>Document.rs</code> file to make the <code>stylesheets</code> member store the associated <code>Element</code>. We're also going to implement the following:

===='''Step 2'''====

We will also implement the <code>.webidl</code> and <code>.rs</code> files for the following:

*CSSStyleSheet interface
*CSSRule interface
*CSSRuleList interface
*CSSStyleRule interface

=='''Testing'''==
Following are the steps to run all the tests:
1. Install the pre-requisites required for servo as mentioned here
2. Run the following commands
cd
git clone https://github.com/mohammed-alfatih/servo.git
cd servo
./mach build --release
'''Note''': It may take around 30 mins to build
./mach test-wpt /tests/wpt/html/dom/interfaces.html
You will see that all tests pass as expected.

'''Note''': There were no predefined test cases mentioned for our project. So now you will see 0 testcases. As far as we know there is no way to test this from UI.

=='''Conclusion'''==
We added the two new interfaces in tests/wpt/mozilla/tests/mozilla/interfaces.html.

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

CSC/ECE 517 Spring 2016/Implement Common Parts of the CSSOM API

2016-04-08T20:43:04Z

Pkulkar5: /* Servo */

=='''Introduction'''==

Cascading Style Sheets ([https://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS]) is a style sheet language used for describing the presentation of a document written in a markup language. Although most often used to set the visual style of web pages and user interfaces written in [https://en.wikipedia.org/wiki/HTML HTML] and [https://en.wikipedia.org/wiki/XHTML XHTML], the language can be applied to any [https://en.wikipedia.org/wiki/XML XML] document, including plain XML, [https://en.wikipedia.org/wiki/Scalable_Vector_Graphics SVG] and [https://en.wikipedia.org/wiki/XUL XUL], and is applicable to rendering in speech, or on other media. Along with HTML and [https://en.wikipedia.org/wiki/JavaScript JavaScript], CSS is a cornerstone technology used by most websites to create visually engaging webpages, user interfaces for web applications, and user interfaces for many mobile applications

=='''CSSOM'''==
CSSOM (CSS object model) defines [https://en.wikipedia.org/wiki/Application_programming_interface APIs] (including generic parsing and serialization rules) for media queries, selectors, and CSS itself.
The core features of the CSSOM are oriented towards providing basic capabilities to author-defined scripts to permit access to and manipulation of style related state information and processes.

=='''Rust'''==

We can organize different languages on a spectrum with control on one end and safety on the other. Languages like C and C++ fall on the end of the side of control, where as on the other side we have languages like Javascript, Ruby, Python, etc. What Rust does is stepping off this line. What it does is not a tradeoff between control and safety, but it provides you both the low level of control found in C and C++, and the high level of safety in JavaScript and Python. The three concepts that distinguish rust from other programming languages are: Ownership, Borrowing and lifetime. Ownership is how Rust achieves its largest goal, memory safety. <ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>

=='''Servo'''==

Servo is a project in [https://en.wikipedia.org/wiki/Mozilla Mozilla] research to write a parallel layout engine in Rust. It aims to achieve better parallelism, security, modularity and performance. Servo is built with Cargo, the rust package manager. It currently supports 64bit OSX, 64bit Linux, Android, and Gonk(Firefox OS).<ref>https://servo.org</ref>

=='''Project Description'''==

The project initial steps were described as the following:
*compile Servo and ensure that it runs on <code>tests/html/about-mozilla.html</code>
*email the <code>mozilla.dev.servo</code> mailing list introducing your group and your progress
*create the <code>StyleSheet</code> interface. See the documentation for how to go about this. Comment out any method in the WebIDL that cannot be trivially implemented according to the specification.
*create the <code>StyleSheetList</code> interface. Leave <code>[ArrayClass]</code> commented out, since it is not yet supported by Servo. Store a <code>JS<Document></code> member to allow accessing a document's stylesheets.
*add the <code>styleSheets</code> attribute from the Document extension to <code>Document.webidl</code>, and make it return a new instance of <code>StyleSheetList</code> referencing the current document.
*run <code>./mach test-wpt</code> <code>/tests/wpt/html/dom/interfaces.html</code> and update the test result expectations according to the documentation
*update <code>tests/wpt/mozilla/tests/mozilla/interfaces.html</code> to add the new interface names and allow the test to pass

The Subsequent steps are:
*to make the <code>stylesheets</code> member of <code>Document</code> store the associated <code>Element</code> along with the actual <code>Stylesheet</code>. Add a member to <code>StyleSheet</code> for the associated element, and implement the <code>ownerNode</code> attribute of <code>StyleSheet</code> using this.
*create the CSSStyleSheet interface, containing an <code>Arc<Stylesheet></code> member. Add a method to <code>Document</code> that returns a new <code>CSSStyleSheet</code> instance for a particular index in the <code>stylesheets</code> member.
*create the CSSRule interface.
*create the CSSRuleList interface and implement <code>CSSStyleSheet.cssRules</code>.
*implement the <code>insertRule</code> and <code>deleteRule</code> methods of <code>CSSStyleSheet</code> by making the <code>rules</code> member of the <code>Stylesheet</code> type contain a RefCell, and using this to mutate the contents of the vector.
*create the CSSStyleRule interface and make <code>cssRules</code> return <code>CSSStyleRule</code> values for appropriate rules.

=='''Implementation'''==
==='''Initial Steps'''===
The following steps were followed to meet the project requirements as per this github page.
===='''Step 1'''====
We had to implement the StyleSheet interface for which we had to create two file: stylesheet.rs and StyleSheet.webidl and included stylesheet interface in the mod.rs file.
In the StyleSheet interface we avoided the three methods: ownerNode, parentStyleSheet and media as they could not be trivially implemented and the instructions were clear to avoid such methods.

===='''Step 2'''====
We had to implement StyleSheetList interface for which we had to create two file: stylesheetlist.rs and StyleSheetList.webidl and included stylesheetlist interface in the mod.rs file.
We used JS<Document> instead of [ArrayClass] as [ArrayClass] is not yet supported by Servo.
In the StyleSheetList interface we did not implement the getter as we do not have a list of stylesheets/scripts/dom.

===='''Step 3'''====
We had to implement a partial interface Document with an attribute as styleSheets. The declaration of the interface was done in Document.webidl and its implementation was done in document.rs file. The implementation returned a new instance of StyleSheetList referencing the current document.

==='''Subsequent Steps'''===

===='''Step 1'''====

We will be making changes in the <code>Document.rs</code> file to make the <code>stylesheets</code> member store the associated <code>Element</code>. We're also going to implement the following:

===='''Step 2'''====

We will also implement the <code>.webidl</code> and <code>.rs</code> files for the following:

*CSSStyleSheet interface
*CSSRule interface
*CSSRuleList interface
*CSSStyleRule interface

=='''Testing'''==
Following are the steps to run all the tests:
1. Install the pre-requisites required for servo as mentioned here
2. Run the following commands
cd
git clone https://github.com/mohammed-alfatih/servo.git
cd servo
./mach build --release
'''Note''': It may take around 30 mins to build
./mach test-wpt /tests/wpt/html/dom/interfaces.html
You will see that all tests pass as expected.

'''Note''': There were no predefined test cases mentioned for our project. So now you will see 0 testcases. As far as we know there is no way to test this from UI.

=='''Conclusion'''==
We added the two new interfaces in tests/wpt/mozilla/tests/mozilla/interfaces.html.

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

CSC/ECE 517 Spring 2016/Implement Common Parts of the CSSOM API

2016-04-08T20:42:26Z

Pkulkar5: /* Servo */

=='''Introduction'''==

Cascading Style Sheets ([https://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS]) is a style sheet language used for describing the presentation of a document written in a markup language. Although most often used to set the visual style of web pages and user interfaces written in [https://en.wikipedia.org/wiki/HTML HTML] and [https://en.wikipedia.org/wiki/XHTML XHTML], the language can be applied to any [https://en.wikipedia.org/wiki/XML XML] document, including plain XML, [https://en.wikipedia.org/wiki/Scalable_Vector_Graphics SVG] and [https://en.wikipedia.org/wiki/XUL XUL], and is applicable to rendering in speech, or on other media. Along with HTML and [https://en.wikipedia.org/wiki/JavaScript JavaScript], CSS is a cornerstone technology used by most websites to create visually engaging webpages, user interfaces for web applications, and user interfaces for many mobile applications

=='''CSSOM'''==
CSSOM (CSS object model) defines [https://en.wikipedia.org/wiki/Application_programming_interface APIs] (including generic parsing and serialization rules) for media queries, selectors, and CSS itself.
The core features of the CSSOM are oriented towards providing basic capabilities to author-defined scripts to permit access to and manipulation of style related state information and processes.

=='''Rust'''==

We can organize different languages on a spectrum with control on one end and safety on the other. Languages like C and C++ fall on the end of the side of control, where as on the other side we have languages like Javascript, Ruby, Python, etc. What Rust does is stepping off this line. What it does is not a tradeoff between control and safety, but it provides you both the low level of control found in C and C++, and the high level of safety in JavaScript and Python. The three concepts that distinguish rust from other programming languages are: Ownership, Borrowing and lifetime. Ownership is how Rust achieves its largest goal, memory safety. <ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>

=='''Servo'''==

Servo is a project in [https://en.wikipedia.org/wiki/Mozilla Mozilla] research to write a parallel layout engine in Rust. It aims to achieve better parallelism, security, modularity and performance. Servo is built with Cargo, the rust package manager. It currently supports 64bit OSX, 64bit Linux, Android, and Gonk(Firefox OS). [https://servo.org]

=='''Project Description'''==

The project initial steps were described as the following:
*compile Servo and ensure that it runs on <code>tests/html/about-mozilla.html</code>
*email the <code>mozilla.dev.servo</code> mailing list introducing your group and your progress
*create the <code>StyleSheet</code> interface. See the documentation for how to go about this. Comment out any method in the WebIDL that cannot be trivially implemented according to the specification.
*create the <code>StyleSheetList</code> interface. Leave <code>[ArrayClass]</code> commented out, since it is not yet supported by Servo. Store a <code>JS<Document></code> member to allow accessing a document's stylesheets.
*add the <code>styleSheets</code> attribute from the Document extension to <code>Document.webidl</code>, and make it return a new instance of <code>StyleSheetList</code> referencing the current document.
*run <code>./mach test-wpt</code> <code>/tests/wpt/html/dom/interfaces.html</code> and update the test result expectations according to the documentation
*update <code>tests/wpt/mozilla/tests/mozilla/interfaces.html</code> to add the new interface names and allow the test to pass

The Subsequent steps are:
*to make the <code>stylesheets</code> member of <code>Document</code> store the associated <code>Element</code> along with the actual <code>Stylesheet</code>. Add a member to <code>StyleSheet</code> for the associated element, and implement the <code>ownerNode</code> attribute of <code>StyleSheet</code> using this.
*create the CSSStyleSheet interface, containing an <code>Arc<Stylesheet></code> member. Add a method to <code>Document</code> that returns a new <code>CSSStyleSheet</code> instance for a particular index in the <code>stylesheets</code> member.
*create the CSSRule interface.
*create the CSSRuleList interface and implement <code>CSSStyleSheet.cssRules</code>.
*implement the <code>insertRule</code> and <code>deleteRule</code> methods of <code>CSSStyleSheet</code> by making the <code>rules</code> member of the <code>Stylesheet</code> type contain a RefCell, and using this to mutate the contents of the vector.
*create the CSSStyleRule interface and make <code>cssRules</code> return <code>CSSStyleRule</code> values for appropriate rules.

=='''Implementation'''==
==='''Initial Steps'''===
The following steps were followed to meet the project requirements as per this github page.
===='''Step 1'''====
We had to implement the StyleSheet interface for which we had to create two file: stylesheet.rs and StyleSheet.webidl and included stylesheet interface in the mod.rs file.
In the StyleSheet interface we avoided the three methods: ownerNode, parentStyleSheet and media as they could not be trivially implemented and the instructions were clear to avoid such methods.

===='''Step 2'''====
We had to implement StyleSheetList interface for which we had to create two file: stylesheetlist.rs and StyleSheetList.webidl and included stylesheetlist interface in the mod.rs file.
We used JS<Document> instead of [ArrayClass] as [ArrayClass] is not yet supported by Servo.
In the StyleSheetList interface we did not implement the getter as we do not have a list of stylesheets/scripts/dom.

===='''Step 3'''====
We had to implement a partial interface Document with an attribute as styleSheets. The declaration of the interface was done in Document.webidl and its implementation was done in document.rs file. The implementation returned a new instance of StyleSheetList referencing the current document.

==='''Subsequent Steps'''===

===='''Step 1'''====

We will be making changes in the <code>Document.rs</code> file to make the <code>stylesheets</code> member store the associated <code>Element</code>. We're also going to implement the following:

===='''Step 2'''====

We will also implement the <code>.webidl</code> and <code>.rs</code> files for the following:

*CSSStyleSheet interface
*CSSRule interface
*CSSRuleList interface
*CSSStyleRule interface

=='''Testing'''==
Following are the steps to run all the tests:
1. Install the pre-requisites required for servo as mentioned here
2. Run the following commands
cd
git clone https://github.com/mohammed-alfatih/servo.git
cd servo
./mach build --release
'''Note''': It may take around 30 mins to build
./mach test-wpt /tests/wpt/html/dom/interfaces.html
You will see that all tests pass as expected.

'''Note''': There were no predefined test cases mentioned for our project. So now you will see 0 testcases. As far as we know there is no way to test this from UI.

=='''Conclusion'''==
We added the two new interfaces in tests/wpt/mozilla/tests/mozilla/interfaces.html.

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

CSC/ECE 517 Spring 2016/Implement Common Parts of the CSSOM API

2016-04-08T20:41:00Z

Pkulkar5:

=='''Introduction'''==

Cascading Style Sheets ([https://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS]) is a style sheet language used for describing the presentation of a document written in a markup language. Although most often used to set the visual style of web pages and user interfaces written in [https://en.wikipedia.org/wiki/HTML HTML] and [https://en.wikipedia.org/wiki/XHTML XHTML], the language can be applied to any [https://en.wikipedia.org/wiki/XML XML] document, including plain XML, [https://en.wikipedia.org/wiki/Scalable_Vector_Graphics SVG] and [https://en.wikipedia.org/wiki/XUL XUL], and is applicable to rendering in speech, or on other media. Along with HTML and [https://en.wikipedia.org/wiki/JavaScript JavaScript], CSS is a cornerstone technology used by most websites to create visually engaging webpages, user interfaces for web applications, and user interfaces for many mobile applications

=='''CSSOM'''==
CSSOM (CSS object model) defines [https://en.wikipedia.org/wiki/Application_programming_interface APIs] (including generic parsing and serialization rules) for media queries, selectors, and CSS itself.
The core features of the CSSOM are oriented towards providing basic capabilities to author-defined scripts to permit access to and manipulation of style related state information and processes.

=='''Rust'''==

We can organize different languages on a spectrum with control on one end and safety on the other. Languages like C and C++ fall on the end of the side of control, where as on the other side we have languages like Javascript, Ruby, Python, etc. What Rust does is stepping off this line. What it does is not a tradeoff between control and safety, but it provides you both the low level of control found in C and C++, and the high level of safety in JavaScript and Python. The three concepts that distinguish rust from other programming languages are: Ownership, Borrowing and lifetime. Ownership is how Rust achieves its largest goal, memory safety. <ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>

=='''Servo'''==

Servo is a project in [https://en.wikipedia.org/wiki/Mozilla Mozilla] research to write a parallel layout engine in Rust. It aims to achieve better parallelism, security, modularity and performance. Servo is built with Cargo, the rust package manager. It currently supports 64bit OSX, 64bit Linux, Android, and Gonk(Firefox OS).

=='''Project Description'''==

The project initial steps were described as the following:
*compile Servo and ensure that it runs on <code>tests/html/about-mozilla.html</code>
*email the <code>mozilla.dev.servo</code> mailing list introducing your group and your progress
*create the <code>StyleSheet</code> interface. See the documentation for how to go about this. Comment out any method in the WebIDL that cannot be trivially implemented according to the specification.
*create the <code>StyleSheetList</code> interface. Leave <code>[ArrayClass]</code> commented out, since it is not yet supported by Servo. Store a <code>JS<Document></code> member to allow accessing a document's stylesheets.
*add the <code>styleSheets</code> attribute from the Document extension to <code>Document.webidl</code>, and make it return a new instance of <code>StyleSheetList</code> referencing the current document.
*run <code>./mach test-wpt</code> <code>/tests/wpt/html/dom/interfaces.html</code> and update the test result expectations according to the documentation
*update <code>tests/wpt/mozilla/tests/mozilla/interfaces.html</code> to add the new interface names and allow the test to pass

The Subsequent steps are:
*to make the <code>stylesheets</code> member of <code>Document</code> store the associated <code>Element</code> along with the actual <code>Stylesheet</code>. Add a member to <code>StyleSheet</code> for the associated element, and implement the <code>ownerNode</code> attribute of <code>StyleSheet</code> using this.
*create the CSSStyleSheet interface, containing an <code>Arc<Stylesheet></code> member. Add a method to <code>Document</code> that returns a new <code>CSSStyleSheet</code> instance for a particular index in the <code>stylesheets</code> member.
*create the CSSRule interface.
*create the CSSRuleList interface and implement <code>CSSStyleSheet.cssRules</code>.
*implement the <code>insertRule</code> and <code>deleteRule</code> methods of <code>CSSStyleSheet</code> by making the <code>rules</code> member of the <code>Stylesheet</code> type contain a RefCell, and using this to mutate the contents of the vector.
*create the CSSStyleRule interface and make <code>cssRules</code> return <code>CSSStyleRule</code> values for appropriate rules.

=='''Implementation'''==
==='''Initial Steps'''===
The following steps were followed to meet the project requirements as per this github page.
===='''Step 1'''====
We had to implement the StyleSheet interface for which we had to create two file: stylesheet.rs and StyleSheet.webidl and included stylesheet interface in the mod.rs file.
In the StyleSheet interface we avoided the three methods: ownerNode, parentStyleSheet and media as they could not be trivially implemented and the instructions were clear to avoid such methods.

===='''Step 2'''====
We had to implement StyleSheetList interface for which we had to create two file: stylesheetlist.rs and StyleSheetList.webidl and included stylesheetlist interface in the mod.rs file.
We used JS<Document> instead of [ArrayClass] as [ArrayClass] is not yet supported by Servo.
In the StyleSheetList interface we did not implement the getter as we do not have a list of stylesheets/scripts/dom.

===='''Step 3'''====
We had to implement a partial interface Document with an attribute as styleSheets. The declaration of the interface was done in Document.webidl and its implementation was done in document.rs file. The implementation returned a new instance of StyleSheetList referencing the current document.

==='''Subsequent Steps'''===

===='''Step 1'''====

We will be making changes in the <code>Document.rs</code> file to make the <code>stylesheets</code> member store the associated <code>Element</code>. We're also going to implement the following:

===='''Step 2'''====

We will also implement the <code>.webidl</code> and <code>.rs</code> files for the following:

*CSSStyleSheet interface
*CSSRule interface
*CSSRuleList interface
*CSSStyleRule interface

=='''Testing'''==
Following are the steps to run all the tests:
1. Install the pre-requisites required for servo as mentioned here
2. Run the following commands
cd
git clone https://github.com/mohammed-alfatih/servo.git
cd servo
./mach build --release
'''Note''': It may take around 30 mins to build
./mach test-wpt /tests/wpt/html/dom/interfaces.html
You will see that all tests pass as expected.

'''Note''': There were no predefined test cases mentioned for our project. So now you will see 0 testcases. As far as we know there is no way to test this from UI.

=='''Conclusion'''==
We added the two new interfaces in tests/wpt/mozilla/tests/mozilla/interfaces.html.

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

CSC/ECE 517 Spring 2016/Implement Common Parts of the CSSOM API

2016-04-08T20:34:10Z

Pkulkar5: /* Rust */

=='''Introduction'''==

Cascading Style Sheets ([https://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS]) is a style sheet language used for describing the presentation of a document written in a markup language. Although most often used to set the visual style of web pages and user interfaces written in [https://en.wikipedia.org/wiki/HTML HTML] and [https://en.wikipedia.org/wiki/XHTML XHTML], the language can be applied to any [https://en.wikipedia.org/wiki/XML XML] document, including plain XML, [https://en.wikipedia.org/wiki/Scalable_Vector_Graphics SVG] and [https://en.wikipedia.org/wiki/XUL XUL], and is applicable to rendering in speech, or on other media. Along with HTML and [https://en.wikipedia.org/wiki/JavaScript JavaScript], CSS is a cornerstone technology used by most websites to create visually engaging webpages, user interfaces for web applications, and user interfaces for many mobile applications

=='''CSSOM'''==
CSSOM (CSS object model) defines [https://en.wikipedia.org/wiki/Application_programming_interface APIs] (including generic parsing and serialization rules) for media queries, selectors, and CSS itself.
The core features of the CSSOM are oriented towards providing basic capabilities to author-defined scripts to permit access to and manipulation of style related state information and processes.

=='''Rust'''==

We can organize different languages on a spectrum with control on one end and safety on the other. Languages like C and C++ fall on the end of the side of control, where as on the other side we have languages like Javascript, Ruby, Python, etc. What Rust does is stepping off this line. What it does is not a tradeoff between control and safety, but it provides you both the low level of control found in C and C++, and the high level of safety in JavaScript and Python. The three concepts that distinguish rust from other programming languages are: Ownership, Borrowing and lifetime. Ownership is how Rust achieves its largest goal, memory safety. [https://en.wikipedia.org/wiki/Rust_(programming_language)]

=='''Servo'''==

Servo is a project in [https://en.wikipedia.org/wiki/Mozilla Mozilla] research to write a parallel layout engine in Rust. It aims to achieve better parallelism, security, modularity and performance. Servo is built with Cargo, the rust package manager. It currently supports 64bit OSX, 64bit Linux, Android, and Gonk(Firefox OS).

=='''Project Description'''==

The project initial steps were described as the following:
*compile Servo and ensure that it runs on <code>tests/html/about-mozilla.html</code>
*email the <code>mozilla.dev.servo</code> mailing list introducing your group and your progress
*create the <code>StyleSheet</code> interface. See the documentation for how to go about this. Comment out any method in the WebIDL that cannot be trivially implemented according to the specification.
*create the <code>StyleSheetList</code> interface. Leave <code>[ArrayClass]</code> commented out, since it is not yet supported by Servo. Store a <code>JS<Document></code> member to allow accessing a document's stylesheets.
*add the <code>styleSheets</code> attribute from the Document extension to <code>Document.webidl</code>, and make it return a new instance of <code>StyleSheetList</code> referencing the current document.
*run <code>./mach test-wpt</code> <code>/tests/wpt/html/dom/interfaces.html</code> and update the test result expectations according to the documentation
*update <code>tests/wpt/mozilla/tests/mozilla/interfaces.html</code> to add the new interface names and allow the test to pass

The Subsequent steps are:
*to make the <code>stylesheets</code> member of <code>Document</code> store the associated <code>Element</code> along with the actual <code>Stylesheet</code>. Add a member to <code>StyleSheet</code> for the associated element, and implement the <code>ownerNode</code> attribute of <code>StyleSheet</code> using this.
*create the CSSStyleSheet interface, containing an <code>Arc<Stylesheet></code> member. Add a method to <code>Document</code> that returns a new <code>CSSStyleSheet</code> instance for a particular index in the <code>stylesheets</code> member.
*create the CSSRule interface.
*create the CSSRuleList interface and implement <code>CSSStyleSheet.cssRules</code>.
*implement the <code>insertRule</code> and <code>deleteRule</code> methods of <code>CSSStyleSheet</code> by making the <code>rules</code> member of the <code>Stylesheet</code> type contain a RefCell, and using this to mutate the contents of the vector.
*create the CSSStyleRule interface and make <code>cssRules</code> return <code>CSSStyleRule</code> values for appropriate rules.

=='''Implementation'''==
==='''Initial Steps'''===
The following steps were followed to meet the project requirements as per this github page.
===='''Step 1'''====
We had to implement the StyleSheet interface for which we had to create two file: stylesheet.rs and StyleSheet.webidl and included stylesheet interface in the mod.rs file.
In the StyleSheet interface we avoided the three methods: ownerNode, parentStyleSheet and media as they could not be trivially implemented and the instructions were clear to avoid such methods.

===='''Step 2'''====
We had to implement StyleSheetList interface for which we had to create two file: stylesheetlist.rs and StyleSheetList.webidl and included stylesheetlist interface in the mod.rs file.
We used JS<Document> instead of [ArrayClass] as [ArrayClass] is not yet supported by Servo.
In the StyleSheetList interface we did not implement the getter as we do not have a list of stylesheets/scripts/dom.

===='''Step 3'''====
We had to implement a partial interface Document with an attribute as styleSheets. The declaration of the interface was done in Document.webidl and its implementation was done in document.rs file. The implementation returned a new instance of StyleSheetList referencing the current document.

==='''Subsequent Steps'''===

===='''Step 1'''====

We will be making changes in the <code>Document.rs</code> file to make the <code>stylesheets</code> member store the associated <code>Element</code>. We're also going to implement the following:

===='''Step 2'''====

We will also implement the <code>.webidl</code> and <code>.rs</code> files for the following:

*CSSStyleSheet interface
*CSSRule interface
*CSSRuleList interface
*CSSStyleRule interface

=='''Testing'''==
Following are the steps to run all the tests:
1. Install the pre-requisites required for servo as mentioned here
2. Run the following commands
cd
git clone https://github.com/mohammed-alfatih/servo.git
cd servo
./mach build --release
'''Note''': It may take around 30 mins to build
./mach test-wpt /tests/wpt/html/dom/interfaces.html
You will see that all tests pass as expected.

'''Note''': There were no predefined test cases mentioned for our project. So now you will see 0 testcases. As far as we know there is no way to test this from UI.

=='''Conclusion'''==
We added the two new interfaces in tests/wpt/mozilla/tests/mozilla/interfaces.html.

CSC/ECE 517 Spring 2016/Implement Common Parts of the CSSOM API

2016-04-08T20:31:59Z

Pkulkar5: /* Rust */

=='''Introduction'''==

Cascading Style Sheets ([https://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS]) is a style sheet language used for describing the presentation of a document written in a markup language. Although most often used to set the visual style of web pages and user interfaces written in [https://en.wikipedia.org/wiki/HTML HTML] and [https://en.wikipedia.org/wiki/XHTML XHTML], the language can be applied to any [https://en.wikipedia.org/wiki/XML XML] document, including plain XML, [https://en.wikipedia.org/wiki/Scalable_Vector_Graphics SVG] and [https://en.wikipedia.org/wiki/XUL XUL], and is applicable to rendering in speech, or on other media. Along with HTML and [https://en.wikipedia.org/wiki/JavaScript JavaScript], CSS is a cornerstone technology used by most websites to create visually engaging webpages, user interfaces for web applications, and user interfaces for many mobile applications

=='''CSSOM'''==
CSSOM (CSS object model) defines [https://en.wikipedia.org/wiki/Application_programming_interface APIs] (including generic parsing and serialization rules) for media queries, selectors, and CSS itself.
The core features of the CSSOM are oriented towards providing basic capabilities to author-defined scripts to permit access to and manipulation of style related state information and processes.

=='''Rust'''==

We can organize different languages on a spectrum with control on one end and safety on the other. Languages like C and C++ fall on the end of the side of control, where as on the other side we have languages like Javascript, Ruby, Python, etc. What Rust does is stepping off this line. What it does is not a tradeoff between control and safety, but it provides you both the low level of control found in C and C++, and the high level of safety in JavaScript and Python. The three concepts that distinguish rust from other programming languages are: Ownership, Borrowing and lifetime. Ownership is how Rust achieves its largest goal, memory safety. <ref name="Rust programming language">https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>

=='''Servo'''==

Servo is a project in [https://en.wikipedia.org/wiki/Mozilla Mozilla] research to write a parallel layout engine in Rust. It aims to achieve better parallelism, security, modularity and performance. Servo is built with Cargo, the rust package manager. It currently supports 64bit OSX, 64bit Linux, Android, and Gonk(Firefox OS).

=='''Project Description'''==

The project initial steps were described as the following:
*compile Servo and ensure that it runs on <code>tests/html/about-mozilla.html</code>
*email the <code>mozilla.dev.servo</code> mailing list introducing your group and your progress
*create the <code>StyleSheet</code> interface. See the documentation for how to go about this. Comment out any method in the WebIDL that cannot be trivially implemented according to the specification.
*create the <code>StyleSheetList</code> interface. Leave <code>[ArrayClass]</code> commented out, since it is not yet supported by Servo. Store a <code>JS<Document></code> member to allow accessing a document's stylesheets.
*add the <code>styleSheets</code> attribute from the Document extension to <code>Document.webidl</code>, and make it return a new instance of <code>StyleSheetList</code> referencing the current document.
*run <code>./mach test-wpt</code> <code>/tests/wpt/html/dom/interfaces.html</code> and update the test result expectations according to the documentation
*update <code>tests/wpt/mozilla/tests/mozilla/interfaces.html</code> to add the new interface names and allow the test to pass

The Subsequent steps are:
*to make the <code>stylesheets</code> member of <code>Document</code> store the associated <code>Element</code> along with the actual <code>Stylesheet</code>. Add a member to <code>StyleSheet</code> for the associated element, and implement the <code>ownerNode</code> attribute of <code>StyleSheet</code> using this.
*create the CSSStyleSheet interface, containing an <code>Arc<Stylesheet></code> member. Add a method to <code>Document</code> that returns a new <code>CSSStyleSheet</code> instance for a particular index in the <code>stylesheets</code> member.
*create the CSSRule interface.
*create the CSSRuleList interface and implement <code>CSSStyleSheet.cssRules</code>.
*implement the <code>insertRule</code> and <code>deleteRule</code> methods of <code>CSSStyleSheet</code> by making the <code>rules</code> member of the <code>Stylesheet</code> type contain a RefCell, and using this to mutate the contents of the vector.
*create the CSSStyleRule interface and make <code>cssRules</code> return <code>CSSStyleRule</code> values for appropriate rules.

=='''Implementation'''==
==='''Initial Steps'''===
The following steps were followed to meet the project requirements as per this github page.
===='''Step 1'''====
We had to implement the StyleSheet interface for which we had to create two file: stylesheet.rs and StyleSheet.webidl and included stylesheet interface in the mod.rs file.
In the StyleSheet interface we avoided the three methods: ownerNode, parentStyleSheet and media as they could not be trivially implemented and the instructions were clear to avoid such methods.

===='''Step 2'''====
We had to implement StyleSheetList interface for which we had to create two file: stylesheetlist.rs and StyleSheetList.webidl and included stylesheetlist interface in the mod.rs file.
We used JS<Document> instead of [ArrayClass] as [ArrayClass] is not yet supported by Servo.
In the StyleSheetList interface we did not implement the getter as we do not have a list of stylesheets/scripts/dom.

===='''Step 3'''====
We had to implement a partial interface Document with an attribute as styleSheets. The declaration of the interface was done in Document.webidl and its implementation was done in document.rs file. The implementation returned a new instance of StyleSheetList referencing the current document.

==='''Subsequent Steps'''===

===='''Step 1'''====

We will be making changes in the <code>Document.rs</code> file to make the <code>stylesheets</code> member store the associated <code>Element</code>. We're also going to implement the following:

===='''Step 2'''====

We will also implement the <code>.webidl</code> and <code>.rs</code> files for the following:

*CSSStyleSheet interface
*CSSRule interface
*CSSRuleList interface
*CSSStyleRule interface

=='''Testing'''==
Following are the steps to run all the tests:
1. Install the pre-requisites required for servo as mentioned here
2. Run the following commands
cd
git clone https://github.com/mohammed-alfatih/servo.git
cd servo
./mach build --release
'''Note''': It may take around 30 mins to build
./mach test-wpt /tests/wpt/html/dom/interfaces.html
You will see that all tests pass as expected.

'''Note''': There were no predefined test cases mentioned for our project. So now you will see 0 testcases. As far as we know there is no way to test this from UI.

=='''Conclusion'''==
We added the two new interfaces in tests/wpt/mozilla/tests/mozilla/interfaces.html.

CSC/ECE 517 Spring 2016/Implement Common Parts of the CSSOM API

2016-04-08T20:23:00Z

Pkulkar5: /* Subsequent Steps */

=='''Introduction'''==

Cascading Style Sheets ([https://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS]) is a style sheet language used for describing the presentation of a document written in a markup language. Although most often used to set the visual style of web pages and user interfaces written in [https://en.wikipedia.org/wiki/HTML HTML] and [https://en.wikipedia.org/wiki/XHTML XHTML], the language can be applied to any [https://en.wikipedia.org/wiki/XML XML] document, including plain XML, [https://en.wikipedia.org/wiki/Scalable_Vector_Graphics SVG] and [https://en.wikipedia.org/wiki/XUL XUL], and is applicable to rendering in speech, or on other media. Along with HTML and [https://en.wikipedia.org/wiki/JavaScript JavaScript], CSS is a cornerstone technology used by most websites to create visually engaging webpages, user interfaces for web applications, and user interfaces for many mobile applications

=='''CSSOM'''==
CSSOM (CSS object model) defines [https://en.wikipedia.org/wiki/Application_programming_interface APIs] (including generic parsing and serialization rules) for media queries, selectors, and CSS itself.
The core features of the CSSOM are oriented towards providing basic capabilities to author-defined scripts to permit access to and manipulation of style related state information and processes.

=='''Rust'''==

We can organize different languages on a spectrum with control on one end and safety on the other. Languages like C and C++ fall on the end of the side of control, where as on the other side we have languages like Javascript, Ruby, Python, etc. What Rust does is stepping off this line. What it does is not a tradeoff between control and safety, but it provides you both the low level of control found in C and C++, and the high level of safety in JavaScript and Python. The three concepts that distinguish rust from other programming languages are: Ownership, Borrowing and lifetime. Ownership is how Rust achieves its largest goal, memory safety.

=='''Servo'''==

Servo is a project in [https://en.wikipedia.org/wiki/Mozilla Mozilla] research to write a parallel layout engine in Rust. It aims to achieve better parallelism, security, modularity and performance. Servo is built with Cargo, the rust package manager. It currently supports 64bit OSX, 64bit Linux, Android, and Gonk(Firefox OS).

=='''Project Description'''==

The project initial steps were described as the following:
*compile Servo and ensure that it runs on <code>tests/html/about-mozilla.html</code>
*email the <code>mozilla.dev.servo</code> mailing list introducing your group and your progress
*create the <code>StyleSheet</code> interface. See the documentation for how to go about this. Comment out any method in the WebIDL that cannot be trivially implemented according to the specification.
*create the <code>StyleSheetList</code> interface. Leave <code>[ArrayClass]</code> commented out, since it is not yet supported by Servo. Store a <code>JS<Document></code> member to allow accessing a document's stylesheets.
*add the <code>styleSheets</code> attribute from the Document extension to <code>Document.webidl</code>, and make it return a new instance of <code>StyleSheetList</code> referencing the current document.
*run <code>./mach test-wpt</code> <code>/tests/wpt/html/dom/interfaces.html</code> and update the test result expectations according to the documentation
*update <code>tests/wpt/mozilla/tests/mozilla/interfaces.html</code> to add the new interface names and allow the test to pass

The Subsequent steps are:
*to make the <code>stylesheets</code> member of <code>Document</code> store the associated <code>Element</code> along with the actual <code>Stylesheet</code>. Add a member to <code>StyleSheet</code> for the associated element, and implement the <code>ownerNode</code> attribute of <code>StyleSheet</code> using this.
*create the CSSStyleSheet interface, containing an <code>Arc<Stylesheet></code> member. Add a method to <code>Document</code> that returns a new <code>CSSStyleSheet</code> instance for a particular index in the <code>stylesheets</code> member.
*create the CSSRule interface.
*create the CSSRuleList interface and implement <code>CSSStyleSheet.cssRules</code>.
*implement the <code>insertRule</code> and <code>deleteRule</code> methods of <code>CSSStyleSheet</code> by making the <code>rules</code> member of the <code>Stylesheet</code> type contain a RefCell, and using this to mutate the contents of the vector.
*create the CSSStyleRule interface and make <code>cssRules</code> return <code>CSSStyleRule</code> values for appropriate rules.

=='''Implementation'''==
==='''Initial Steps'''===
The following steps were followed to meet the project requirements as per this github page.
===='''Step 1'''====
We had to implement the StyleSheet interface for which we had to create two file: stylesheet.rs and StyleSheet.webidl and included stylesheet interface in the mod.rs file.
In the StyleSheet interface we avoided the three methods: ownerNode, parentStyleSheet and media as they could not be trivially implemented and the instructions were clear to avoid such methods.

===='''Step 2'''====
We had to implement StyleSheetList interface for which we had to create two file: stylesheetlist.rs and StyleSheetList.webidl and included stylesheetlist interface in the mod.rs file.
We used JS<Document> instead of [ArrayClass] as [ArrayClass] is not yet supported by Servo.
In the StyleSheetList interface we did not implement the getter as we do not have a list of stylesheets/scripts/dom.

===='''Step 3'''====
We had to implement a partial interface Document with an attribute as styleSheets. The declaration of the interface was done in Document.webidl and its implementation was done in document.rs file. The implementation returned a new instance of StyleSheetList referencing the current document.

==='''Subsequent Steps'''===

===='''Step 1'''====

We will be making changes in the <code>Document.rs</code> file to make the <code>stylesheets</code> member store the associated <code>Element</code>. We're also going to implement the following:

===='''Step 2'''====

We will also implement the <code>.webidl</code> and <code>.rs</code> files for the following:

*CSSStyleSheet interface
*CSSRule interface
*CSSRuleList interface
*CSSStyleRule interface

=='''Testing'''==
Following are the steps to run all the tests:
1. Install the pre-requisites required for servo as mentioned here
2. Run the following commands
cd
git clone https://github.com/mohammed-alfatih/servo.git
cd servo
./mach build --release
'''Note''': It may take around 30 mins to build
./mach test-wpt /tests/wpt/html/dom/interfaces.html
You will see that all tests pass as expected.

'''Note''': There were no predefined test cases mentioned for our project. So now you will see 0 testcases. As far as we know there is no way to test this from UI.

=='''Conclusion'''==
We added the two new interfaces in tests/wpt/mozilla/tests/mozilla/interfaces.html.

CSC/ECE 517 Spring 2016/Implement Common Parts of the CSSOM API

2016-04-08T20:20:31Z

Pkulkar5: /* Rust */

=='''Introduction'''==

Cascading Style Sheets ([https://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS]) is a style sheet language used for describing the presentation of a document written in a markup language. Although most often used to set the visual style of web pages and user interfaces written in [https://en.wikipedia.org/wiki/HTML HTML] and [https://en.wikipedia.org/wiki/XHTML XHTML], the language can be applied to any [https://en.wikipedia.org/wiki/XML XML] document, including plain XML, [https://en.wikipedia.org/wiki/Scalable_Vector_Graphics SVG] and [https://en.wikipedia.org/wiki/XUL XUL], and is applicable to rendering in speech, or on other media. Along with HTML and [https://en.wikipedia.org/wiki/JavaScript JavaScript], CSS is a cornerstone technology used by most websites to create visually engaging webpages, user interfaces for web applications, and user interfaces for many mobile applications

=='''CSSOM'''==
CSSOM (CSS object model) defines [https://en.wikipedia.org/wiki/Application_programming_interface APIs] (including generic parsing and serialization rules) for media queries, selectors, and CSS itself.
The core features of the CSSOM are oriented towards providing basic capabilities to author-defined scripts to permit access to and manipulation of style related state information and processes.

=='''Rust'''==

We can organize different languages on a spectrum with control on one end and safety on the other. Languages like C and C++ fall on the end of the side of control, where as on the other side we have languages like Javascript, Ruby, Python, etc. What Rust does is stepping off this line. What it does is not a tradeoff between control and safety, but it provides you both the low level of control found in C and C++, and the high level of safety in JavaScript and Python. The three concepts that distinguish rust from other programming languages are: Ownership, Borrowing and lifetime. Ownership is how Rust achieves its largest goal, memory safety.

=='''Servo'''==

Servo is a project in [https://en.wikipedia.org/wiki/Mozilla Mozilla] research to write a parallel layout engine in Rust. It aims to achieve better parallelism, security, modularity and performance. Servo is built with Cargo, the rust package manager. It currently supports 64bit OSX, 64bit Linux, Android, and Gonk(Firefox OS).

=='''Project Description'''==

The project initial steps were described as the following:
*compile Servo and ensure that it runs on <code>tests/html/about-mozilla.html</code>
*email the <code>mozilla.dev.servo</code> mailing list introducing your group and your progress
*create the <code>StyleSheet</code> interface. See the documentation for how to go about this. Comment out any method in the WebIDL that cannot be trivially implemented according to the specification.
*create the <code>StyleSheetList</code> interface. Leave <code>[ArrayClass]</code> commented out, since it is not yet supported by Servo. Store a <code>JS<Document></code> member to allow accessing a document's stylesheets.
*add the <code>styleSheets</code> attribute from the Document extension to <code>Document.webidl</code>, and make it return a new instance of <code>StyleSheetList</code> referencing the current document.
*run <code>./mach test-wpt</code> <code>/tests/wpt/html/dom/interfaces.html</code> and update the test result expectations according to the documentation
*update <code>tests/wpt/mozilla/tests/mozilla/interfaces.html</code> to add the new interface names and allow the test to pass

The Subsequent steps are:
*to make the <code>stylesheets</code> member of <code>Document</code> store the associated <code>Element</code> along with the actual <code>Stylesheet</code>. Add a member to <code>StyleSheet</code> for the associated element, and implement the <code>ownerNode</code> attribute of <code>StyleSheet</code> using this.
*create the CSSStyleSheet interface, containing an <code>Arc<Stylesheet></code> member. Add a method to <code>Document</code> that returns a new <code>CSSStyleSheet</code> instance for a particular index in the <code>stylesheets</code> member.
*create the CSSRule interface.
*create the CSSRuleList interface and implement <code>CSSStyleSheet.cssRules</code>.
*implement the <code>insertRule</code> and <code>deleteRule</code> methods of <code>CSSStyleSheet</code> by making the <code>rules</code> member of the <code>Stylesheet</code> type contain a RefCell, and using this to mutate the contents of the vector.
*create the CSSStyleRule interface and make <code>cssRules</code> return <code>CSSStyleRule</code> values for appropriate rules.

=='''Implementation'''==
==='''Initial Steps'''===
The following steps were followed to meet the project requirements as per this github page.
===='''Step 1'''====
We had to implement the StyleSheet interface for which we had to create two file: stylesheet.rs and StyleSheet.webidl and included stylesheet interface in the mod.rs file.
In the StyleSheet interface we avoided the three methods: ownerNode, parentStyleSheet and media as they could not be trivially implemented and the instructions were clear to avoid such methods.

===='''Step 2'''====
We had to implement StyleSheetList interface for which we had to create two file: stylesheetlist.rs and StyleSheetList.webidl and included stylesheetlist interface in the mod.rs file.
We used JS<Document> instead of [ArrayClass] as [ArrayClass] is not yet supported by Servo.
In the StyleSheetList interface we did not implement the getter as we do not have a list of stylesheets/scripts/dom.

===='''Step 3'''====
We had to implement a partial interface Document with an attribute as styleSheets. The declaration of the interface was done in Document.webidl and its implementation was done in document.rs file. The implementation returned a new instance of StyleSheetList referencing the current document.

==='''Subsequent Steps'''===

===='''Step 1'''====

We will be making changes in the <code>Documet.rs</code> file to make the <code>stylesheets</code> member store the associated <code>Element</code>. We're also going to implement the following:

===='''Step 2'''====

We will also implement the <code>.webidl</code> and <code>.rs</code> files for the following:

*CSSStyleSheet interface
*CSSRule interface
*CSSRuleList interface
*CSSStyleRule interface

=='''Testing'''==
Following are the steps to run all the tests:
1. Install the pre-requisites required for servo as mentioned here
2. Run the following commands
cd
git clone https://github.com/mohammed-alfatih/servo.git
cd servo
./mach build --release
'''Note''': It may take around 30 mins to build
./mach test-wpt /tests/wpt/html/dom/interfaces.html
You will see that all tests pass as expected.

'''Note''': There were no predefined test cases mentioned for our project. So now you will see 0 testcases. As far as we know there is no way to test this from UI.

=='''Conclusion'''==
We added the two new interfaces in tests/wpt/mozilla/tests/mozilla/interfaces.html.

CSC/ECE 517 Spring 2016/Implement Common Parts of the CSSOM API

2016-04-08T20:19:22Z

Pkulkar5: /* Servo */

=='''Introduction'''==

Cascading Style Sheets ([https://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS]) is a style sheet language used for describing the presentation of a document written in a markup language. Although most often used to set the visual style of web pages and user interfaces written in [https://en.wikipedia.org/wiki/HTML HTML] and [https://en.wikipedia.org/wiki/XHTML XHTML], the language can be applied to any [https://en.wikipedia.org/wiki/XML XML] document, including plain XML, [https://en.wikipedia.org/wiki/Scalable_Vector_Graphics SVG] and [https://en.wikipedia.org/wiki/XUL XUL], and is applicable to rendering in speech, or on other media. Along with HTML and [https://en.wikipedia.org/wiki/JavaScript JavaScript], CSS is a cornerstone technology used by most websites to create visually engaging webpages, user interfaces for web applications, and user interfaces for many mobile applications

=='''CSSOM'''==
CSSOM (CSS object model) defines [https://en.wikipedia.org/wiki/Application_programming_interface APIs] (including generic parsing and serialization rules) for media queries, selectors, and CSS itself.
The core features of the CSSOM are oriented towards providing basic capabilities to author-defined scripts to permit access to and manipulation of style related state information and processes.

=='''Rust'''==

We can organize different languages on a spectrum with control on one end and safety on the other. Languages like C and C++ fall on the end of the side of control, where as on the other side we have languages like Javascript, Ruby, Python, etc. What Rust does is stepping off this line. What it does is not a tradeoff between control and safety, but it provides you both the low level of control found in C and C++, and the high level of safety in JavaScript and Python. The three concepts that distinguish rust from other programming languages are: Ownership, Borrowing and lifetime. Ownership is how Rust achieves its largest goal, memory safety.

=='''Rust'''==

We can organize different languages on a spectrum with control on one end and safety on the other. Languages like C and C++ fall on the end of the side of control, where as on the other side we have languages like Javascript, Ruby, Python, etc.
What Rust does is stepping off this line. What it does is not a tradeoff between control and safety, but it provides you both the low level of control found in C and C++, and the high level of safety in JavaScript and Python.
The three concepts that distinguish rust from other programming languages are: Ownership, Borrowing and lifetime. Ownership is how Rust achieves its largest goal, memory safety.

=='''Project Description'''==

The project initial steps were described as the following:
*compile Servo and ensure that it runs on <code>tests/html/about-mozilla.html</code>
*email the <code>mozilla.dev.servo</code> mailing list introducing your group and your progress
*create the <code>StyleSheet</code> interface. See the documentation for how to go about this. Comment out any method in the WebIDL that cannot be trivially implemented according to the specification.
*create the <code>StyleSheetList</code> interface. Leave <code>[ArrayClass]</code> commented out, since it is not yet supported by Servo. Store a <code>JS<Document></code> member to allow accessing a document's stylesheets.
*add the <code>styleSheets</code> attribute from the Document extension to <code>Document.webidl</code>, and make it return a new instance of <code>StyleSheetList</code> referencing the current document.
*run <code>./mach test-wpt</code> <code>/tests/wpt/html/dom/interfaces.html</code> and update the test result expectations according to the documentation
*update <code>tests/wpt/mozilla/tests/mozilla/interfaces.html</code> to add the new interface names and allow the test to pass

The Subsequent steps are:
*to make the <code>stylesheets</code> member of <code>Document</code> store the associated <code>Element</code> along with the actual <code>Stylesheet</code>. Add a member to <code>StyleSheet</code> for the associated element, and implement the <code>ownerNode</code> attribute of <code>StyleSheet</code> using this.
*create the CSSStyleSheet interface, containing an <code>Arc<Stylesheet></code> member. Add a method to <code>Document</code> that returns a new <code>CSSStyleSheet</code> instance for a particular index in the <code>stylesheets</code> member.
*create the CSSRule interface.
*create the CSSRuleList interface and implement <code>CSSStyleSheet.cssRules</code>.
*implement the <code>insertRule</code> and <code>deleteRule</code> methods of <code>CSSStyleSheet</code> by making the <code>rules</code> member of the <code>Stylesheet</code> type contain a RefCell, and using this to mutate the contents of the vector.
*create the CSSStyleRule interface and make <code>cssRules</code> return <code>CSSStyleRule</code> values for appropriate rules.

=='''Implementation'''==
==='''Initial Steps'''===
The following steps were followed to meet the project requirements as per this github page.
===='''Step 1'''====
We had to implement the StyleSheet interface for which we had to create two file: stylesheet.rs and StyleSheet.webidl and included stylesheet interface in the mod.rs file.
In the StyleSheet interface we avoided the three methods: ownerNode, parentStyleSheet and media as they could not be trivially implemented and the instructions were clear to avoid such methods.

===='''Step 2'''====
We had to implement StyleSheetList interface for which we had to create two file: stylesheetlist.rs and StyleSheetList.webidl and included stylesheetlist interface in the mod.rs file.
We used JS<Document> instead of [ArrayClass] as [ArrayClass] is not yet supported by Servo.
In the StyleSheetList interface we did not implement the getter as we do not have a list of stylesheets/scripts/dom.

===='''Step 3'''====
We had to implement a partial interface Document with an attribute as styleSheets. The declaration of the interface was done in Document.webidl and its implementation was done in document.rs file. The implementation returned a new instance of StyleSheetList referencing the current document.

==='''Subsequent Steps'''===

===='''Step 1'''====

We will be making changes in the <code>Documet.rs</code> file to make the <code>stylesheets</code> member store the associated <code>Element</code>. We're also going to implement the following:

===='''Step 2'''====

We will also implement the <code>.webidl</code> and <code>.rs</code> files for the following:

*CSSStyleSheet interface
*CSSRule interface
*CSSRuleList interface
*CSSStyleRule interface

=='''Testing'''==
Following are the steps to run all the tests:
1. Install the pre-requisites required for servo as mentioned here
2. Run the following commands
cd
git clone https://github.com/mohammed-alfatih/servo.git
cd servo
./mach build --release
'''Note''': It may take around 30 mins to build
./mach test-wpt /tests/wpt/html/dom/interfaces.html
You will see that all tests pass as expected.

'''Note''': There were no predefined test cases mentioned for our project. So now you will see 0 testcases. As far as we know there is no way to test this from UI.

=='''Conclusion'''==
We added the two new interfaces in tests/wpt/mozilla/tests/mozilla/interfaces.html.

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-31T22:03:55Z

Pkulkar5:

== E1603. Refactor user, course_participant and assignment_participant model ==
This page provides details about the changes made to Expertiza under project E1603. Refactor user, course_participant and assignment_participant model.

==Background==
Expertiza is an educational web application built on top of Ruby on Rails. The project is open source with code available on Github and maintained by both the students and faculty of the NC State University. The application allows instructors to manage courses and assignments. The students can choose a topic from the list for an assignment, form a team, submit their work and do multiple reviews on other's work. The application helps instructors and teaching assistants in scoring and maintaining the grades for the assignment.

==Description==
The users of the expertiza are modeled using the user model. A participant signs up for courses and assignments. A user can have multiple participants and all participants belong to a user. The participant model is inherited by the course and assignment participant model. Our work involves refactoring functions defined in these models. Some methods were moved to places with better fit and some methods were improvised with better implementations. The further sections in the document will explain the changes complement and how it will impact the overall usage of expertiza.

==Tasks accomplished in this project==
* Moved the export_fields method to the User model from CourseParticipant model to remove redudancy.
* Added attr_accessible modifier to CourseParticipant to improve security.
* Refactored the get_user_list method into smaller methods, one method for each if condition in User model.
* Moved the ‘files’ method from AssignmentParticipant model which was duplicate and used in assignment_team.rb as well to a common place (FileHelper module).
* Refactored the average_question_score method by using sql summation to find values for sum_of_scores and number_of_scores variables in AssignmentParticipant model.

==Models==

===User===
The user model stores details of the user like name,email,role,timezone and his preferences on how expertiza should behave to him. A user can have many roles like student, instructor or administrator. The user model is used for logging in, participating in courses, assignments and creating teams. The user model maintains parent child relationship, a user will have one parent and can have many children.

===Assignment Participant===
Expertiza uses a participant abstraction for modeling the participance of a user in any of the activities like courses and assignments. A participant belongs to a user and it represents a connection between a user and an activity. Assignment_participant, which is a child class of participant models the association between users and assignments. This association also needs to be mapped to other activities performed by a user related to the assignment. These activities include reviews, quiz, response to reviews, teammate reviews etc.. The assignment_participant model is related to models which is responsible for all the mentioned activities.

===Course Participant===
The course_participant is a child class of the participant abstraction and it represents the association between a user and a course. The model also stores fields required for the association and supports bulk importing and exporting.

==Changes==

===Refactoring: Duplicated export_fields method===
This method exports the headers of the csv file to be downloaded. The method export_fields occurs in various models with different implementations. However, the implementation for this method had been duplicated in course_participant and user models. This led to the disadvantage of having redundant code in the system and an inefficient coding practice. User model represents the base class and other models inherit from this class. Hence, deleting the method from User model made little sense. The refactoring invoked the User models export_fields method from within the export_fields of course_participant. Since the export_file controller calls this method on the course_participant object, there wasn't a choice to delete the method completely. This refactoring has the advantage that code is reused and the proper object is tied to the header fields instead of just the generic User object.

===Refactoring: Breaking get_user_list method===
This method contained a lot of if-else statements that executed different codes depending on the type of user. The refactoring broke the large method into smaller methods, one for each user type. This improved the modularity of the code. It made the code more manageable and understandable from maintenance point of view (separation of responsibilities).

===Refactoring: Use SQL summation to calculate average_question_score===
The average of the score for a question in the review given by all other students who reviewed an assignment needs to be calculated in the average_question_score method in assignment participant model. This was originally implemented by using two for loops and fetching all the answers given by all the reviewers and then filtering using an if statement. This method consumes more CPU cycles and impacts the performance of the application server. It also consumes more bandwidth since the application fetches all the data from the database but returns only one value to the user. This was reimplemented to use the SQL summation inside the database and returns the only desired value to the application. This method also takes advantage of the database indexing and fetches only values required instead of filtering in the application.

===Refactoring: Add attr_accessible to class to improve security===
The course_participant model has a number of instance variables like can_submit, can_review, user_id, parent_id, submitted_at, permission_granted, penalty_accumulated, grade, type, handle, time_stamp, digital_signature, duty, can_take_quiz. Earlier, these variables were less secure and hence susceptible to tampering with URLs or forms from malicious users. In general, elements are filled based on the data sent as a hash from the view. This happens as mass assignment where any matching key in the hash will be set. To protect this mass assignment from malicious attacks, a good design is to add attr_accessible macro. Adding this keyword to instance variables ensures that only the specified attributes in the list of attr_accessible are allowed for mass assignment. This ensures that developers can carefully consider which attributes should be allowed to do mass assignment. This way, the refactoring is done.
<code>attr_accessible :can_submit, :can_review, :user_id, :parent_id, :submitted_at, :permission_granted, :penalty_accumulated, :grade, :type, :handle, :time_stamp, :digital_signature, :duty, :can_take_quiz</code>

===Refactoring: files method is duplicate and used in assignment_team.rb as well. Move it to either a common place or keep it at the most appropriate place===
This refactoring belongs to AssignmentParticipant model. This model is a special class of Participant and it denotes the participants who have collaborated for a particular Assignment. This method takes a parameter which is a directory and it returns all the files present in that directory. The directory argument is basically a string containing the file path for reviewer uploaded files during peer review. This argument comes from AssignmentParticipant model but the files method as a whole is independent of the model as its function is to return files present in a directory. It does not need to belong to any model. Hence the ‘files’ method must be placed in file_helper.rb. Thus the ‘files’ method is moved from the AssignmentParticipant model to a helper module like file_helper.rb. The design principle that is reinforced here is that a class must have responsibilities that belong to itself and not other “helper” responsibilities. This is an implementation of Separation Of Concerns design principle.

<code>
def files(directory)
files_list = Dir[directory + "/*"]
files = Array.new
files_list.each do |file|
if File.directory?(file)
dir_files = files(file)
dir_files.each{|f| files << f}
end
files << file
end
files
end
</code>

===Refactoring: topic_name in Participant.rb===
In participant.rb model, there is a method topic_name. However, this method doesn't seem to be required here. A course participant cannot have a topic. If it is an assignment participant object, we can find which team that participant is in first, then find which topic is this team holding. In fact, there is a topic_name field in SignedUpTeam class. On thorough investigation, we found that the method has no caller, which is the right implementation in any case. Hence, the refactoring involved deleting this method altogether. The refactoring was verified by the fact that none of the existing test cases failed.

==Testing==
Expertiza mainly uses RSpec for testing and has a comprehensive set of test cases overall. However, there are some models that do not have the required rspecs. We have included test cases for all the refactoring that we have done. We also ensured that the existing test cases do not fail.

===Test adding attr_accessible to class to improve security===
The earlier version of Expertiza did not have an rspec for the CourseParticipant model. We added an rspec named course_participant_spec.rb as the rspec for this model covering tests for the refactorings done in this project. The attr_accessible improves security by allowing only those fields that are in the list of attr_accessible macro for mass assignment. We test this by using “should allow_mass_assignment_of” and “should_not allow_mass_assignment_of”. Those attributes that are not in the list of attr_accessible will pass the test only when tested as “should_not allow_mass_assignment_of” and the attributes that are in the list of attr_accessible will pass the test only when tested as “should allow_mass_assignment_of”. The following is the code snippet of the test case.
<code>
describe "#accessible attributes" do
it { should allow_mass_assignment_of(:can_submit) }
it { should allow_mass_assignment_of(:can_review) }
it { should allow_mass_assignment_of(:user_id) }
it { should allow_mass_assignment_of(:parent_id) }
it { should allow_mass_assignment_of(:submitted_at) }
it { should allow_mass_assignment_of(:permission_granted) }
it { should allow_mass_assignment_of(:penalty_accumulated) }
it { should allow_mass_assignment_of(:grade) }
it { should allow_mass_assignment_of(:type) }
it { should allow_mass_assignment_of(:handle) }
it { should allow_mass_assignment_of(:time_stamp) }
it { should allow_mass_assignment_of(:digital_signature) }
it { should allow_mass_assignment_of(:duty) }
it { should allow_mass_assignment_of(:can_take_quiz) }
end
</code>

===Test the export_fields method===
This refactoring was done in the CourseParticipant model. The duplication is removed and the export_fields method is kept only in the User model and a call to the User model is made from CourseParticipant. To test this method, we test the functionality of this method as there is no test case for this method in the previous version. The export_fields method takes an argument of options which is a list of all the fields that the end user wants to export as course participant data and it returns the corresponding fields by making a call to User model. The ideal test case will test only the export_fields in the course_participant model and not the one in user model. This is in line with the strategy of testing incoming query messages by making assertions about what they send back. Therefore, for a given set of options, only the required right set of fields are to be returned. We expect that the returned list of fields will match the ones the method asked using the options field. Below is a sample test snippet.
<code>
describe "#export_fields" do
it "returns export fields for a csv based on radio buttons checked" do
options = {"personal_details"=>"true", "role"=>"true", "parent"=>"true", "email_options"=>"true", "handle"=>"true"}
fields = ["name", "full name", "email", "role", "parent", "email on submission", "email on review", "email on metareview", "handle"]
expect(CourseParticipant.export_fields(options)).to match_array(fields)
end
</code>

===Test refactoring of get_user_list method into smaller methods===
In order to test get_user_list, we create a dummy object of User and set its role as instructor and fetch the user list of that instructor which returns the list of participants of that instructor’s course. The list could be empty or non empty depending on the user object.
<code>
describe "#get_user_list" do
it 'user list' do
@role = Role.new name: "Instructor"
user1 = User.new name: "instructor4", role: @role
expect(user1.get_user_list).to be_empty
expect(user1.get_users_instructor)
end
end
</code>

===Test files method in the FileHelper module===
The files method takes an argument of a directory path and returns all the files present in that directory. In the original repository, there was no test case for this method. We have added a test for this method in the file_helper_spec.rb file. The test case takes an example directory like /tmp/expertiza1603/ and returns the files present in that directory. Since the test cases can be run in any environment, the result of the test case is dependent on the presence of such a directory structure. We have created a sample directory with two files on the VCL environment(152.7.99.160). If such a directory is not present, it is important to create a directory by that name.
<code>
describe FileHelper do
class DummyClass
end
before(:each) do
@dummy_class = DummyClass.new
@dummy_class.extend(FileHelper)
end
describe "#files" do
it 'return files present in a dir' do
expected_array = ["/tmp/expertiza1603/1.txt", "/tmp/expertiza1603/2.txt"]
expect(@dummy_class.files("/tmp/expertiza1603")).to match_array(expected_array)
end
end
end
</code>

===Testing through GUI===

====Test export fields method====
*Login as super_administrator2 or administrator5 with password as "password"
*Click on "Manage..."" and click on "Courses"
*On the "Actions" tab, click on "Add Participants"
*On the page that opens up, go to the bottom and select "Export course participants"
*Click on "Export" button and a csv file should download with the selected radio button fields.

====Test get_user_list method====
*Login as super_administrator2 or administrator5 with password as "password"
*Click on "Manage..."" and click on "Users"
*You should see all the users on the page.

==References==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/pranavkulkarni/expertiza GitHub Project Repository Fork]
#[https://github.com/expertiza/expertiza/pull/662 Git Pull Request]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://152.7.99.160:3000 Demo link]
#[https://relishapp.com/rspec Rspec Documentation]
#[https://en.wikipedia.org/wiki/Don%27t_repeat_yourself DRY Principle]

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-29T23:10:27Z

Pkulkar5: /* Test files method in the FileHelper module */

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-29T23:10:10Z

Pkulkar5: /* Test files method in the FileHelper module */

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-29T23:09:56Z

Pkulkar5: /* Test files method in the FileHelper module */

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-29T23:09:24Z

Pkulkar5: /* Test files method in the FileHelper module */

== E1603. Refactor user, course_participant and assignment_participant model ==
This page provides details about the changes made to Expertiza under project E1603. Refactor user, course_participant and assignment_participant model.

==Background==
Expertiza is an educational web application built on top of Ruby on Rails. The project is open source with code available on Github and maintained by both the students and faculty of the NC State University. The application allows instructors to manage courses and assignments. The students can choose a topic from the list for an assignment, form a team, submit their work and do multiple reviews on other's work. The application helps instructors and teaching assistants in scoring and maintaining the grades for the assignment.

==Description==
The users of the expertiza are modeled using the user model. A participant signs up for courses and assignments. A user can have multiple participants and all participants belong to a user. The participant model is inherited by the course and assignment participant model. Our work involves refactoring functions defined in these models. Some methods were moved to places with better fit and some methods were improvised with better implementations. The further sections in the document will explain the changes complement and how it will impact the overall usage of expertiza.

==Tasks accomplished in this project==
* Moved the export_fields method to the User model from CourseParticipant model to remove redudancy.
* Added attr_accessible modifier to CourseParticipant to improve security.
* Refactored the get_user_list method into smaller methods, one method for each if condition in User model.
* Moved the ‘files’ method from AssignmentParticipant model which was duplicate and used in assignment_team.rb as well to a common place (FileHelper module).
* Refactored the average_question_score method by using sql summation to find values for sum_of_scores and number_of_scores variables in AssignmentParticipant model.

==Models==

===User===
The user model stores details of the user like name,email,role,timezone and his preferences on how expertiza should behave to him. A user can have many roles like student, instructor or administrator. The user model is used for logging in, participating in courses, assignments and creating teams. The user model maintains parent child relationship, a user will have one parent and can have many children.

===Assignment Participant===
Expertiza uses a participant abstraction for modeling the participance of a user in any of the activities like courses and assignments. A participant belongs to a user and it represents a connection between a user and an activity. Assignment_participant, which is a child class of participant models the association between users and assignments. This association also needs to be mapped to other activities performed by a user related to the assignment. These activities include reviews, quiz, response to reviews, teammate reviews etc.. The assignment_participant model is related to models which is responsible for all the mentioned activities.

===Course Participant===
The course_participant is a child class of the participant abstraction and it represents the association between a user and a course. The model also stores fields required for the association and supports bulk importing and exporting.

==Changes==

===Refactoring: Duplicated export_fields method===
This method exports the headers of the csv file to be downloaded. The method export_fields occurs in various models with different implementations. However, the implementation for this method had been duplicated in course_participant and user models. This led to the disadvantage of having redundant code in the system and an inefficient coding practice. User model represents the base class and other models inherit from this class. Hence, deleting the method from User model made little sense. The refactoring invoked the User models export_fields method from within the export_fields of course_participant. Since the export_file controller calls this method on the course_participant object, there wasn't a choice to delete the method completely. This refactoring has the advantage that code is reused and the proper object is tied to the header fields instead of just the generic User object.

===Refactoring: Breaking get_user_list method===
This method contained a lot of if-else statements that executed different codes depending on the type of user. The refactoring broke the large method into smaller methods, one for each user type. This improved the modularity of the code. It made the code more manageable and understandable from maintenance point of view (separation of responsibilities).

===Refactoring: Use SQL summation to calculate average_question_score===
The average of the score for a question in the review given by all other students who reviewed an assignment needs to be calculated in the average_question_score method in assignment participant model. This was originally implemented by using two for loops and fetching all the answers given by all the reviewers and then filtering using an if statement. This method consumes more CPU cycles and impacts the performance of the application server. It also consumes more bandwidth since the application fetches all the data from the database but returns only one value to the user. This was reimplemented to use the SQL summation inside the database and returns the only desired value to the application. This method also takes advantage of the database indexing and fetches only values required instead of filtering in the application.

===Refactoring: Add attr_accessible to class to improve security===
The course_participant model has a number of instance variables like can_submit, can_review, user_id, parent_id, submitted_at, permission_granted, penalty_accumulated, grade, type, handle, time_stamp, digital_signature, duty, can_take_quiz. Earlier, these variables were less secure and hence susceptible to tampering with URLs or forms from malicious users. In general, elements are filled based on the data sent as a hash from the view. This happens as mass assignment where any matching key in the hash will be set. To protect this mass assignment from malicious attacks, a good design is to add attr_accessible macro. Adding this keyword to instance variables ensures that only the specified attributes in the list of attr_accessible are allowed for mass assignment. This ensures that developers can carefully consider which attributes should be allowed to do mass assignment. This way, the refactoring is done.
<code>attr_accessible :can_submit, :can_review, :user_id, :parent_id, :submitted_at, :permission_granted, :penalty_accumulated, :grade, :type, :handle, :time_stamp, :digital_signature, :duty, :can_take_quiz</code>

===Refactoring: files method is duplicate and used in assignment_team.rb as well. Move it to either a common place or keep it at the most appropriate place===
This refactoring belongs to AssignmentParticipant model. This model is a special class of Participant and it denotes the participants who have collaborated for a particular Assignment. This method takes a parameter which is a directory and it returns all the files present in that directory. The directory argument is basically a string containing the file path for reviewer uploaded files during peer review. This argument comes from AssignmentParticipant model but the files method as a whole is independent of the model as its function is to return files present in a directory. It does not need to belong to any model. Hence the ‘files’ method must be placed in file_helper.rb. Thus the ‘files’ method is moved from the AssignmentParticipant model to a helper module like file_helper.rb. The design principle that is reinforced here is that a class must have responsibilities that belong to itself and not other “helper” responsibilities. This is an implementation of Separation Of Concerns design principle.

<code>
def files(directory)
files_list = Dir[directory + "/*"]
files = Array.new
files_list.each do |file|
if File.directory?(file)
dir_files = files(file)
dir_files.each{|f| files << f}
end
files << file
end
files
end
</code>

===Refactoring: topic_name in Participant.rb===
In participant.rb model, there is a method topic_name. However, this method doesn't seem to be required here. A course participant cannot have a topic. If it is an assignment participant object, we can find which team that participant is in first, then find which topic is this team holding. In fact, there is a topic_name field in SignedUpTeam class. On thorough investigation, we found that the method has no caller, which is the right implementation in any case. Hence, the refactoring involved deleting this method altogether. The refactoring was verified by the fact that none of the existing test cases failed.

==Testing==
Expertiza mainly uses RSpec for testing and has a comprehensive set of test cases overall. However, there are some models that do not have the required rspecs. We have included test cases for all the refactoring that we have done. We also ensured that the existing test cases do not fail.

===Test adding attr_accessible to class to improve security===
The earlier version of Expertiza did not have an rspec for the CourseParticipant model. We added an rspec named course_participant_spec.rb as the rspec for this model covering tests for the refactorings done in this project. The attr_accessible improves security by allowing only those fields that are in the list of attr_accessible macro for mass assignment. We test this by using “should allow_mass_assignment_of” and “should_not allow_mass_assignment_of”. Those attributes that are not in the list of attr_accessible will pass the test only when tested as “should_not allow_mass_assignment_of” and the attributes that are in the list of attr_accessible will pass the test only when tested as “should allow_mass_assignment_of”. The following is the code snippet of the test case.
<code>
describe "#accessible attributes" do
it { should allow_mass_assignment_of(:can_submit) }
it { should allow_mass_assignment_of(:can_review) }
it { should allow_mass_assignment_of(:user_id) }
it { should allow_mass_assignment_of(:parent_id) }
it { should allow_mass_assignment_of(:submitted_at) }
it { should allow_mass_assignment_of(:permission_granted) }
it { should allow_mass_assignment_of(:penalty_accumulated) }
it { should allow_mass_assignment_of(:grade) }
it { should allow_mass_assignment_of(:type) }
it { should allow_mass_assignment_of(:handle) }
it { should allow_mass_assignment_of(:time_stamp) }
it { should allow_mass_assignment_of(:digital_signature) }
it { should allow_mass_assignment_of(:duty) }
it { should allow_mass_assignment_of(:can_take_quiz) }
end
</code>

===Test the export_fields method===
This refactoring was done in the CourseParticipant model. The duplication is removed and the export_fields method is kept only in the User model and a call to the User model is made from CourseParticipant. To test this method, we test the functionality of this method as there is no test case for this method in the previous version. The export_fields method takes an argument of options which is a list of all the fields that the end user wants to export as course participant data and it returns the corresponding fields by making a call to User model. The ideal test case will test only the export_fields in the course_participant model and not the one in user model. This is in line with the strategy of testing incoming query messages by making assertions about what they send back. Therefore, for a given set of options, only the required right set of fields are to be returned. We expect that the returned list of fields will match the ones the method asked using the options field. Below is a sample test snippet.
<code>
describe "#export_fields" do
it "returns export fields for a csv based on radio buttons checked" do
options = {"personal_details"=>"true", "role"=>"true", "parent"=>"true", "email_options"=>"true", "handle"=>"true"}
fields = ["name", "full name", "email", "role", "parent", "email on submission", "email on review", "email on metareview", "handle"]
expect(CourseParticipant.export_fields(options)).to match_array(fields)
end
</code>

===Test refactoring of get_user_list method into smaller methods===
In order to test get_user_list, we create a dummy object of User and set its role as instructor and fetch the user list of that instructor which returns the list of participants of that instructor’s course. The list could be empty or non empty depending on the user object.
<code>
describe "#get_user_list" do
it 'user list' do
@role = Role.new name: "Instructor"
user1 = User.new name: "instructor4", role: @role
expect(user1.get_user_list).to be_empty
expect(user1.get_users_instructor)
end
end
</code>

===Test files method in the FileHelper module===
The files method takes an argument of a directory path and returns all the files present in that directory. In the original repository, there was no test case for this method. We have added a test for this method in the file_helper_spec.rb file. The test case takes an example directory like /tmp/expertiza1603/ and returns the files present in that directory. Since the test cases can be run in any environment, the result of the test case is dependent on the presence of such a directory structure. We have created a sample directory with two files on the VCL environment(152.7.99.160). If such a directory is not present, it is important to create a directory by that name.
<code>
describe FileHelper do
class DummyClass
end

before(:each) do
@dummy_class = DummyClass.new
@dummy_class.extend(FileHelper)
end

describe "#files" do
it 'return files present in a dir' do
expected_array = ["/tmp/expertiza1603/1.txt", "/tmp/expertiza1603/2.txt"]
expect(@dummy_class.files("/tmp/expertiza1603")).to match_array(expected_array)
end
end
end
</code>

===Testing through GUI===

====Test export fields method====
*Login as super_administrator2 or administrator5 with password as "password"
*Click on "Manage..."" and click on "Courses"
*On the "Actions" tab, click on "Add Participants"
*On the page that opens up, go to the bottom and select "Export course participants"
*Click on "Export" button and a csv file should download with the selected radio button fields.

====Test get_user_list method====
*Login as super_administrator2 or administrator5 with password as "password"
*Click on "Manage..."" and click on "Users"
*You should see all the users on the page.

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-29T23:08:39Z

Pkulkar5: /* Testing */

== E1603. Refactor user, course_participant and assignment_participant model ==
This page provides details about the changes made to Expertiza under project E1603. Refactor user, course_participant and assignment_participant model.

==Background==
Expertiza is an educational web application built on top of Ruby on Rails. The project is open source with code available on Github and maintained by both the students and faculty of the NC State University. The application allows instructors to manage courses and assignments. The students can choose a topic from the list for an assignment, form a team, submit their work and do multiple reviews on other's work. The application helps instructors and teaching assistants in scoring and maintaining the grades for the assignment.

==Description==
The users of the expertiza are modeled using the user model. A participant signs up for courses and assignments. A user can have multiple participants and all participants belong to a user. The participant model is inherited by the course and assignment participant model. Our work involves refactoring functions defined in these models. Some methods were moved to places with better fit and some methods were improvised with better implementations. The further sections in the document will explain the changes complement and how it will impact the overall usage of expertiza.

==Tasks accomplished in this project==
* Moved the export_fields method to the User model from CourseParticipant model to remove redudancy.
* Added attr_accessible modifier to CourseParticipant to improve security.
* Refactored the get_user_list method into smaller methods, one method for each if condition in User model.
* Moved the ‘files’ method from AssignmentParticipant model which was duplicate and used in assignment_team.rb as well to a common place (FileHelper module).
* Refactored the average_question_score method by using sql summation to find values for sum_of_scores and number_of_scores variables in AssignmentParticipant model.

==Models==

===User===
The user model stores details of the user like name,email,role,timezone and his preferences on how expertiza should behave to him. A user can have many roles like student, instructor or administrator. The user model is used for logging in, participating in courses, assignments and creating teams. The user model maintains parent child relationship, a user will have one parent and can have many children.

===Assignment Participant===
Expertiza uses a participant abstraction for modeling the participance of a user in any of the activities like courses and assignments. A participant belongs to a user and it represents a connection between a user and an activity. Assignment_participant, which is a child class of participant models the association between users and assignments. This association also needs to be mapped to other activities performed by a user related to the assignment. These activities include reviews, quiz, response to reviews, teammate reviews etc.. The assignment_participant model is related to models which is responsible for all the mentioned activities.

===Course Participant===
The course_participant is a child class of the participant abstraction and it represents the association between a user and a course. The model also stores fields required for the association and supports bulk importing and exporting.

==Changes==

===Refactoring: Duplicated export_fields method===
This method exports the headers of the csv file to be downloaded. The method export_fields occurs in various models with different implementations. However, the implementation for this method had been duplicated in course_participant and user models. This led to the disadvantage of having redundant code in the system and an inefficient coding practice. User model represents the base class and other models inherit from this class. Hence, deleting the method from User model made little sense. The refactoring invoked the User models export_fields method from within the export_fields of course_participant. Since the export_file controller calls this method on the course_participant object, there wasn't a choice to delete the method completely. This refactoring has the advantage that code is reused and the proper object is tied to the header fields instead of just the generic User object.

===Refactoring: Breaking get_user_list method===
This method contained a lot of if-else statements that executed different codes depending on the type of user. The refactoring broke the large method into smaller methods, one for each user type. This improved the modularity of the code. It made the code more manageable and understandable from maintenance point of view (separation of responsibilities).

===Refactoring: Use SQL summation to calculate average_question_score===
The average of the score for a question in the review given by all other students who reviewed an assignment needs to be calculated in the average_question_score method in assignment participant model. This was originally implemented by using two for loops and fetching all the answers given by all the reviewers and then filtering using an if statement. This method consumes more CPU cycles and impacts the performance of the application server. It also consumes more bandwidth since the application fetches all the data from the database but returns only one value to the user. This was reimplemented to use the SQL summation inside the database and returns the only desired value to the application. This method also takes advantage of the database indexing and fetches only values required instead of filtering in the application.

===Refactoring: Add attr_accessible to class to improve security===
The course_participant model has a number of instance variables like can_submit, can_review, user_id, parent_id, submitted_at, permission_granted, penalty_accumulated, grade, type, handle, time_stamp, digital_signature, duty, can_take_quiz. Earlier, these variables were less secure and hence susceptible to tampering with URLs or forms from malicious users. In general, elements are filled based on the data sent as a hash from the view. This happens as mass assignment where any matching key in the hash will be set. To protect this mass assignment from malicious attacks, a good design is to add attr_accessible macro. Adding this keyword to instance variables ensures that only the specified attributes in the list of attr_accessible are allowed for mass assignment. This ensures that developers can carefully consider which attributes should be allowed to do mass assignment. This way, the refactoring is done.
<code>attr_accessible :can_submit, :can_review, :user_id, :parent_id, :submitted_at, :permission_granted, :penalty_accumulated, :grade, :type, :handle, :time_stamp, :digital_signature, :duty, :can_take_quiz</code>

===Refactoring: files method is duplicate and used in assignment_team.rb as well. Move it to either a common place or keep it at the most appropriate place===
This refactoring belongs to AssignmentParticipant model. This model is a special class of Participant and it denotes the participants who have collaborated for a particular Assignment. This method takes a parameter which is a directory and it returns all the files present in that directory. The directory argument is basically a string containing the file path for reviewer uploaded files during peer review. This argument comes from AssignmentParticipant model but the files method as a whole is independent of the model as its function is to return files present in a directory. It does not need to belong to any model. Hence the ‘files’ method must be placed in file_helper.rb. Thus the ‘files’ method is moved from the AssignmentParticipant model to a helper module like file_helper.rb. The design principle that is reinforced here is that a class must have responsibilities that belong to itself and not other “helper” responsibilities. This is an implementation of Separation Of Concerns design principle.

<code>
def files(directory)
files_list = Dir[directory + "/*"]
files = Array.new
files_list.each do |file|
if File.directory?(file)
dir_files = files(file)
dir_files.each{|f| files << f}
end
files << file
end
files
end
</code>

===Refactoring: topic_name in Participant.rb===
In participant.rb model, there is a method topic_name. However, this method doesn't seem to be required here. A course participant cannot have a topic. If it is an assignment participant object, we can find which team that participant is in first, then find which topic is this team holding. In fact, there is a topic_name field in SignedUpTeam class. On thorough investigation, we found that the method has no caller, which is the right implementation in any case. Hence, the refactoring involved deleting this method altogether. The refactoring was verified by the fact that none of the existing test cases failed.

==Testing==
Expertiza mainly uses RSpec for testing and has a comprehensive set of test cases overall. However, there are some models that do not have the required rspecs. We have included test cases for all the refactoring that we have done. We also ensured that the existing test cases do not fail.

===Test adding attr_accessible to class to improve security===
The earlier version of Expertiza did not have an rspec for the CourseParticipant model. We added an rspec named course_participant_spec.rb as the rspec for this model covering tests for the refactorings done in this project. The attr_accessible improves security by allowing only those fields that are in the list of attr_accessible macro for mass assignment. We test this by using “should allow_mass_assignment_of” and “should_not allow_mass_assignment_of”. Those attributes that are not in the list of attr_accessible will pass the test only when tested as “should_not allow_mass_assignment_of” and the attributes that are in the list of attr_accessible will pass the test only when tested as “should allow_mass_assignment_of”. The following is the code snippet of the test case.
<code>
describe "#accessible attributes" do
it { should allow_mass_assignment_of(:can_submit) }
it { should allow_mass_assignment_of(:can_review) }
it { should allow_mass_assignment_of(:user_id) }
it { should allow_mass_assignment_of(:parent_id) }
it { should allow_mass_assignment_of(:submitted_at) }
it { should allow_mass_assignment_of(:permission_granted) }
it { should allow_mass_assignment_of(:penalty_accumulated) }
it { should allow_mass_assignment_of(:grade) }
it { should allow_mass_assignment_of(:type) }
it { should allow_mass_assignment_of(:handle) }
it { should allow_mass_assignment_of(:time_stamp) }
it { should allow_mass_assignment_of(:digital_signature) }
it { should allow_mass_assignment_of(:duty) }
it { should allow_mass_assignment_of(:can_take_quiz) }
end
</code>

===Test the export_fields method===
This refactoring was done in the CourseParticipant model. The duplication is removed and the export_fields method is kept only in the User model and a call to the User model is made from CourseParticipant. To test this method, we test the functionality of this method as there is no test case for this method in the previous version. The export_fields method takes an argument of options which is a list of all the fields that the end user wants to export as course participant data and it returns the corresponding fields by making a call to User model. The ideal test case will test only the export_fields in the course_participant model and not the one in user model. This is in line with the strategy of testing incoming query messages by making assertions about what they send back. Therefore, for a given set of options, only the required right set of fields are to be returned. We expect that the returned list of fields will match the ones the method asked using the options field. Below is a sample test snippet.
<code>
describe "#export_fields" do
it "returns export fields for a csv based on radio buttons checked" do
options = {"personal_details"=>"true", "role"=>"true", "parent"=>"true", "email_options"=>"true", "handle"=>"true"}
fields = ["name", "full name", "email", "role", "parent", "email on submission", "email on review", "email on metareview", "handle"]
expect(CourseParticipant.export_fields(options)).to match_array(fields)
end
</code>

===Test refactoring of get_user_list method into smaller methods===
In order to test get_user_list, we create a dummy object of User and set its role as instructor and fetch the user list of that instructor which returns the list of participants of that instructor’s course. The list could be empty or non empty depending on the user object.
<code>
describe "#get_user_list" do
it 'user list' do
@role = Role.new name: "Instructor"
user1 = User.new name: "instructor4", role: @role
expect(user1.get_user_list).to be_empty
expect(user1.get_users_instructor)
end
end
</code>

===Test files method in the FileHelper module===
The files method takes an argument of a directory path and returns all the files present in that directory. In the original repository, there was no test case for this method. We have added a test for this method in the file_helper_spec.rb file. The test case takes an example directory like /tmp/expertiza1603/ and returns the files present in that directory. Since the test cases can be run in any environment, the result of the test case is dependent on the presence of such a directory structure. We have created a sample directory with two files on the VCL environment(152.7.99.160). If such a directory is not present, it is important to create a directory by that name.
<code>
describe FileHelper do

class DummyClass
end

before(:each) do
@dummy_class = DummyClass.new
@dummy_class.extend(FileHelper)
end

describe "#files" do
it 'return files present in a dir' do
expected_array = ["/tmp/expertiza1603/1.txt", "/tmp/expertiza1603/2.txt"]
expect(@dummy_class.files("/tmp/expertiza1603")).to match_array(expected_array)
end
end
end
</code>

===Testing through GUI===

====Test export fields method====
*Login as super_administrator2 or administrator5 with password as "password"
*Click on "Manage..."" and click on "Courses"
*On the "Actions" tab, click on "Add Participants"
*On the page that opens up, go to the bottom and select "Export course participants"
*Click on "Export" button and a csv file should download with the selected radio button fields.

====Test get_user_list method====
*Login as super_administrator2 or administrator5 with password as "password"
*Click on "Manage..."" and click on "Users"
*You should see all the users on the page.

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-29T22:02:20Z

Pkulkar5: /* Testing through GUI */

== E1603. Refactor user, course_participant and assignment_participant model ==
This page provides details about the changes made to Expertiza under project E1603. Refactor user, course_participant and assignment_participant model.

==Background==
Expertiza is an educational web application built on top of Ruby on Rails. The project is open source with code available on Github and maintained by both the students and faculty of the NC State University. The application allows instructors to manage courses and assignments. The students can choose a topic from the list for an assignment, form a team, submit their work and do multiple reviews on other's work. The application helps instructors and teaching assistants in scoring and maintaining the grades for the assignment.

==Description==
The users of the expertiza are modeled using the user model. A participant signs up for courses and assignments. A user can have multiple participants and all participants belong to a user. The participant model is inherited by the course and assignment participant model. Our work involves refactoring functions defined in these models. Some methods were moved to places with better fit and some methods were improvised with better implementations. The further sections in the document will explain the changes complement and how it will impact the overall usage of expertiza.

==Tasks accomplished in this project==
* Moved the export_fields method to the User model from CourseParticipant model to remove redudancy.
* Added attr_accessible modifier to CourseParticipant to improve security.
* Refactored the get_user_list method into smaller methods, one method for each if condition in User model.
* Moved the ‘files’ method from AssignmentParticipant model which was duplicate and used in assignment_team.rb as well to a common place (FileHelper module).
* Refactored the average_question_score method by using sql summation to find values for sum_of_scores and number_of_scores variables in AssignmentParticipant model.

==Models==

===User===
The user model stores details of the user like name,email,role,timezone and his preferences on how expertiza should behave to him. A user can have many roles like student, instructor or administrator. The user model is used for logging in, participating in courses, assignments and creating teams. The user model maintains parent child relationship, a user will have one parent and can have many children.

===Assignment Participant===
Expertiza uses a participant abstraction for modeling the participance of a user in any of the activities like courses and assignments. A participant belongs to a user and it represents a connection between a user and an activity. Assignment_participant, which is a child class of participant models the association between users and assignments. This association also needs to be mapped to other activities performed by a user related to the assignment. These activities include reviews, quiz, response to reviews, teammate reviews etc.. The assignment_participant model is related to models which is responsible for all the mentioned activities.

===Course Participant===
The course_participant is a child class of the participant abstraction and it represents the association between a user and a course. The model also stores fields required for the association and supports bulk importing and exporting.

==Changes==

===Refactoring: Duplicated export_fields method===
This method exports the headers of the csv file to be downloaded. The method export_fields occurs in various models with different implementations. However, the implementation for this method had been duplicated in course_participant and user models. This led to the disadvantage of having redundant code in the system and an inefficient coding practice. User model represents the base class and other models inherit from this class. Hence, deleting the method from User model made little sense. The refactoring invoked the User models export_fields method from within the export_fields of course_participant. Since the export_file controller calls this method on the course_participant object, there wasn't a choice to delete the method completely. This refactoring has the advantage that code is reused and the proper object is tied to the header fields instead of just the generic User object.

===Refactoring: Breaking get_user_list method===
This method contained a lot of if-else statements that executed different codes depending on the type of user. The refactoring broke the large method into smaller methods, one for each user type. This improved the modularity of the code. It made the code more manageable and understandable from maintenance point of view (separation of responsibilities).

===Refactoring: Use SQL summation to calculate average_question_score===
The average of the score for a question in the review given by all other students who reviewed an assignment needs to be calculated in the average_question_score method in assignment participant model. This was originally implemented by using two for loops and fetching all the answers given by all the reviewers and then filtering using an if statement. This method consumes more CPU cycles and impacts the performance of the application server. It also consumes more bandwidth since the application fetches all the data from the database but returns only one value to the user. This was reimplemented to use the SQL summation inside the database and returns the only desired value to the application. This method also takes advantage of the database indexing and fetches only values required instead of filtering in the application.

===Refactoring: Add attr_accessible to class to improve security===
The course_participant model has a number of instance variables like can_submit, can_review, user_id, parent_id, submitted_at, permission_granted, penalty_accumulated, grade, type, handle, time_stamp, digital_signature, duty, can_take_quiz. Earlier, these variables were less secure and hence susceptible to tampering with URLs or forms from malicious users. In general, elements are filled based on the data sent as a hash from the view. This happens as mass assignment where any matching key in the hash will be set. To protect this mass assignment from malicious attacks, a good design is to add attr_accessible macro. Adding this keyword to instance variables ensures that only the specified attributes in the list of attr_accessible are allowed for mass assignment. This ensures that developers can carefully consider which attributes should be allowed to do mass assignment. This way, the refactoring is done.
<code>attr_accessible :can_submit, :can_review, :user_id, :parent_id, :submitted_at, :permission_granted, :penalty_accumulated, :grade, :type, :handle, :time_stamp, :digital_signature, :duty, :can_take_quiz</code>

===Refactoring: files method is duplicate and used in assignment_team.rb as well. Move it to either a common place or keep it at the most appropriate place===
This refactoring belongs to AssignmentParticipant model. This model is a special class of Participant and it denotes the participants who have collaborated for a particular Assignment. This method takes a parameter which is a directory and it returns all the files present in that directory. The directory argument is basically a string containing the file path for reviewer uploaded files during peer review. This argument comes from AssignmentParticipant model but the files method as a whole is independent of the model as its function is to return files present in a directory. It does not need to belong to any model. Hence the ‘files’ method must be placed in file_helper.rb. Thus the ‘files’ method is moved from the AssignmentParticipant model to a helper module like file_helper.rb. The design principle that is reinforced here is that a class must have responsibilities that belong to itself and not other “helper” responsibilities. This is an implementation of Separation Of Concerns design principle.

<code>
def files(directory)
files_list = Dir[directory + "/*"]
files = Array.new
files_list.each do |file|
if File.directory?(file)
dir_files = files(file)
dir_files.each{|f| files << f}
end
files << file
end
files
end
</code>

===Refactoring: topic_name in Participant.rb===
In participant.rb model, there is a method topic_name. However, this method doesn't seem to be required here. A course participant cannot have a topic. If it is an assignment participant object, we can find which team that participant is in first, then find which topic is this team holding. In fact, there is a topic_name field in SignedUpTeam class. On thorough investigation, we found that the method has no caller, which is the right implementation in any case. Hence, the refactoring involved deleting this method altogether. The refactoring was verified by the fact that none of the existing test cases failed.

==Testing==
Expertiza mainly uses RSpec for testing and has a comprehensive set of test cases overall. However, there are some models that do not have the required rspecs. We have included test cases for all the refactoring that we have done. We also ensured that the existing test cases do not fail.

===Test adding attr_accessible to class to improve security===
The earlier version of Expertiza did not have an rspec for the CourseParticipant model. We added an rspec named course_participant_spec.rb as the rspec for this model covering tests for the refactorings done in this project. The attr_accessible improves security by allowing only those fields that are in the list of attr_accessible macro for mass assignment. We test this by using “should allow_mass_assignment_of” and “should_not allow_mass_assignment_of”. Those attributes that are not in the list of attr_accessible will pass the test only when tested as “should_not allow_mass_assignment_of” and the attributes that are in the list of attr_accessible will pass the test only when tested as “should allow_mass_assignment_of”. The following is the code snippet of the test case.
<code>
describe "#accessible attributes" do
it { should allow_mass_assignment_of(:can_submit) }
it { should allow_mass_assignment_of(:can_review) }
it { should allow_mass_assignment_of(:user_id) }
it { should allow_mass_assignment_of(:parent_id) }
it { should allow_mass_assignment_of(:submitted_at) }
it { should allow_mass_assignment_of(:permission_granted) }
it { should allow_mass_assignment_of(:penalty_accumulated) }
it { should allow_mass_assignment_of(:grade) }
it { should allow_mass_assignment_of(:type) }
it { should allow_mass_assignment_of(:handle) }
it { should allow_mass_assignment_of(:time_stamp) }
it { should allow_mass_assignment_of(:digital_signature) }
it { should allow_mass_assignment_of(:duty) }
it { should allow_mass_assignment_of(:can_take_quiz) }
end
</code>

===Test the export_fields method===
This refactoring was done in the CourseParticipant model. The duplication is removed and the export_fields method is kept only in the User model and a call to the User model is made from CourseParticipant. To test this method, we test the functionality of this method as there is no test case for this method in the previous version. The export_fields method takes an argument of options which is a list of all the fields that the end user wants to export as course participant data and it returns the corresponding fields by making a call to User model. The ideal test case will test only the export_fields in the course_participant model and not the one in user model. This is in line with the strategy of testing incoming query messages by making assertions about what they send back. Therefore, for a given set of options, only the required right set of fields are to be returned. We expect that the returned list of fields will match the ones the method asked using the options field. Below is a sample test snippet.
<code>
describe "#export_fields" do
it "returns export fields for a csv based on radio buttons checked" do
options = {"personal_details"=>"true", "role"=>"true", "parent"=>"true", "email_options"=>"true", "handle"=>"true"}
fields = ["name", "full name", "email", "role", "parent", "email on submission", "email on review", "email on metareview", "handle"]
expect(CourseParticipant.export_fields(options)).to match_array(fields)
end
</code>

===Test refactoring of get_user_list method into smaller methods===
In order to test get_user_list, we create a dummy object of User and set its role as instructor and fetch the user list of that instructor which returns the list of participants of that instructor’s course. The list could be empty or non empty depending on the user object.
<code>
describe "#get_user_list" do
it 'user list' do
@role = Role.new name: "Instructor"
user1 = User.new name: "instructor4", role: @role
expect(user1.get_user_list).to be_empty
expect(user1.get_users_instructor)
end
end
</code>

===Testing through GUI===

====Test export fields method====
*Login as super_administrator2 or administrator5 with password as "password"
*Click on "Manage..."" and click on "Courses"
*On the "Actions" tab, click on "Add Participants"
*On the page that opens up, go to the bottom and select "Export course participants"
*Click on "Export" button and a csv file should download with the selected radio button fields.

====Test get_user_list method====
*Login as super_administrator2 or administrator5 with password as "password"
*Click on "Manage..."" and click on "Users"
*You should see all the users on the page.

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-29T21:35:31Z

Pkulkar5: /* Testing through GUI */

== E1603. Refactor user, course_participant and assignment_participant model ==
This page provides details about the changes made to Expertiza under project E1603. Refactor user, course_participant and assignment_participant model.

==Background==
Expertiza is an educational web application built on top of Ruby on Rails. The project is open source with code available on Github and maintained by both the students and faculty of the NC State University. The application allows instructors to manage courses and assignments. The students can choose a topic from the list for an assignment, form a team, submit their work and do multiple reviews on other's work. The application helps instructors and teaching assistants in scoring and maintaining the grades for the assignment.

==Description==
The users of the expertiza are modeled using the user model. A participant signs up for courses and assignments. A user can have multiple participants and all participants belong to a user. The participant model is inherited by the course and assignment participant model. Our work involves refactoring functions defined in these models. Some methods were moved to places with better fit and some methods were improvised with better implementations. The further sections in the document will explain the changes complement and how it will impact the overall usage of expertiza.

==Tasks accomplished in this project==
* Moved the export_fields method to the User model from CourseParticipant model to remove redudancy.
* Added attr_accessible modifier to CourseParticipant to improve security.
* Refactored the get_user_list method into smaller methods, one method for each if condition in User model.
* Moved the ‘files’ method from AssignmentParticipant model which was duplicate and used in assignment_team.rb as well to a common place (FileHelper module).
* Refactored the average_question_score method by using sql summation to find values for sum_of_scores and number_of_scores variables in AssignmentParticipant model.

==Models==

===User===
The user model stores details of the user like name,email,role,timezone and his preferences on how expertiza should behave to him. A user can have many roles like student, instructor or administrator. The user model is used for logging in, participating in courses, assignments and creating teams. The user model maintains parent child relationship, a user will have one parent and can have many children.

===Assignment Participant===
Expertiza uses a participant abstraction for modeling the participance of a user in any of the activities like courses and assignments. A participant belongs to a user and it represents a connection between a user and an activity. Assignment_participant, which is a child class of participant models the association between users and assignments. This association also needs to be mapped to other activities performed by a user related to the assignment. These activities include reviews, quiz, response to reviews, teammate reviews etc.. The assignment_participant model is related to models which is responsible for all the mentioned activities.

===Course Participant===
The course_participant is a child class of the participant abstraction and it represents the association between a user and a course. The model also stores fields required for the association and supports bulk importing and exporting.

==Changes==

===Refactoring: Duplicated export_fields method===
This method exports the headers of the csv file to be downloaded. The method export_fields occurs in various models with different implementations. However, the implementation for this method had been duplicated in course_participant and user models. This led to the disadvantage of having redundant code in the system and an inefficient coding practice. User model represents the base class and other models inherit from this class. Hence, deleting the method from User model made little sense. The refactoring invoked the User models export_fields method from within the export_fields of course_participant. Since the export_file controller calls this method on the course_participant object, there wasn't a choice to delete the method completely. This refactoring has the advantage that code is reused and the proper object is tied to the header fields instead of just the generic User object.

===Refactoring: Breaking get_user_list method===
This method contained a lot of if-else statements that executed different codes depending on the type of user. The refactoring broke the large method into smaller methods, one for each user type. This improved the modularity of the code. It made the code more manageable and understandable from maintenance point of view (separation of responsibilities).

===Refactoring: Use SQL summation to calculate average_question_score===
The average of the score for a question in the review given by all other students who reviewed an assignment needs to be calculated in the average_question_score method in assignment participant model. This was originally implemented by using two for loops and fetching all the answers given by all the reviewers and then filtering using an if statement. This method consumes more CPU cycles and impacts the performance of the application server. It also consumes more bandwidth since the application fetches all the data from the database but returns only one value to the user. This was reimplemented to use the SQL summation inside the database and returns the only desired value to the application. This method also takes advantage of the database indexing and fetches only values required instead of filtering in the application.

===Refactoring: Add attr_accessible to class to improve security===
The course_participant model has a number of instance variables like can_submit, can_review, user_id, parent_id, submitted_at, permission_granted, penalty_accumulated, grade, type, handle, time_stamp, digital_signature, duty, can_take_quiz. Earlier, these variables were less secure and hence susceptible to tampering with URLs or forms from malicious users. In general, elements are filled based on the data sent as a hash from the view. This happens as mass assignment where any matching key in the hash will be set. To protect this mass assignment from malicious attacks, a good design is to add attr_accessible macro. Adding this keyword to instance variables ensures that only the specified attributes in the list of attr_accessible are allowed for mass assignment. This ensures that developers can carefully consider which attributes should be allowed to do mass assignment. This way, the refactoring is done.
<code>attr_accessible :can_submit, :can_review, :user_id, :parent_id, :submitted_at, :permission_granted, :penalty_accumulated, :grade, :type, :handle, :time_stamp, :digital_signature, :duty, :can_take_quiz</code>

===Refactoring: files method is duplicate and used in assignment_team.rb as well. Move it to either a common place or keep it at the most appropriate place===
This refactoring belongs to AssignmentParticipant model. This model is a special class of Participant and it denotes the participants who have collaborated for a particular Assignment. This method takes a parameter which is a directory and it returns all the files present in that directory. The directory argument is basically a string containing the file path for reviewer uploaded files during peer review. This argument comes from AssignmentParticipant model but the files method as a whole is independent of the model as its function is to return files present in a directory. It does not need to belong to any model. Hence the ‘files’ method must be placed in file_helper.rb. Thus the ‘files’ method is moved from the AssignmentParticipant model to a helper module like file_helper.rb. The design principle that is reinforced here is that a class must have responsibilities that belong to itself and not other “helper” responsibilities. This is an implementation of Separation Of Concerns design principle.

<code>
def files(directory)
files_list = Dir[directory + "/*"]
files = Array.new
files_list.each do |file|
if File.directory?(file)
dir_files = files(file)
dir_files.each{|f| files << f}
end
files << file
end
files
end
</code>

===Refactoring: topic_name in Participant.rb===
In participant.rb model, there is a method topic_name. However, this method doesn't seem to be required here. A course participant cannot have a topic. If it is an assignment participant object, we can find which team that participant is in first, then find which topic is this team holding. In fact, there is a topic_name field in SignedUpTeam class. On thorough investigation, we found that the method has no caller, which is the right implementation in any case. Hence, the refactoring involved deleting this method altogether. The refactoring was verified by the fact that none of the existing test cases failed.

==Testing==
Expertiza mainly uses RSpec for testing and has a comprehensive set of test cases overall. However, there are some models that do not have the required rspecs. We have included test cases for all the refactoring that we have done. We also ensured that the existing test cases do not fail.

===Test adding attr_accessible to class to improve security===
The earlier version of Expertiza did not have an rspec for the CourseParticipant model. We added an rspec named course_participant_spec.rb as the rspec for this model covering tests for the refactorings done in this project. The attr_accessible improves security by allowing only those fields that are in the list of attr_accessible macro for mass assignment. We test this by using “should allow_mass_assignment_of” and “should_not allow_mass_assignment_of”. Those attributes that are not in the list of attr_accessible will pass the test only when tested as “should_not allow_mass_assignment_of” and the attributes that are in the list of attr_accessible will pass the test only when tested as “should allow_mass_assignment_of”. The following is the code snippet of the test case.
<code>
describe "#accessible attributes" do
it { should allow_mass_assignment_of(:can_submit) }
it { should allow_mass_assignment_of(:can_review) }
it { should allow_mass_assignment_of(:user_id) }
it { should allow_mass_assignment_of(:parent_id) }
it { should allow_mass_assignment_of(:submitted_at) }
it { should allow_mass_assignment_of(:permission_granted) }
it { should allow_mass_assignment_of(:penalty_accumulated) }
it { should allow_mass_assignment_of(:grade) }
it { should allow_mass_assignment_of(:type) }
it { should allow_mass_assignment_of(:handle) }
it { should allow_mass_assignment_of(:time_stamp) }
it { should allow_mass_assignment_of(:digital_signature) }
it { should allow_mass_assignment_of(:duty) }
it { should allow_mass_assignment_of(:can_take_quiz) }
end
</code>

===Test the export_fields method===
This refactoring was done in the CourseParticipant model. The duplication is removed and the export_fields method is kept only in the User model and a call to the User model is made from CourseParticipant. To test this method, we test the functionality of this method as there is no test case for this method in the previous version. The export_fields method takes an argument of options which is a list of all the fields that the end user wants to export as course participant data and it returns the corresponding fields by making a call to User model. The ideal test case will test only the export_fields in the course_participant model and not the one in user model. This is in line with the strategy of testing incoming query messages by making assertions about what they send back. Therefore, for a given set of options, only the required right set of fields are to be returned. We expect that the returned list of fields will match the ones the method asked using the options field. Below is a sample test snippet.
<code>
describe "#export_fields" do
it "returns export fields for a csv based on radio buttons checked" do
options = {"personal_details"=>"true", "role"=>"true", "parent"=>"true", "email_options"=>"true", "handle"=>"true"}
fields = ["name", "full name", "email", "role", "parent", "email on submission", "email on review", "email on metareview", "handle"]
expect(CourseParticipant.export_fields(options)).to match_array(fields)
end
</code>

===Test refactoring of get_user_list method into smaller methods===
In order to test get_user_list, we create a dummy object of User and set its role as instructor and fetch the user list of that instructor which returns the list of participants of that instructor’s course. The list could be empty or non empty depending on the user object.
<code>
describe "#get_user_list" do
it 'user list' do
@role = Role.new name: "Instructor"
user1 = User.new name: "instructor4", role: @role
expect(user1.get_user_list).to be_empty
expect(user1.get_users_instructor)
end
end
</code>

===Testing through GUI===

====Test export fields method====
*Login as super_administrator2 with password as "password"
*Click on "Manage..."" and click on "Courses"
*On the "Actions" tab, click on "Add Participants"
*On the page that opens up, go to the bottom and select "Export course participants"
*Click on "Export" button and a csv file should download with the selected radio button fields.

====Test get_user_list method====
*Login as super_administrator2 with password as "password"
*Click on "Manage..."" and click on "Users"
*You should see all the users on the page.

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-29T21:27:45Z

Pkulkar5: /* Testing through GUI */

== E1603. Refactor user, course_participant and assignment_participant model ==
This page provides details about the changes made to Expertiza under project E1603. Refactor user, course_participant and assignment_participant model.

==Background==
Expertiza is an educational web application built on top of Ruby on Rails. The project is open source with code available on Github and maintained by both the students and faculty of the NC State University. The application allows instructors to manage courses and assignments. The students can choose a topic from the list for an assignment, form a team, submit their work and do multiple reviews on other's work. The application helps instructors and teaching assistants in scoring and maintaining the grades for the assignment.

==Description==
The users of the expertiza are modeled using the user model. A participant signs up for courses and assignments. A user can have multiple participants and all participants belong to a user. The participant model is inherited by the course and assignment participant model. Our work involves refactoring functions defined in these models. Some methods were moved to places with better fit and some methods were improvised with better implementations. The further sections in the document will explain the changes complement and how it will impact the overall usage of expertiza.

==Tasks accomplished in this project==
* Moved the export_fields method to the User model from CourseParticipant model to remove redudancy.
* Added attr_accessible modifier to CourseParticipant to improve security.
* Refactored the get_user_list method into smaller methods, one method for each if condition in User model.
* Moved the ‘files’ method from AssignmentParticipant model which was duplicate and used in assignment_team.rb as well to a common place (FileHelper module).
* Refactored the average_question_score method by using sql summation to find values for sum_of_scores and number_of_scores variables in AssignmentParticipant model.

==Models==

===User===
The user model stores details of the user like name,email,role,timezone and his preferences on how expertiza should behave to him. A user can have many roles like student, instructor or administrator. The user model is used for logging in, participating in courses, assignments and creating teams. The user model maintains parent child relationship, a user will have one parent and can have many children.

===Assignment Participant===
Expertiza uses a participant abstraction for modeling the participance of a user in any of the activities like courses and assignments. A participant belongs to a user and it represents a connection between a user and an activity. Assignment_participant, which is a child class of participant models the association between users and assignments. This association also needs to be mapped to other activities performed by a user related to the assignment. These activities include reviews, quiz, response to reviews, teammate reviews etc.. The assignment_participant model is related to models which is responsible for all the mentioned activities.

===Course Participant===
The course_participant is a child class of the participant abstraction and it represents the association between a user and a course. The model also stores fields required for the association and supports bulk importing and exporting.

==Changes==

===Refactoring: Duplicated export_fields method===
This method exports the headers of the csv file to be downloaded. The method export_fields occurs in various models with different implementations. However, the implementation for this method had been duplicated in course_participant and user models. This led to the disadvantage of having redundant code in the system and an inefficient coding practice. User model represents the base class and other models inherit from this class. Hence, deleting the method from User model made little sense. The refactoring invoked the User models export_fields method from within the export_fields of course_participant. Since the export_file controller calls this method on the course_participant object, there wasn't a choice to delete the method completely. This refactoring has the advantage that code is reused and the proper object is tied to the header fields instead of just the generic User object.

===Refactoring: Breaking get_user_list method===
This method contained a lot of if-else statements that executed different codes depending on the type of user. The refactoring broke the large method into smaller methods, one for each user type. This improved the modularity of the code. It made the code more manageable and understandable from maintenance point of view (separation of responsibilities).

===Refactoring: Use SQL summation to calculate average_question_score===
The average of the score for a question in the review given by all other students who reviewed an assignment needs to be calculated in the average_question_score method in assignment participant model. This was originally implemented by using two for loops and fetching all the answers given by all the reviewers and then filtering using an if statement. This method consumes more CPU cycles and impacts the performance of the application server. It also consumes more bandwidth since the application fetches all the data from the database but returns only one value to the user. This was reimplemented to use the SQL summation inside the database and returns the only desired value to the application. This method also takes advantage of the database indexing and fetches only values required instead of filtering in the application.

===Refactoring: Add attr_accessible to class to improve security===
The course_participant model has a number of instance variables like can_submit, can_review, user_id, parent_id, submitted_at, permission_granted, penalty_accumulated, grade, type, handle, time_stamp, digital_signature, duty, can_take_quiz. Earlier, these variables were less secure and hence susceptible to tampering with URLs or forms from malicious users. In general, elements are filled based on the data sent as a hash from the view. This happens as mass assignment where any matching key in the hash will be set. To protect this mass assignment from malicious attacks, a good design is to add attr_accessible macro. Adding this keyword to instance variables ensures that only the specified attributes in the list of attr_accessible are allowed for mass assignment. This ensures that developers can carefully consider which attributes should be allowed to do mass assignment. This way, the refactoring is done.
<code>attr_accessible :can_submit, :can_review, :user_id, :parent_id, :submitted_at, :permission_granted, :penalty_accumulated, :grade, :type, :handle, :time_stamp, :digital_signature, :duty, :can_take_quiz</code>

===Refactoring: files method is duplicate and used in assignment_team.rb as well. Move it to either a common place or keep it at the most appropriate place===
This refactoring belongs to AssignmentParticipant model. This model is a special class of Participant and it denotes the participants who have collaborated for a particular Assignment. This method takes a parameter which is a directory and it returns all the files present in that directory. The directory argument is basically a string containing the file path for reviewer uploaded files during peer review. This argument comes from AssignmentParticipant model but the files method as a whole is independent of the model as its function is to return files present in a directory. It does not need to belong to any model. Hence the ‘files’ method must be placed in file_helper.rb. Thus the ‘files’ method is moved from the AssignmentParticipant model to a helper module like file_helper.rb. The design principle that is reinforced here is that a class must have responsibilities that belong to itself and not other “helper” responsibilities. This is an implementation of Separation Of Concerns design principle.

<code>
def files(directory)
files_list = Dir[directory + "/*"]
files = Array.new
files_list.each do |file|
if File.directory?(file)
dir_files = files(file)
dir_files.each{|f| files << f}
end
files << file
end
files
end
</code>

===Refactoring: topic_name in Participant.rb===
In participant.rb model, there is a method topic_name. However, this method doesn't seem to be required here. A course participant cannot have a topic. If it is an assignment participant object, we can find which team that participant is in first, then find which topic is this team holding. In fact, there is a topic_name field in SignedUpTeam class. On thorough investigation, we found that the method has no caller, which is the right implementation in any case. Hence, the refactoring involved deleting this method altogether. The refactoring was verified by the fact that none of the existing test cases failed.

==Testing==
Expertiza mainly uses RSpec for testing and has a comprehensive set of test cases overall. However, there are some models that do not have the required rspecs. We have included test cases for all the refactoring that we have done. We also ensured that the existing test cases do not fail.

===Test adding attr_accessible to class to improve security===
The earlier version of Expertiza did not have an rspec for the CourseParticipant model. We added an rspec named course_participant_spec.rb as the rspec for this model covering tests for the refactorings done in this project. The attr_accessible improves security by allowing only those fields that are in the list of attr_accessible macro for mass assignment. We test this by using “should allow_mass_assignment_of” and “should_not allow_mass_assignment_of”. Those attributes that are not in the list of attr_accessible will pass the test only when tested as “should_not allow_mass_assignment_of” and the attributes that are in the list of attr_accessible will pass the test only when tested as “should allow_mass_assignment_of”. The following is the code snippet of the test case.
<code>
describe "#accessible attributes" do
it { should allow_mass_assignment_of(:can_submit) }
it { should allow_mass_assignment_of(:can_review) }
it { should allow_mass_assignment_of(:user_id) }
it { should allow_mass_assignment_of(:parent_id) }
it { should allow_mass_assignment_of(:submitted_at) }
it { should allow_mass_assignment_of(:permission_granted) }
it { should allow_mass_assignment_of(:penalty_accumulated) }
it { should allow_mass_assignment_of(:grade) }
it { should allow_mass_assignment_of(:type) }
it { should allow_mass_assignment_of(:handle) }
it { should allow_mass_assignment_of(:time_stamp) }
it { should allow_mass_assignment_of(:digital_signature) }
it { should allow_mass_assignment_of(:duty) }
it { should allow_mass_assignment_of(:can_take_quiz) }
end
</code>

===Test the export_fields method===
This refactoring was done in the CourseParticipant model. The duplication is removed and the export_fields method is kept only in the User model and a call to the User model is made from CourseParticipant. To test this method, we test the functionality of this method as there is no test case for this method in the previous version. The export_fields method takes an argument of options which is a list of all the fields that the end user wants to export as course participant data and it returns the corresponding fields by making a call to User model. The ideal test case will test only the export_fields in the course_participant model and not the one in user model. This is in line with the strategy of testing incoming query messages by making assertions about what they send back. Therefore, for a given set of options, only the required right set of fields are to be returned. We expect that the returned list of fields will match the ones the method asked using the options field. Below is a sample test snippet.
<code>
describe "#export_fields" do
it "returns export fields for a csv based on radio buttons checked" do
options = {"personal_details"=>"true", "role"=>"true", "parent"=>"true", "email_options"=>"true", "handle"=>"true"}
fields = ["name", "full name", "email", "role", "parent", "email on submission", "email on review", "email on metareview", "handle"]
expect(CourseParticipant.export_fields(options)).to match_array(fields)
end
</code>

===Test refactoring of get_user_list method into smaller methods===
In order to test get_user_list, we create a dummy object of User and set its role as instructor and fetch the user list of that instructor which returns the list of participants of that instructor’s course. The list could be empty or non empty depending on the user object.
<code>
describe "#get_user_list" do
it 'user list' do
@role = Role.new name: "Instructor"
user1 = User.new name: "instructor4", role: @role
expect(user1.get_user_list).to be_empty
expect(user1.get_users_instructor)
end
end
</code>

===Testing through GUI===
*Login as super_administrator2 with password as "password"
*Click on "Manage..."" and click on "Courses"
*On the "Actions" tab, click on "Add Participants"
*On the page that opens up, go to the bottom and select "Export course participants"
*Click on "Export" button and a csv file should download with the selected radio button fields.

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-29T21:27:31Z

Pkulkar5: /* Testing */

== E1603. Refactor user, course_participant and assignment_participant model ==
This page provides details about the changes made to Expertiza under project E1603. Refactor user, course_participant and assignment_participant model.

==Background==
Expertiza is an educational web application built on top of Ruby on Rails. The project is open source with code available on Github and maintained by both the students and faculty of the NC State University. The application allows instructors to manage courses and assignments. The students can choose a topic from the list for an assignment, form a team, submit their work and do multiple reviews on other's work. The application helps instructors and teaching assistants in scoring and maintaining the grades for the assignment.

==Description==
The users of the expertiza are modeled using the user model. A participant signs up for courses and assignments. A user can have multiple participants and all participants belong to a user. The participant model is inherited by the course and assignment participant model. Our work involves refactoring functions defined in these models. Some methods were moved to places with better fit and some methods were improvised with better implementations. The further sections in the document will explain the changes complement and how it will impact the overall usage of expertiza.

==Tasks accomplished in this project==
* Moved the export_fields method to the User model from CourseParticipant model to remove redudancy.
* Added attr_accessible modifier to CourseParticipant to improve security.
* Refactored the get_user_list method into smaller methods, one method for each if condition in User model.
* Moved the ‘files’ method from AssignmentParticipant model which was duplicate and used in assignment_team.rb as well to a common place (FileHelper module).
* Refactored the average_question_score method by using sql summation to find values for sum_of_scores and number_of_scores variables in AssignmentParticipant model.

==Models==

===User===
The user model stores details of the user like name,email,role,timezone and his preferences on how expertiza should behave to him. A user can have many roles like student, instructor or administrator. The user model is used for logging in, participating in courses, assignments and creating teams. The user model maintains parent child relationship, a user will have one parent and can have many children.

===Assignment Participant===
Expertiza uses a participant abstraction for modeling the participance of a user in any of the activities like courses and assignments. A participant belongs to a user and it represents a connection between a user and an activity. Assignment_participant, which is a child class of participant models the association between users and assignments. This association also needs to be mapped to other activities performed by a user related to the assignment. These activities include reviews, quiz, response to reviews, teammate reviews etc.. The assignment_participant model is related to models which is responsible for all the mentioned activities.

===Course Participant===
The course_participant is a child class of the participant abstraction and it represents the association between a user and a course. The model also stores fields required for the association and supports bulk importing and exporting.

==Changes==

===Refactoring: Duplicated export_fields method===
This method exports the headers of the csv file to be downloaded. The method export_fields occurs in various models with different implementations. However, the implementation for this method had been duplicated in course_participant and user models. This led to the disadvantage of having redundant code in the system and an inefficient coding practice. User model represents the base class and other models inherit from this class. Hence, deleting the method from User model made little sense. The refactoring invoked the User models export_fields method from within the export_fields of course_participant. Since the export_file controller calls this method on the course_participant object, there wasn't a choice to delete the method completely. This refactoring has the advantage that code is reused and the proper object is tied to the header fields instead of just the generic User object.

===Refactoring: Breaking get_user_list method===
This method contained a lot of if-else statements that executed different codes depending on the type of user. The refactoring broke the large method into smaller methods, one for each user type. This improved the modularity of the code. It made the code more manageable and understandable from maintenance point of view (separation of responsibilities).

===Refactoring: Use SQL summation to calculate average_question_score===
The average of the score for a question in the review given by all other students who reviewed an assignment needs to be calculated in the average_question_score method in assignment participant model. This was originally implemented by using two for loops and fetching all the answers given by all the reviewers and then filtering using an if statement. This method consumes more CPU cycles and impacts the performance of the application server. It also consumes more bandwidth since the application fetches all the data from the database but returns only one value to the user. This was reimplemented to use the SQL summation inside the database and returns the only desired value to the application. This method also takes advantage of the database indexing and fetches only values required instead of filtering in the application.

===Refactoring: Add attr_accessible to class to improve security===
The course_participant model has a number of instance variables like can_submit, can_review, user_id, parent_id, submitted_at, permission_granted, penalty_accumulated, grade, type, handle, time_stamp, digital_signature, duty, can_take_quiz. Earlier, these variables were less secure and hence susceptible to tampering with URLs or forms from malicious users. In general, elements are filled based on the data sent as a hash from the view. This happens as mass assignment where any matching key in the hash will be set. To protect this mass assignment from malicious attacks, a good design is to add attr_accessible macro. Adding this keyword to instance variables ensures that only the specified attributes in the list of attr_accessible are allowed for mass assignment. This ensures that developers can carefully consider which attributes should be allowed to do mass assignment. This way, the refactoring is done.
<code>attr_accessible :can_submit, :can_review, :user_id, :parent_id, :submitted_at, :permission_granted, :penalty_accumulated, :grade, :type, :handle, :time_stamp, :digital_signature, :duty, :can_take_quiz</code>

===Refactoring: files method is duplicate and used in assignment_team.rb as well. Move it to either a common place or keep it at the most appropriate place===
This refactoring belongs to AssignmentParticipant model. This model is a special class of Participant and it denotes the participants who have collaborated for a particular Assignment. This method takes a parameter which is a directory and it returns all the files present in that directory. The directory argument is basically a string containing the file path for reviewer uploaded files during peer review. This argument comes from AssignmentParticipant model but the files method as a whole is independent of the model as its function is to return files present in a directory. It does not need to belong to any model. Hence the ‘files’ method must be placed in file_helper.rb. Thus the ‘files’ method is moved from the AssignmentParticipant model to a helper module like file_helper.rb. The design principle that is reinforced here is that a class must have responsibilities that belong to itself and not other “helper” responsibilities. This is an implementation of Separation Of Concerns design principle.

<code>
def files(directory)
files_list = Dir[directory + "/*"]
files = Array.new
files_list.each do |file|
if File.directory?(file)
dir_files = files(file)
dir_files.each{|f| files << f}
end
files << file
end
files
end
</code>

===Refactoring: topic_name in Participant.rb===
In participant.rb model, there is a method topic_name. However, this method doesn't seem to be required here. A course participant cannot have a topic. If it is an assignment participant object, we can find which team that participant is in first, then find which topic is this team holding. In fact, there is a topic_name field in SignedUpTeam class. On thorough investigation, we found that the method has no caller, which is the right implementation in any case. Hence, the refactoring involved deleting this method altogether. The refactoring was verified by the fact that none of the existing test cases failed.

==Testing==
Expertiza mainly uses RSpec for testing and has a comprehensive set of test cases overall. However, there are some models that do not have the required rspecs. We have included test cases for all the refactoring that we have done. We also ensured that the existing test cases do not fail.

===Test adding attr_accessible to class to improve security===
The earlier version of Expertiza did not have an rspec for the CourseParticipant model. We added an rspec named course_participant_spec.rb as the rspec for this model covering tests for the refactorings done in this project. The attr_accessible improves security by allowing only those fields that are in the list of attr_accessible macro for mass assignment. We test this by using “should allow_mass_assignment_of” and “should_not allow_mass_assignment_of”. Those attributes that are not in the list of attr_accessible will pass the test only when tested as “should_not allow_mass_assignment_of” and the attributes that are in the list of attr_accessible will pass the test only when tested as “should allow_mass_assignment_of”. The following is the code snippet of the test case.
<code>
describe "#accessible attributes" do
it { should allow_mass_assignment_of(:can_submit) }
it { should allow_mass_assignment_of(:can_review) }
it { should allow_mass_assignment_of(:user_id) }
it { should allow_mass_assignment_of(:parent_id) }
it { should allow_mass_assignment_of(:submitted_at) }
it { should allow_mass_assignment_of(:permission_granted) }
it { should allow_mass_assignment_of(:penalty_accumulated) }
it { should allow_mass_assignment_of(:grade) }
it { should allow_mass_assignment_of(:type) }
it { should allow_mass_assignment_of(:handle) }
it { should allow_mass_assignment_of(:time_stamp) }
it { should allow_mass_assignment_of(:digital_signature) }
it { should allow_mass_assignment_of(:duty) }
it { should allow_mass_assignment_of(:can_take_quiz) }
end
</code>

===Test the export_fields method===
This refactoring was done in the CourseParticipant model. The duplication is removed and the export_fields method is kept only in the User model and a call to the User model is made from CourseParticipant. To test this method, we test the functionality of this method as there is no test case for this method in the previous version. The export_fields method takes an argument of options which is a list of all the fields that the end user wants to export as course participant data and it returns the corresponding fields by making a call to User model. The ideal test case will test only the export_fields in the course_participant model and not the one in user model. This is in line with the strategy of testing incoming query messages by making assertions about what they send back. Therefore, for a given set of options, only the required right set of fields are to be returned. We expect that the returned list of fields will match the ones the method asked using the options field. Below is a sample test snippet.
<code>
describe "#export_fields" do
it "returns export fields for a csv based on radio buttons checked" do
options = {"personal_details"=>"true", "role"=>"true", "parent"=>"true", "email_options"=>"true", "handle"=>"true"}
fields = ["name", "full name", "email", "role", "parent", "email on submission", "email on review", "email on metareview", "handle"]
expect(CourseParticipant.export_fields(options)).to match_array(fields)
end
</code>

===Test refactoring of get_user_list method into smaller methods===
In order to test get_user_list, we create a dummy object of User and set its role as instructor and fetch the user list of that instructor which returns the list of participants of that instructor’s course. The list could be empty or non empty depending on the user object.
<code>
describe "#get_user_list" do
it 'user list' do
@role = Role.new name: "Instructor"
user1 = User.new name: "instructor4", role: @role
expect(user1.get_user_list).to be_empty
expect(user1.get_users_instructor)
end
end
</code>

===Testing through GUI===
*Login as super_administrator2 with password as "password"
*Click on "Manage..."" and click on "Courses"
*On the "Actions" tab, click on "Add Participants"
*On the page that opens up, go to the bottom and select "Export course participants"
Click on "Export" button and a csv file should download with the selected radio button fields.

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-28T20:04:06Z

Pkulkar5: /* Test the export_fields method */

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-28T19:47:13Z

Pkulkar5: /* Refactoring: files method is duplicate and used in assignment_team.rb as well. Move it to either a common place or keep it at the most appropriate place */

== E1603. Refactor user, course_participant and assignment_participant model ==
This page provides details about the changes made to Expertiza under project E1603. Refactor user, course_participant and assignment_participant model.

==Background==
Expertiza is an educational web application built on top of Ruby on Rails. The project is open source with code available on Github and maintained by both the students and faculty of the NC State University. The application allows instructors to manage courses and assignments. The students can choose a topic from the list for an assignment, form a team, submit their work and do multiple reviews on other's work. The application helps instructors and teaching assistants in scoring and maintaining the grades for the assignment.

==Description==
The users of the expertiza are modeled using the user model. A participant signs up for courses and assignments. A user can have multiple participants and all participants belong to a user. The participant model is inherited by the course and assignment participant model. Our work involves refactoring functions defined in these models. Some methods were moved to places with better fit and some methods were improvised with better implementations. The further sections in the document will explain the changes complement and how it will impact the overall usage of expertiza.

==Tasks accomplished in this project==
* Moved the export_fields method to the User model from CourseParticipant model to remove redudancy.
* Added attr_accessible modifier to CourseParticipant to improve security.
* Refactored the get_user_list method into smaller methods, one method for each if condition in User model.
* Moved the ‘files’ method from AssignmentParticipant model which was duplicate and used in assignment_team.rb as well to a common place (FileHelper module).
* Refactored the average_question_score method by using sql summation to find values for sum_of_scores and number_of_scores variables in AssignmentParticipant model.

==Models==

===User===
The user model stores details of the user like name,email,role,timezone and his preferences on how expertiza should behave to him. A user can have many roles like student, instructor or administrator. The user model is used for logging in, participating in courses, assignments and creating teams. The user model maintains parent child relationship, a user will have one parent and can have many children.

===Assignment Participant===
Expertiza uses a participant abstraction for modeling the participance of a user in any of the activities like courses and assignments. A participant belongs to a user and it represents a connection between a user and an activity. Assignment_participant, which is a child class of participant models the association between users and assignments. This association also needs to be mapped to other activities performed by a user related to the assignment. These activities include reviews, quiz, response to reviews, teammate reviews etc.. The assignment_participant model is related to models which is responsible for all the mentioned activities.

===Course Participant===
The course_participant is a child class of the participant abstraction and it represents the association between a user and a course. The model also stores fields required for the association and supports bulk importing and exporting.

==Changes==

===Refactoring: Duplicated export_fields method===
This method exports the headers of the csv file to be downloaded. The method export_fields occurs in various models with different implementations. However, the implementation for this method had been duplicated in course_participant and user models. This led to the disadvantage of having redundant code in the system and an inefficient coding practice. User model represents the base class and other models inherit from this class. Hence, deleting the method from User model made little sense. The refactoring invoked the User models export_fields method from within the export_fields of course_participant. Since the export_file controller calls this method on the course_participant object, there wasn't a choice to delete the method completely. This refactoring has the advantage that code is reused and the proper object is tied to the header fields instead of just the generic User object.

===Refactoring: Breaking get_user_list method===
This method contained a lot of if-else statements that executed different codes depending on the type of user. The refactoring broke the large method into smaller methods, one for each user type. This improved the modularity of the code. It made the code more manageable and understandable from maintenance point of view (separation of responsibilities).

===Refactoring: Use SQL summation to calculate average_question_score===
The average of the score for a question in the review given by all other students who reviewed an assignment needs to be calculated in the average_question_score method in assignment participant model. This was originally implemented by using two for loops and fetching all the answers given by all the reviewers and then filtering using an if statement. This method consumes more CPU cycles and impacts the performance of the application server. It also consumes more bandwidth since the application fetches all the data from the database but returns only one value to the user. This was reimplemented to use the SQL summation inside the database and returns the only desired value to the application. This method also takes advantage of the database indexing and fetches only values required instead of filtering in the application.

===Refactoring: Add attr_accessible to class to improve security===
The course_participant model has a number of instance variables like can_submit, can_review, user_id, parent_id, submitted_at, permission_granted, penalty_accumulated, grade, type, handle, time_stamp, digital_signature, duty, can_take_quiz. Earlier, these variables were less secure and hence susceptible to tampering with URLs or forms from malicious users. In general, elements are filled based on the data sent as a hash from the view. This happens as mass assignment where any matching key in the hash will be set. To protect this mass assignment from malicious attacks, a good design is to add attr_accessible macro. Adding this keyword to instance variables ensures that only the specified attributes in the list of attr_accessible are allowed for mass assignment. This ensures that developers can carefully consider which attributes should be allowed to do mass assignment. This way, the refactoring is done.
<code>attr_accessible :can_submit, :can_review, :user_id, :parent_id, :submitted_at, :permission_granted, :penalty_accumulated, :grade, :type, :handle, :time_stamp, :digital_signature, :duty, :can_take_quiz</code>

===Refactoring: files method is duplicate and used in assignment_team.rb as well. Move it to either a common place or keep it at the most appropriate place===
This refactoring belongs to AssignmentParticipant model. This model is a special class of Participant and it denotes the participants who have collaborated for a particular Assignment. This method takes a parameter which is a directory and it returns all the files present in that directory. The directory argument is basically a string containing the file path for reviewer uploaded files during peer review. This argument comes from AssignmentParticipant model but the files method as a whole is independent of the model as its function is to return files present in a directory. It does not need to belong to any model. Hence the ‘files’ method must be placed in file_helper.rb. Thus the ‘files’ method is moved from the AssignmentParticipant model to a helper module like file_helper.rb. The design principle that is reinforced here is that a class must have responsibilities that belong to itself and not other “helper” responsibilities. This is an implementation of Separation Of Concerns design principle.

<code>
def files(directory)
files_list = Dir[directory + "/*"]
files = Array.new
files_list.each do |file|
if File.directory?(file)
dir_files = files(file)
dir_files.each{|f| files << f}
end
files << file
end
files
end
</code>

===Refactoring: topic_name in Participant.rb===
In participant.rb model, there is a method topic_name. However, this method doesn't seem to be required here. A course participant cannot have a topic. If it is an assignment participant object, we can find which team that participant is in first, then find which topic is this team holding. In fact, there is a topic_name field in SignedUpTeam class. On thorough investigation, we found that the method has no caller, which is the right implementation in any case. Hence, the refactoring involved deleting this method altogether. The refactoring was verified by the fact that none of the existing test cases failed.

==Testing==
Expertiza mainly uses RSpec for testing and has a comprehensive set of test cases overall. However, there are some models that do not have the required rspecs. We have included test cases for all the refactoring that we have done. We also ensured that the existing test cases do not fail.

===Test adding attr_accessible to class to improve security===
The earlier version of Expertiza did not have an rspec for the CourseParticipant model. We added an rspec named course_participant_spec.rb as the rspec for this model covering tests for the refactorings done in this project. The attr_accessible improves security by allowing only those fields that are in the list of attr_accessible macro for mass assignment. We test this by using “should allow_mass_assignment_of” and “should_not allow_mass_assignment_of”. Those attributes that are not in the list of attr_accessible will pass the test only when tested as “should_not allow_mass_assignment_of” and the attributes that are in the list of attr_accessible will pass the test only when tested as “should allow_mass_assignment_of”. The following is the code snippet of the test case.
<code>
describe "#accessible attributes" do
it { should allow_mass_assignment_of(:can_submit) }
it { should allow_mass_assignment_of(:can_review) }
it { should allow_mass_assignment_of(:user_id) }
it { should allow_mass_assignment_of(:parent_id) }
it { should allow_mass_assignment_of(:submitted_at) }
it { should allow_mass_assignment_of(:permission_granted) }
it { should allow_mass_assignment_of(:penalty_accumulated) }
it { should allow_mass_assignment_of(:grade) }
it { should allow_mass_assignment_of(:type) }
it { should allow_mass_assignment_of(:handle) }
it { should allow_mass_assignment_of(:time_stamp) }
it { should allow_mass_assignment_of(:digital_signature) }
it { should allow_mass_assignment_of(:duty) }
it { should allow_mass_assignment_of(:can_take_quiz) }
end
</code>

===Test the export_fields method===
This refactoring happened in the CourseParticipant model. The duplication is removed and the export_fields method is kept only in the User model and a call to the User model is made from CourseParticipant. To test this method, we test the functionality of this method as there is no test case for this method in the previous version. The export_fields method takes an argument of options which is a list of all the fields that the end user wants to export as course participant data and it returns the corresponding fields by making a call to User model. The ideal test case will tes only the export_fields in the course_participant model and not the one in user model. This is in line with the strategy of testing incoming query messages by making assertions about what they send back. Therefore, for a given set of options, only the required right set of fields are to be returned. We expect that the returned list of fields will match the ones the method asked using the options field. Below is a sample test snippet.
<code>
describe "#export_fields" do
it "returns export fields for a csv based on radio buttons checked" do
options = {"personal_details"=>"true", "role"=>"true", "parent"=>"true", "email_options"=>"true", "handle"=>"true"}
fields = ["name", "full name", "email", "role", "parent", "email on submission", "email on review", "email on metareview", "handle"]
expect(CourseParticipant.export_fields(options)).to match_array(fields)
end
</code>

===Test refactoring of get_user_list method into smaller methods===
In order to test get_user_list, we create a dummy object of User and set its role as instructor and fetch the user list of that instructor which returns the list of participants of that instructor’s course. The list could be empty or non empty depending on the user object.
<code>
describe "#get_user_list" do
it 'user list' do
@role = Role.new name: "Instructor"
user1 = User.new name: "instructor4", role: @role
expect(user1.get_user_list).to be_empty
expect(user1.get_users_instructor)
end
end
</code>

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-28T19:42:13Z

Pkulkar5: /* Refactoring: Use SQL summation to calculate average_question_score */

== E1603. Refactor user, course_participant and assignment_participant model ==
This page provides details about the changes made to Expertiza under project E1603. Refactor user, course_participant and assignment_participant model.

==Background==
Expertiza is an educational web application built on top of Ruby on Rails. The project is open source with code available on Github and maintained by both the students and faculty of the NC State University. The application allows instructors to manage courses and assignments. The students can choose a topic from the list for an assignment, form a team, submit their work and do multiple reviews on other's work. The application helps instructors and teaching assistants in scoring and maintaining the grades for the assignment.

==Description==
The users of the expertiza are modeled using the user model. A participant signs up for courses and assignments. A user can have multiple participants and all participants belong to a user. The participant model is inherited by the course and assignment participant model. Our work involves refactoring functions defined in these models. Some methods were moved to places with better fit and some methods were improvised with better implementations. The further sections in the document will explain the changes complement and how it will impact the overall usage of expertiza.

==Tasks accomplished in this project==
* Moved the export_fields method to the User model from CourseParticipant model to remove redudancy.
* Added attr_accessible modifier to CourseParticipant to improve security.
* Refactored the get_user_list method into smaller methods, one method for each if condition in User model.
* Moved the ‘files’ method from AssignmentParticipant model which was duplicate and used in assignment_team.rb as well to a common place (FileHelper module).
* Refactored the average_question_score method by using sql summation to find values for sum_of_scores and number_of_scores variables in AssignmentParticipant model.

==Models==

===User===
The user model stores details of the user like name,email,role,timezone and his preferences on how expertiza should behave to him. A user can have many roles like student, instructor or administrator. The user model is used for logging in, participating in courses, assignments and creating teams. The user model maintains parent child relationship, a user will have one parent and can have many children.

===Assignment Participant===
Expertiza uses a participant abstraction for modeling the participance of a user in any of the activities like courses and assignments. A participant belongs to a user and it represents a connection between a user and an activity. Assignment_participant, which is a child class of participant models the association between users and assignments. This association also needs to be mapped to other activities performed by a user related to the assignment. These activities include reviews, quiz, response to reviews, teammate reviews etc.. The assignment_participant model is related to models which is responsible for all the mentioned activities.

===Course Participant===
The course_participant is a child class of the participant abstraction and it represents the association between a user and a course. The model also stores fields required for the association and supports bulk importing and exporting.

==Changes==

===Refactoring: Duplicated export_fields method===
This method exports the headers of the csv file to be downloaded. The method export_fields occurs in various models with different implementations. However, the implementation for this method had been duplicated in course_participant and user models. This led to the disadvantage of having redundant code in the system and an inefficient coding practice. User model represents the base class and other models inherit from this class. Hence, deleting the method from User model made little sense. The refactoring invoked the User models export_fields method from within the export_fields of course_participant. Since the export_file controller calls this method on the course_participant object, there wasn't a choice to delete the method completely. This refactoring has the advantage that code is reused and the proper object is tied to the header fields instead of just the generic User object.

===Refactoring: Breaking get_user_list method===
This method contained a lot of if-else statements that executed different codes depending on the type of user. The refactoring broke the large method into smaller methods, one for each user type. This improved the modularity of the code. It made the code more manageable and understandable from maintenance point of view (separation of responsibilities).

===Refactoring: Use SQL summation to calculate average_question_score===
The average of the score for a question in the review given by all other students who reviewed an assignment needs to be calculated in the average_question_score method in assignment participant model. This was originally implemented by using two for loops and fetching all the answers given by all the reviewers and then filtering using an if statement. This method consumes more CPU cycles and impacts the performance of the application server. It also consumes more bandwidth since the application fetches all the data from the database but returns only one value to the user. This was reimplemented to use the SQL summation inside the database and returns the only desired value to the application. This method also takes advantage of the database indexing and fetches only values required instead of filtering in the application.

===Refactoring: Add attr_accessible to class to improve security===
The course_participant model has a number of instance variables like can_submit, can_review, user_id, parent_id, submitted_at, permission_granted, penalty_accumulated, grade, type, handle, time_stamp, digital_signature, duty, can_take_quiz. Earlier, these variables were less secure and hence susceptible to tampering with URLs or forms from malicious users. In general, elements are filled based on the data sent as a hash from the view. This happens as mass assignment where any matching key in the hash will be set. To protect this mass assignment from malicious attacks, a good design is to add attr_accessible macro. Adding this keyword to instance variables ensures that only the specified attributes in the list of attr_accessible are allowed for mass assignment. This ensures that developers can carefully consider which attributes should be allowed to do mass assignment. This way, the refactoring is done.
<code>attr_accessible :can_submit, :can_review, :user_id, :parent_id, :submitted_at, :permission_granted, :penalty_accumulated, :grade, :type, :handle, :time_stamp, :digital_signature, :duty, :can_take_quiz</code>

===Refactoring: files method is duplicate and used in assignment_team.rb as well. Move it to either a common place or keep it at the most appropriate place===
This refactoring belongs to AssignmentParticipant model. This model is a special class of Participant and it denotes the participants who have collaborated for a particular Assignment. This method takes a parameter which is a directory and it returns all the files present in that directory. The directory argument is basically a string containing the file path for reviewer uploaded files during peer review. This argument comes from AssignmentParticipant model but the files method as a whole is independent of the model as its function is to return files present in a directory. It does not need to belong to any model. Hence the ‘files’ method must be placed in file_helper.rb. Thus the ‘files’ method is moved from the AssignmentParticipant model to a helper module like file_helper.rb. The design principle that is reinforced here is that a class must have responsibilities that belong to itself and not other “helper” responsibilities.

<code>
def files(directory)
files_list = Dir[directory + "/*"]
files = Array.new
files_list.each do |file|
if File.directory?(file)
dir_files = files(file)
dir_files.each{|f| files << f}
end
files << file
end
files
end
</code>

===Refactoring: topic_name in Participant.rb===
In participant.rb model, there is a method topic_name. However, this method doesn't seem to be required here. A course participant cannot have a topic. If it is an assignment participant object, we can find which team that participant is in first, then find which topic is this team holding. In fact, there is a topic_name field in SignedUpTeam class. On thorough investigation, we found that the method has no caller, which is the right implementation in any case. Hence, the refactoring involved deleting this method altogether. The refactoring was verified by the fact that none of the existing test cases failed.

==Testing==
Expertiza mainly uses RSpec for testing and has a comprehensive set of test cases overall. However, there are some models that do not have the required rspecs. We have included test cases for all the refactoring that we have done. We also ensured that the existing test cases do not fail.

===Test adding attr_accessible to class to improve security===
The earlier version of Expertiza did not have an rspec for the CourseParticipant model. We added an rspec named course_participant_spec.rb as the rspec for this model covering tests for the refactorings done in this project. The attr_accessible improves security by allowing only those fields that are in the list of attr_accessible macro for mass assignment. We test this by using “should allow_mass_assignment_of” and “should_not allow_mass_assignment_of”. Those attributes that are not in the list of attr_accessible will pass the test only when tested as “should_not allow_mass_assignment_of” and the attributes that are in the list of attr_accessible will pass the test only when tested as “should allow_mass_assignment_of”. The following is the code snippet of the test case.
<code>
describe "#accessible attributes" do
it { should allow_mass_assignment_of(:can_submit) }
it { should allow_mass_assignment_of(:can_review) }
it { should allow_mass_assignment_of(:user_id) }
it { should allow_mass_assignment_of(:parent_id) }
it { should allow_mass_assignment_of(:submitted_at) }
it { should allow_mass_assignment_of(:permission_granted) }
it { should allow_mass_assignment_of(:penalty_accumulated) }
it { should allow_mass_assignment_of(:grade) }
it { should allow_mass_assignment_of(:type) }
it { should allow_mass_assignment_of(:handle) }
it { should allow_mass_assignment_of(:time_stamp) }
it { should allow_mass_assignment_of(:digital_signature) }
it { should allow_mass_assignment_of(:duty) }
it { should allow_mass_assignment_of(:can_take_quiz) }
end
</code>

===Test the export_fields method===
This refactoring happened in the CourseParticipant model. The duplication is removed and the export_fields method is kept only in the User model and a call to the User model is made from CourseParticipant. To test this method, we test the functionality of this method as there is no test case for this method in the previous version. The export_fields method takes an argument of options which is a list of all the fields that the end user wants to export as course participant data and it returns the corresponding fields by making a call to User model. The ideal test case will tes only the export_fields in the course_participant model and not the one in user model. This is in line with the strategy of testing incoming query messages by making assertions about what they send back. Therefore, for a given set of options, only the required right set of fields are to be returned. We expect that the returned list of fields will match the ones the method asked using the options field. Below is a sample test snippet.
<code>
describe "#export_fields" do
it "returns export fields for a csv based on radio buttons checked" do
options = {"personal_details"=>"true", "role"=>"true", "parent"=>"true", "email_options"=>"true", "handle"=>"true"}
fields = ["name", "full name", "email", "role", "parent", "email on submission", "email on review", "email on metareview", "handle"]
expect(CourseParticipant.export_fields(options)).to match_array(fields)
end
</code>

===Test refactoring of get_user_list method into smaller methods===
In order to test get_user_list, we create a dummy object of User and set its role as instructor and fetch the user list of that instructor which returns the list of participants of that instructor’s course. The list could be empty or non empty depending on the user object.
<code>
describe "#get_user_list" do
it 'user list' do
@role = Role.new name: "Instructor"
user1 = User.new name: "instructor4", role: @role
expect(user1.get_user_list).to be_empty
expect(user1.get_users_instructor)
end
end
</code>

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-28T19:35:54Z

Pkulkar5: /* Assignment Participant */

== E1603. Refactor user, course_participant and assignment_participant model ==
This page provides details about the changes made to Expertiza under project E1603. Refactor user, course_participant and assignment_participant model.

==Background==
Expertiza is an educational web application built on top of Ruby on Rails. The project is open source with code available on Github and maintained by both the students and faculty of the NC State University. The application allows instructors to manage courses and assignments. The students can choose a topic from the list for an assignment, form a team, submit their work and do multiple reviews on other's work. The application helps instructors and teaching assistants in scoring and maintaining the grades for the assignment.

==Description==
The users of the expertiza are modeled using the user model. A participant signs up for courses and assignments. A user can have multiple participants and all participants belong to a user. The participant model is inherited by the course and assignment participant model. Our work involves refactoring functions defined in these models. Some methods were moved to places with better fit and some methods were improvised with better implementations. The further sections in the document will explain the changes complement and how it will impact the overall usage of expertiza.

==Tasks accomplished in this project==
* Moved the export_fields method to the User model from CourseParticipant model to remove redudancy.
* Added attr_accessible modifier to CourseParticipant to improve security.
* Refactored the get_user_list method into smaller methods, one method for each if condition in User model.
* Moved the ‘files’ method from AssignmentParticipant model which was duplicate and used in assignment_team.rb as well to a common place (FileHelper module).
* Refactored the average_question_score method by using sql summation to find values for sum_of_scores and number_of_scores variables in AssignmentParticipant model.

==Models==

===User===
The user model stores details of the user like name,email,role,timezone and his preferences on how expertiza should behave to him. A user can have many roles like student, instructor or administrator. The user model is used for logging in, participating in courses, assignments and creating teams. The user model maintains parent child relationship, a user will have one parent and can have many children.

===Assignment Participant===
Expertiza uses a participant abstraction for modeling the participance of a user in any of the activities like courses and assignments. A participant belongs to a user and it represents a connection between a user and an activity. Assignment_participant, which is a child class of participant models the association between users and assignments. This association also needs to be mapped to other activities performed by a user related to the assignment. These activities include reviews, quiz, response to reviews, teammate reviews etc.. The assignment_participant model is related to models which is responsible for all the mentioned activities.

===Course Participant===
The course_participant is a child class of the participant abstraction and it represents the association between a user and a course. The model also stores fields required for the association and supports bulk importing and exporting.

==Changes==

===Refactoring: Duplicated export_fields method===
This method exports the headers of the csv file to be downloaded. The method export_fields occurs in various models with different implementations. However, the implementation for this method had been duplicated in course_participant and user models. This led to the disadvantage of having redundant code in the system and an inefficient coding practice. User model represents the base class and other models inherit from this class. Hence, deleting the method from User model made little sense. The refactoring invoked the User models export_fields method from within the export_fields of course_participant. Since the export_file controller calls this method on the course_participant object, there wasn't a choice to delete the method completely. This refactoring has the advantage that code is reused and the proper object is tied to the header fields instead of just the generic User object.

===Refactoring: Breaking get_user_list method===
This method contained a lot of if-else statements that executed different codes depending on the type of user. The refactoring broke the large method into smaller methods, one for each user type. This improved the modularity of the code. It made the code more manageable and understandable from maintenance point of view (separation of responsibilities).

===Refactoring: Use SQL summation to calculate average_question_score===
The average of the score for a question in the review given by all other students who reviewed an assignment needs to be calculated in the average_question_score method in assignment participant model. This was originally implement by using two for loops and fetching all the answers given by all the reviewers and then filtering using a if statement. This method consumes more CPU cycles and impacts the performance of the application server. It also consumes more bandwidth since the application fetches all the data from the database but returns only one value to the user. This was reimplemented to use the SQL summation inside the database and returns only value to the application. This method also takes advantage of the database indexing and fetches only values required instead of filtering in the application.

===Refactoring: Add attr_accessible to class to improve security===
The course_participant model has a number of instance variables like can_submit, can_review, user_id, parent_id, submitted_at, permission_granted, penalty_accumulated, grade, type, handle, time_stamp, digital_signature, duty, can_take_quiz. Earlier, these variables were less secure and hence susceptible to tampering with URLs or forms from malicious users. In general, elements are filled based on the data sent as a hash from the view. This happens as mass assignment where any matching key in the hash will be set. To protect this mass assignment from malicious attacks, a good design is to add attr_accessible macro. Adding this keyword to instance variables ensures that only the specified attributes in the list of attr_accessible are allowed for mass assignment. This ensures that developers can carefully consider which attributes should be allowed to do mass assignment. This way, the refactoring is done.
<code>attr_accessible :can_submit, :can_review, :user_id, :parent_id, :submitted_at, :permission_granted, :penalty_accumulated, :grade, :type, :handle, :time_stamp, :digital_signature, :duty, :can_take_quiz</code>

===Refactoring: files method is duplicate and used in assignment_team.rb as well. Move it to either a common place or keep it at the most appropriate place===
This refactoring belongs to AssignmentParticipant model. This model is a special class of Participant and it denotes the participants who have collaborated for a particular Assignment. This method takes a parameter which is a directory and it returns all the files present in that directory. The directory argument is basically a string containing the file path for reviewer uploaded files during peer review. This argument comes from AssignmentParticipant model but the files method as a whole is independent of the model as its function is to return files present in a directory. It does not need to belong to any model. Hence the ‘files’ method must be placed in file_helper.rb. Thus the ‘files’ method is moved from the AssignmentParticipant model to a helper module like file_helper.rb. The design principle that is reinforced here is that a class must have responsibilities that belong to itself and not other “helper” responsibilities.

<code>
def files(directory)
files_list = Dir[directory + "/*"]
files = Array.new
files_list.each do |file|
if File.directory?(file)
dir_files = files(file)
dir_files.each{|f| files << f}
end
files << file
end
files
end
</code>

===Refactoring: topic_name in Participant.rb===
In participant.rb model, there is a method topic_name. However, this method doesn't seem to be required here. A course participant cannot have a topic. If it is an assignment participant object, we can find which team that participant is in first, then find which topic is this team holding. In fact, there is a topic_name field in SignedUpTeam class. On thorough investigation, we found that the method has no caller, which is the right implementation in any case. Hence, the refactoring involved deleting this method altogether. The refactoring was verified by the fact that none of the existing test cases failed.

==Testing==
Expertiza mainly uses RSpec for testing and has a comprehensive set of test cases overall. However, there are some models that do not have the required rspecs. We have included test cases for all the refactoring that we have done. We also ensured that the existing test cases do not fail.

===Test adding attr_accessible to class to improve security===
The earlier version of Expertiza did not have an rspec for the CourseParticipant model. We added an rspec named course_participant_spec.rb as the rspec for this model covering tests for the refactorings done in this project. The attr_accessible improves security by allowing only those fields that are in the list of attr_accessible macro for mass assignment. We test this by using “should allow_mass_assignment_of” and “should_not allow_mass_assignment_of”. Those attributes that are not in the list of attr_accessible will pass the test only when tested as “should_not allow_mass_assignment_of” and the attributes that are in the list of attr_accessible will pass the test only when tested as “should allow_mass_assignment_of”. The following is the code snippet of the test case.
<code>
describe "#accessible attributes" do
it { should allow_mass_assignment_of(:can_submit) }
it { should allow_mass_assignment_of(:can_review) }
it { should allow_mass_assignment_of(:user_id) }
it { should allow_mass_assignment_of(:parent_id) }
it { should allow_mass_assignment_of(:submitted_at) }
it { should allow_mass_assignment_of(:permission_granted) }
it { should allow_mass_assignment_of(:penalty_accumulated) }
it { should allow_mass_assignment_of(:grade) }
it { should allow_mass_assignment_of(:type) }
it { should allow_mass_assignment_of(:handle) }
it { should allow_mass_assignment_of(:time_stamp) }
it { should allow_mass_assignment_of(:digital_signature) }
it { should allow_mass_assignment_of(:duty) }
it { should allow_mass_assignment_of(:can_take_quiz) }
end
</code>

===Test the export_fields method===
This refactoring happened in the CourseParticipant model. The duplication is removed and the export_fields method is kept only in the User model and a call to the User model is made from CourseParticipant. To test this method, we test the functionality of this method as there is no test case for this method in the previous version. The export_fields method takes an argument of options which is a list of all the fields that the end user wants to export as course participant data and it returns the corresponding fields by making a call to User model. The ideal test case will tes only the export_fields in the course_participant model and not the one in user model. This is in line with the strategy of testing incoming query messages by making assertions about what they send back. Therefore, for a given set of options, only the required right set of fields are to be returned. We expect that the returned list of fields will match the ones the method asked using the options field. Below is a sample test snippet.
<code>
describe "#export_fields" do
it "returns export fields for a csv based on radio buttons checked" do
options = {"personal_details"=>"true", "role"=>"true", "parent"=>"true", "email_options"=>"true", "handle"=>"true"}
fields = ["name", "full name", "email", "role", "parent", "email on submission", "email on review", "email on metareview", "handle"]
expect(CourseParticipant.export_fields(options)).to match_array(fields)
end
</code>

===Test refactoring of get_user_list method into smaller methods===
In order to test get_user_list, we create a dummy object of User and set its role as instructor and fetch the user list of that instructor which returns the list of participants of that instructor’s course. The list could be empty or non empty depending on the user object.
<code>
describe "#get_user_list" do
it 'user list' do
@role = Role.new name: "Instructor"
user1 = User.new name: "instructor4", role: @role
expect(user1.get_user_list).to be_empty
expect(user1.get_users_instructor)
end
end
</code>

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-24T01:12:13Z

Pkulkar5:

== E1603. Refactor user, course_participant and assignment_participant model ==
This page provides details about the changes made to Expertiza under project E1603. Refactor user, course_participant and assignment_participant model.

==Background==
Expertiza is an educational web application built on top of Ruby on Rails. The project is open source with code available on Github and maintained by both the students and faculty of the NC State University. The application allows instructors to manage courses and assignments. The students can choose a topic from the list for an assignment, form a team, submit their work and do multiple reviews on other's work. The application helps instructors and teaching assistants in scoring and maintaining the grades for the assignment.

==Description==
The users of the expertiza are modeled using the user model. A participant signs up for courses and assignments. A user can have multiple participants and all participants belong to a user. The participant model is inherited by the course and assignment participant model. Our work involves refactoring functions defined in these models. Some methods were moved to places with better fit and some methods were improvised with better implementations. The further sections in the document will explain the changes complement and how it will impact the overall usage of expertiza.

==Tasks accomplished in this project==
* Moved the export_fields method to the User model from CourseParticipant model to remove redudancy.
* Added attr_accessible modifier to CourseParticipant to improve security.
* Refactored the get_user_list method into smaller methods, one method for each if condition in User model.
* Moved the ‘files’ method from AssignmentParticipant model which was duplicate and used in assignment_team.rb as well to a common place (FileHelper module).
* Refactored the average_question_score method by using sql summation to find values for sum_of_scores and number_of_scores variables in AssignmentParticipant model.

==Models==

===User===
The user model stores details of the user like name,email,role,timezone and his preferences on how expertiza should behave to him. A user can have many roles like student, instructor or administrator. The user model is used for logging in, participating in courses, assignments and creating teams. The user model maintains parent child relationship, a user will have one parent and can have many children.

===Assignment Participant===
Expertiza uses an participant abstraction for modeling the participance of a user in any of the activities like courses and assignments. A participant belongs a user and it represents a connection between user and a activity. Assignment_participant, which is a child class of participant models the association between users and assignments. This association also needs to be mapped to other activities performed by a user related to the assignment. These activities include reviews, quiz, response to reviews, teammate reviews etc.. The assignment_participant model is related to models which is responsible for all the mentioned activities.

===Course Participant===
The course_participant is a child class of the participant abstraction and it represents the association between a user and a course. The model also stores fields required for the association and supports bulk importing and exporting.

==Changes==

===Refactoring: Use SQL summation to calculate average_question_score===
The average of the score for a question in the review given by all other students who reviewed an assignment needs to be calculated in the average_question_score method in assignment participant model. This was originally implement by using two for loops and fetching all the answers given by all the reviewers and then filtering using a if statement. This method consumes more CPU cycles and impacts the performance of the application server. It also consumes more bandwidth since the application fetches all the data from the database but returns only one value to the user. This was reimplemented to use the SQL summation inside the database and returns only value to the application. This method also takes advantage of the database indexing and fetches only values required instead of filtering in the application.

===Refactoring: Add attr_accessible to class to improve security===
The course_participant model has a number of instance variables like can_submit, can_review, user_id, parent_id, submitted_at, permission_granted, penalty_accumulated, grade, type, handle, time_stamp, digital_signature, duty, can_take_quiz. Earlier, these variables were less secure and hence susceptible to tampering with URLs or forms from malicious users. In general, elements are filled based on the data sent as a hash from the view. This happens as mass assignment where any matching key in the hash will be set. To protect this mass assignment from malicious attacks, a good design is to add attr_accessible macro. Adding this keyword to instance variables ensures that only the specified attributes in the list of attr_accessible are allowed for mass assignment. This ensures that developers can carefully consider which attributes should be allowed to do mass assignment. This way, the refactoring is done.
<code>attr_accessible :can_submit, :can_review, :user_id, :parent_id, :submitted_at, :permission_granted, :penalty_accumulated, :grade, :type, :handle, :time_stamp, :digital_signature, :duty, :can_take_quiz</code>

===Refactoring: files method is duplicate and used in assignment_team.rb as well. Move it to either a common place or keep it at the most appropriate place===
This refactoring belongs to AssignmentParticipant model. This model is a special class of Participant and it denotes the participants who have collaborated for a particular Assignment. This method takes a parameter which is a directory and it returns all the files present in that directory. The directory argument is basically a string containing the file path for reviewer uploaded files during peer review. This argument comes from AssignmentParticipant model but the files method as a whole is independent of the model as its function is to return files present in a directory. It does not need to belong to any model. Hence the ‘files’ method must be placed in file_helper.rb. Thus the ‘files’ method is moved from the AssignmentParticipant model to a helper module like file_helper.rb. The design principle that is reinforced here is that a class must have responsibilities that belong to itself and not other “helper” responsibilities.

<code>
def files(directory)
files_list = Dir[directory + "/*"]
files = Array.new
files_list.each do |file|
if File.directory?(file)
dir_files = files(file)
dir_files.each{|f| files << f}
end
files << file
end
files
end
</code>

==Testing==
Expertiza mainly uses RSpec for testing and has a comprehensive set of test cases overall. However, there are some models that do not have the required rspecs. We have included test cases for all the refactoring that we have done. We also ensured that the existing test cases do not fail.

===Test adding attr_accessible to class to improve security===
The earlier version of Expertiza did not have an rspec for the CourseParticipant model. We added an rspec named course_participant_spec.rb as the rspec for this model covering tests for the refactorings done in this project. The attr_accessible improves security by allowing only those fields that are in the list of attr_accessible macro for mass assignment. We test this by using “should allow_mass_assignment_of” and “should_not allow_mass_assignment_of”. Those attributes that are not in the list of attr_accessible will pass the test only when tested as “should_not allow_mass_assignment_of” and the attributes that are in the list of attr_accessible will pass the test only when tested as “should allow_mass_assignment_of”. The following is the code snippet of the test case.
<code>
describe "#accessible attributes" do
it { should allow_mass_assignment_of(:can_submit) }
it { should allow_mass_assignment_of(:can_review) }
it { should allow_mass_assignment_of(:user_id) }
it { should allow_mass_assignment_of(:parent_id) }
it { should allow_mass_assignment_of(:submitted_at) }
it { should allow_mass_assignment_of(:permission_granted) }
it { should allow_mass_assignment_of(:penalty_accumulated) }
it { should allow_mass_assignment_of(:grade) }
it { should allow_mass_assignment_of(:type) }
it { should allow_mass_assignment_of(:handle) }
it { should allow_mass_assignment_of(:time_stamp) }
it { should allow_mass_assignment_of(:digital_signature) }
it { should allow_mass_assignment_of(:duty) }
it { should allow_mass_assignment_of(:can_take_quiz) }
end
</code>

===Test the export_fields method===
This refactoring happened in the CourseParticipant model. The duplication is removed and the export_fields method is kept only in the User model and a call to the User model is made from CourseParticipant. To test this method, we test the functionality of this method as there is no test case for this method in the previous version. The export_fields method takes an argument of options which is a list of all the fields that the end user wants to export as course participant data and it returns the corresponding fields by making a call to User model. The ideal test case will tes only the export_fields in the course_participant model and not the one in user model. This is in line with the strategy of testing incoming query messages by making assertions about what they send back. Therefore, for a given set of options, only the required right set of fields are to be returned. We expect that the returned list of fields will match the ones the method asked using the options field. Below is a sample test snippet.
<code>
describe "#export_fields" do
it "returns export fields for a csv based on radio buttons checked" do
options = {"personal_details"=>"true", "role"=>"true", "parent"=>"true", "email_options"=>"true", "handle"=>"true"}
fields = ["name", "full name", "email", "role", "parent", "email on submission", "email on review", "email on metareview", "handle"]
expect(CourseParticipant.export_fields(options)).to match_array(fields)
end
</code>

===Test refactoring of get_user_list method into smaller methods===
In order to test get_user_list, we create a dummy object of User and set its role as instructor and fetch the user list of that instructor which returns the list of participants of that instructor’s course. The list could be empty or non empty depending on the user object.
<code>
describe "#get_user_list" do
it 'user list' do
@role = Role.new name: "Instructor"
user1 = User.new name: "instructor4", role: @role
expect(user1.get_user_list).to be_empty
expect(user1.get_users_instructor)
end
end
</code>

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-24T01:11:55Z

Pkulkar5:

== E1603. Refactor user, course_participant and assignment_participant model ==
This page provides details about the changes made to Expertiza under project E1603. Refactor user, course_participant and assignment_participant model.

==Background==
Expertiza is an educational web application built on top of Ruby on Rails. The project is open source with code available on Github and maintained by both the students and faculty of the NC State University. The application allows instructors to manage courses and assignments. The students can choose a topic from the list for an assignment, form a team, submit their work and do multiple reviews on other's work. The application helps instructors and teaching assistants in scoring and maintaining the grades for the assignment.

==Description==
The users of the expertiza are modeled using the user model. A participant signs up for courses and assignments. A user can have multiple participants and all participants belong to a user. The participant model is inherited by the course and assignment participant model. Our work involves refactoring functions defined in these models. Some methods were moved to places with better fit and some methods were improvised with better implementations. The further sections in the document will explain the changes complement and how it will impact the overall usage of expertiza.

==Tasks accomplished in this project==
* Moved the export_fields method to the User model from CourseParticipant model to remove redudancy.
* Added attr_accessible modifier to CourseParticipant to improve security.
* Refactored the get_user_list method into smaller methods, one method for each if condition in User model.
* Moved the ‘files’ method from AssignmentParticipant model which was duplicate and used in assignment_team.rb as well to a common place (FileHelper module).
* Refactored the average_question_score method by using sql summation to find values for sum_of_scores and number_of_scores variables in AssignmentParticipant model.

==Models==

===User===
The user model stores details of the user like name,email,role,timezone and his preferences on how expertiza should behave to him. A user can have many roles like student, instructor or administrator. The user model is used for logging in, participating in courses, assignments and creating teams. The user model maintains parent child relationship, a user will have one parent and can have many children.

===Assignment Participant===
Expertiza uses an participant abstraction for modeling the participance of a user in any of the activities like courses and assignments. A participant belongs a user and it represents a connection between user and a activity. Assignment_participant, which is a child class of participant models the association between users and assignments. This association also needs to be mapped to other activities performed by a user related to the assignment. These activities include reviews, quiz, response to reviews, teammate reviews etc.. The assignment_participant model is related to models which is responsible for all the mentioned activities.

===Course Participant===
The course_participant is a child class of the participant abstraction and it represents the association between a user and a course. The model also stores fields required for the association and supports bulk importing and exporting.

==Changes==

===Refactoring: Use SQL summation to calculate average_question_score===
The average of the score for a question in the review given by all other students who reviewed an assignment needs to be calculated in the average_question_score method in assignment participant model. This was originally implement by using two for loops and fetching all the answers given by all the reviewers and then filtering using a if statement. This method consumes more CPU cycles and impacts the performance of the application server. It also consumes more bandwidth since the application fetches all the data from the database but returns only one value to the user. This was reimplemented to use the SQL summation inside the database and returns only value to the application. This method also takes advantage of the database indexing and fetches only values required instead of filtering in the application.

===Refactoring: Add attr_accessible to class to improve security===
The course_participant model has a number of instance variables like can_submit, can_review, user_id, parent_id, submitted_at, permission_granted, penalty_accumulated, grade, type, handle, time_stamp, digital_signature, duty, can_take_quiz. Earlier, these variables were less secure and hence susceptible to tampering with URLs or forms from malicious users. In general, elements are filled based on the data sent as a hash from the view. This happens as mass assignment where any matching key in the hash will be set. To protect this mass assignment from malicious attacks, a good design is to add attr_accessible macro. Adding this keyword to instance variables ensures that only the specified attributes in the list of attr_accessible are allowed for mass assignment. This ensures that developers can carefully consider which attributes should be allowed to do mass assignment. This way, the refactoring is done.
<code>attr_accessible :can_submit, :can_review, :user_id, :parent_id, :submitted_at, :permission_granted, :penalty_accumulated, :grade, :type, :handle, :time_stamp, :digital_signature, :duty, :can_take_quiz</code>

===Refactoring: files method is duplicate and used in assignment_team.rb as well. Move it to either a common place or keep it at the most appropriate place===
This refactoring belongs to AssignmentParticipant model. This model is a special class of Participant and it denotes the participants who have collaborated for a particular Assignment. This method takes a parameter which is a directory and it returns all the files present in that directory. The directory argument is basically a string containing the file path for reviewer uploaded files during peer review. This argument comes from AssignmentParticipant model but the files method as a whole is independent of the model as its function is to return files present in a directory. It does not need to belong to any model. Hence the ‘files’ method must be placed in file_helper.rb. Thus the ‘files’ method is moved from the AssignmentParticipant model to a helper module like file_helper.rb. The design principle that is reinforced here is that a class must have responsibilities that belong to itself and not other “helper” responsibilities.

<code>
def files(directory)
files_list = Dir[directory + "/*"]
files = Array.new
files_list.each do |file|
if File.directory?(file)
dir_files = files(file)
dir_files.each{|f| files << f}
end
files << file
end
files
end
</code>

==Testing==
Expertiza mainly uses RSpec for testing and has a comprehensive set of test cases overall. However, there are some models that do not have the required rspecs. We have included test cases for all the refactoring that we have done. We also ensured that the existing test cases do not fail.

===Test adding attr_accessible to class to improve security===
The earlier version of Expertiza did not have an rspec for the CourseParticipant model. We added an rspec named course_participant_spec.rb as the rspec for this model covering tests for the refactorings done in this project. The attr_accessible improves security by allowing only those fields that are in the list of attr_accessible macro for mass assignment. We test this by using “should allow_mass_assignment_of” and “should_not allow_mass_assignment_of”. Those attributes that are not in the list of attr_accessible will pass the test only when tested as “should_not allow_mass_assignment_of” and the attributes that are in the list of attr_accessible will pass the test only when tested as “should allow_mass_assignment_of”. The following is the code snippet of the test case.
<code>
describe "#accessible attributes" do
it { should allow_mass_assignment_of(:can_submit) }
it { should allow_mass_assignment_of(:can_review) }
it { should allow_mass_assignment_of(:user_id) }
it { should allow_mass_assignment_of(:parent_id) }
it { should allow_mass_assignment_of(:submitted_at) }
it { should allow_mass_assignment_of(:permission_granted) }
it { should allow_mass_assignment_of(:penalty_accumulated) }
it { should allow_mass_assignment_of(:grade) }
it { should allow_mass_assignment_of(:type) }
it { should allow_mass_assignment_of(:handle) }
it { should allow_mass_assignment_of(:time_stamp) }
it { should allow_mass_assignment_of(:digital_signature) }
it { should allow_mass_assignment_of(:duty) }
it { should allow_mass_assignment_of(:can_take_quiz) }
end
</code>

===Test the export_fields method===
This refactoring happened in the CourseParticipant model. The duplication is removed and the export_fields method is kept only in the User model and a call to the User model is made from CourseParticipant. To test this method, we test the functionality of this method as there is no test case for this method in the previous version. The export_fields method takes an argument of options which is a list of all the fields that the end user wants to export as course participant data and it returns the corresponding fields by making a call to User model. The ideal test case will tes only the export_fields in the course_participant model and not the one in user model. This is in line with the strategy of testing incoming query messages by making assertions about what they send back. Therefore, for a given set of options, only the required right set of fields are to be returned. We expect that the returned list of fields will match the ones the method asked using the options field. Below is a sample test snippet.
<code>
describe "#export_fields" do
it "returns export fields for a csv based on radio buttons checked" do
options = {"personal_details"=>"true", "role"=>"true", "parent"=>"true", "email_options"=>"true", "handle"=>"true"}
fields = ["name", "full name", "email", "role", "parent", "email on submission", "email on review", "email on metareview", "handle"]
expect(CourseParticipant.export_fields(options)).to match_array(fields)
end
</code>

===Test refactoring of get_user_list method into smaller methods===
In order to test get_user_list, we create a dummy object of User and set its role as instructor and fetch the user list of that instructor which returns the list of participants of that instructor’s course. The list could be empty or non empty depending on the user object.
<code>
describe "#get_user_list" do
it 'user list' do
@role = Role.new name: "Instructor"
user1 = User.new name: "instructor4", role: @role
expect(user1.get_user_list).to be_empty
expect(user1.get_users_instructor)
end
end
</code

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-24T00:42:52Z

Pkulkar5:

== E1603. Refactor user, course_participant and assignment_participant model ==
This page provides details about the changes made to Expertiza under project E1603. Refactor user, course_participant and assignment_participant model.

==Background==
Expertiza is an educational web application built on top of Ruby on Rails. The project is open source with code available on Github and maintained by both the students and faculty of the NC State University. The application allows instructors to manage courses and assignments. The students can choose a topic from the list for an assignment, form a team, submit their work and do multiple reviews on other's work. The application helps instructors and teaching assistants in scoring and maintaining the grades for the assignment.

==Description==
The users of the expertiza are modeled using the user model. A participant signs up for courses and assignments. A user can have multiple participants and all participants belong to a user. The participant model is inherited by the course and assignment participant model. Our work involves refactoring functions defined in these models. Some methods were moved to places with better fit and some methods were improvised with better implementations. The further sections in the document will explain the changes complement and how it will impact the overall usage of expertiza.

==Tasks accomplished in this project==
* Moved the export_fields method to the User model from CourseParticipant model to remove redudancy.
* Added attr_accessible modifier to CourseParticipant to improve security.
* Refactored the get_user_list method into smaller methods, one method for each if condition in User model.
* Moved the ‘files’ method from AssignmentParticipant model which was duplicate and used in assignment_team.rb as well to a common place (FileHelper module).
* Refactored the average_question_score method by using sql summation to find values for sum_of_scores and number_of_scores variables in AssignmentParticipant model.

==Models==

===User===
The user model stores details of the user like name,email,role,timezone and his preferences on how expertiza should behave to him. A user can have many roles like student, instructor or administrator. The user model is used for logging in, participating in courses, assignments and creating teams. The user model maintains parent child relationship, a user will have one parent and can have many children.

===Assignment Participant===
Expertiza uses an participant abstraction for modeling the participance of a user in any of the activities like courses and assignments. A participant belongs a user and it represents a connection between user and a activity. Assignment_participant, which is a child class of participant models the association between users and assignments. This association also needs to be mapped to other activities performed by a user related to the assignment. These activities include reviews, quiz, response to reviews, teammate reviews etc.. The assignment_participant model is related to models which is responsible for all the mentioned activities.

===Course Participant===
The course_participant is a child class of the participant abstraction and it represents the association between a user and a course. The model also stores fields required for the association and supports bulk importing and exporting.

==Changes==

===Refactoring: Use SQL summation to calculate average_question_score===
The average of the score for a question in the review given by all other students who reviewed an assignment needs to be calculated in the average_question_score method in assignment participant model. This was originally implement by using two for loops and fetching all the answers given by all the reviewers and then filtering using a if statement. This method consumes more CPU cycles and impacts the performance of the application server. It also consumes more bandwidth since the application fetches all the data from the database but returns only one value to the user. This was reimplemented to use the SQL summation inside the database and returns only value to the application. This method also takes advantage of the database indexing and fetches only values required instead of filtering in the application.

===Refactoring: Add attr_accessible to class to improve security===
The course_participant model has a number of instance variables like can_submit, can_review, user_id, parent_id, submitted_at, permission_granted, penalty_accumulated, grade, type, handle, time_stamp, digital_signature, duty, can_take_quiz. Earlier, these variables were less secure and hence susceptible to tampering with URLs or forms from malicious users. In general, elements are filled based on the data sent as a hash from the view. This happens as mass assignment where any matching key in the hash will be set. To protect this mass assignment from malicious attacks, a good design is to add attr_accessible macro. Adding this keyword to instance variables ensures that only the specified attributes in the list of attr_accessible are allowed for mass assignment. This ensures that developers can carefully consider which attributes should be allowed to do mass assignment. This way, the refactoring is done.
<code>attr_accessible :can_submit, :can_review, :user_id, :parent_id, :submitted_at, :permission_granted, :penalty_accumulated, :grade, :type, :handle, :time_stamp, :digital_signature, :duty, :can_take_quiz</code>

===Refactoring: files method is duplicate and used in assignment_team.rb as well. Move it to either a common place or keep it at the most appropriate place===
This refactoring belongs to AssignmentParticipant model. This model is a special class of Participant and it denotes the participants who have collaborated for a particular Assignment. This method takes a parameter which is a directory and it returns all the files present in that directory. The directory argument is basically a string containing the file path for reviewer uploaded files during peer review. This argument comes from AssignmentParticipant model but the files method as a whole is independent of the model as its function is to return files present in a directory. It does not need to belong to any model. Hence the ‘files’ method must be placed in file_helper.rb. Thus the ‘files’ method is moved from the AssignmentParticipant model to a helper module like file_helper.rb. The design principle that is reinforced here is that a class must have responsibilities that belong to itself and not other “helper” responsibilities.

<code>
def files(directory)
files_list = Dir[directory + "/*"]
files = Array.new
files_list.each do |file|
if File.directory?(file)
dir_files = files(file)
dir_files.each{|f| files << f}
end
files << file
end
files
end
</code>

==Testing==
Expertiza mainly uses RSpec for testing and has a comprehensive set of test cases overall. However, there are some models that do not have the required rspecs. We have included test cases for all the refactoring that we have done. We also ensured that the existing test cases do not fail.

===Test adding attr_accessible to class to improve security===
The earlier version of Expertiza did not have an rspec for the CourseParticipant model. We added an rspec named course_participant_spec.rb as the rspec for this model covering tests for the refactorings done in this project. The attr_accessible improves security by allowing only those fields that are in the list of attr_accessible macro for mass assignment. We test this by using “should allow_mass_assignment_of” and “should_not allow_mass_assignment_of”. Those attributes that are not in the list of attr_accessible will pass the test only when tested as “should_not allow_mass_assignment_of” and the attributes that are in the list of attr_accessible will pass the test only when tested as “should allow_mass_assignment_of”. The following is the code snippet of the test case.
<code>
describe "#accessible attributes" do
it { should allow_mass_assignment_of(:can_submit) }
it { should allow_mass_assignment_of(:can_review) }
it { should allow_mass_assignment_of(:user_id) }
it { should allow_mass_assignment_of(:parent_id) }
it { should allow_mass_assignment_of(:submitted_at) }
it { should allow_mass_assignment_of(:permission_granted) }
it { should allow_mass_assignment_of(:penalty_accumulated) }
it { should allow_mass_assignment_of(:grade) }
it { should allow_mass_assignment_of(:type) }
it { should allow_mass_assignment_of(:handle) }
it { should allow_mass_assignment_of(:time_stamp) }
it { should allow_mass_assignment_of(:digital_signature) }
it { should allow_mass_assignment_of(:duty) }
it { should allow_mass_assignment_of(:can_take_quiz) }
end
</code>

===Test the export_fields method===
This refactoring happened in the CourseParticipant model. The duplication is removed and the export_fields method is kept only in the User model and a call to the User model is made from CourseParticipant. To test this method, we test the functionality of this method as there is no test case for this method in the previous version. The export_fields method takes an argument of options which is a list of all the fields that the end user wants to export as course participant data and it returns the corresponding fields by making a call to User model. The ideal test case will tes only the export_fields in the course_participant model and not the one in user model. This is in line with the strategy of testing incoming query messages by making assertions about what they send back. Therefore, for a given set of options, only the required right set of fields are to be returned. We expect that the returned list of fields will match the ones the method asked using the options field. Below is a sample test snippet.
<code>
describe "#export_fields" do
it "returns export fields for a csv based on radio buttons checked" do
options = {"personal_details"=>"true", "role"=>"true", "parent"=>"true", "email_options"=>"true", "handle"=>"true"}
fields = ["name", "full name", "email", "role", "parent", "email on submission", "email on review", "email on metareview", "handle"]
expect(CourseParticipant.export_fields(options)).to match_array(fields)
end
</code>

===Test refactoring of get_user_list method into smaller methods===
In order to test get_user_list, we create a dummy object of User and set its role as instructor and fetch the user list of that instructor which returns the list of participants of that instructor’s course. The list could be empty or non empty depending on the user object.
<code>
describe "#get_user_list" do
it 'user list' do
@role = Role.new name: "Instructor"
user1 = User.new name: "instructor4", role: @role
expect(user1.get_user_list).to be_empty
expect(user1.get_users_instructor)
end
end
</code>

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-24T00:34:35Z

Pkulkar5: /* Changes */

File:Course participant.png

2016-03-24T00:27:12Z

Pkulkar5: Course participant model

Course participant model

CSC/ECE 517 Spring 2016/Refactor user course participant and assignment participant model

2016-03-24T00:15:23Z

Pkulkar5: /* Tasks identified */