Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T04:01:23Z

Sbastik: /* Step 2: */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
==='''Step 1:'''===
The first step includes building Servo.

==='''Step 2:'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.

= Steps to execute our program =
*The first step is to install Rust in your machine. Steps can be found at <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
*The next step is to build Servo. Steps can be found at <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
<br><br>
[[File:Building servo fin.png]]
*Our implementation files are “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs errorevent.rs]” and “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl errorevent.webidl]”.
*Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
*Build servo again
<pre>
./mach build
</pre>
*We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:59:16Z

Sbastik: /* Step 2 */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
=='''Step 1'''==
The first step includes building Servo.

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
*Check if it works using this command:

= Steps to execute our program =
*The first step is to install Rust in your machine. Steps can be found at <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
*The next step is to build Servo. Steps can be found at <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
<br><br>
[[File:Building servo fin.png]]
*Our implementation files are “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs errorevent.rs]” and “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl errorevent.webidl]”.
*Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
*Build servo again
<pre>
./mach build
</pre>
*We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:59:03Z

Sbastik: /* Step 1 */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
=='''Step 1'''==
The first step includes building Servo.

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

= Steps to execute our program =
*The first step is to install Rust in your machine. Steps can be found at <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
*The next step is to build Servo. Steps can be found at <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
<br><br>
[[File:Building servo fin.png]]
*Our implementation files are “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs errorevent.rs]” and “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl errorevent.webidl]”.
*Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
*Build servo again
<pre>
./mach build
</pre>
*We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:55:41Z

Sbastik: /* Steps to execute our program */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

= Steps to execute our program =
*The first step is to install Rust in your machine. Steps can be found on <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
*The next step is to build Servo. Steps can be found on <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
[[File:Building servo fin.png]]
*Our implementation files are “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs errorevent.rs]” and “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl errorevent.webidl]”.
*Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
*Build servo again
<pre>
./mach build
</pre>
*We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:54:55Z

Sbastik: /* Steps to execute our program */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

= Steps to execute our program =
*The first step is to install Rust in your machine. Steps can be found on <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
*The next step is to build Servo. Steps can be found on <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
[[File:Building servo fin.png]]
*Our implementation files are “errorevent.rs” and “errorevent.webidl”.
*Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
*Build servo again
<pre>
./mach build
</pre>
*We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:54:12Z

Sbastik:

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

= Steps to execute our program =
1.The first step is to install Rust in your machine. Steps can be found on <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
2.The next step is to build Servo. Steps can be found on <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
[[File:Building servo fin.png]]
3.Our implementation files are “errorevent.rs” and “errorevent.webidl”.
4.Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
5.Build servo again
<pre>
./mach build
</pre>
6.We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:53:41Z

Sbastik: /* Implementation Steps */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

Steps to execute our program:
1.The first step is to install Rust in your machine. Steps can be found on <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
2.The next step is to build Servo. Steps can be found on <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
[[File:Building servo fin.png]]
3.Our implementation files are “errorevent.rs” and “errorevent.webidl”.
4.Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
5.Build servo again
<pre>
./mach build
</pre>
6.We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:52:03Z

Sbastik:

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

Steps to execute our program:
1.The first step is to install Rust in your machine. Steps can be found on <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
2.The next step is to build Servo. Steps can be found on <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
[[File:Build servo fin.png]]
3.Our implementation files are “errorevent.rs” and “errorevent.webidl”.
4.Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
5.Build servo again
<pre>
./mach build
</pre>
6.We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:48:21Z

Sbastik:

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:38:53Z

Sbastik: /* Implementation Steps */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to components/script/dom/webidls
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
<br>
<br>
[[File:Building servo fin.png]]
<br>
<br>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:38:18Z

Sbastik: /* Step 2 */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file 'errorevent.webidl' along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to components/script/dom/webidls
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
<br>
<br>
[[File:Building servo fin.png]]
<br>
<br>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:36:42Z

Sbastik: /* Step 2 */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

= RUST Programming Language =

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

= Servo =

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file 'errorevent.webidl' along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/tree/master/components/script/dom/webidls 'errorevent.webidl'] and add it to components/script/dom/webidls
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
<br>
<br>
[[File:Building servo fin.png]]
<br>
<br>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:34:54Z

Sbastik: /* Implementation Steps */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

= RUST Programming Language =

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

= Servo =

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file 'errorevent.webidl' along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file 'errorevent.webidl' and add it to components/script/dom/webidls
*Create the 'errorevent.rs' file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
<br>
<br>
[[File:Building servo fin.png]]
<br>
<br>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:34:03Z

Sbastik: /* Servo */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

= RUST Programming Language =

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

= Servo =

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file 'errorevent.webidl' and add it to components/script/dom/webidls
*Create the 'errorevent.rs' file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
<br>
<br>
[[File:Building servo fin.png]]
<br>
<br>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:33:12Z

Sbastik: /* Introduction */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

= RUST Programming Language =

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

= Servo =

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file 'errorevent.webidl' and add it to components/script/dom/webidls
*Create the 'errorevent.rs' file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
<br>
<br>
[[File:Building servo fin.png]]
<br>
<br>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:31:47Z

Sbastik: /* RUST Programming Language */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

= RUST Programming Language =

Servo is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

= Servo =

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file 'errorevent.webidl' and add it to components/script/dom/webidls
*Create the 'errorevent.rs' file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
<br>
<br>
[[File:Building servo fin.png]]
<br>
<br>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:14:20Z

Sbastik: /* Implementation Steps */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

== Introduction ==
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file 'errorevent.webidl' and add it to components/script/dom/webidls
*Create the 'errorevent.rs' file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png|frame|center|alt = Building Servo|Step to build servo]]
[[File:Building servo fin.png|frame|center|alt = Building Servo|After Building Servo]]
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png|frame|center|alt = Running servo|After running servo]]

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:13:43Z

Sbastik: /* Step 2 */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

== Introduction ==
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file 'errorevent.webidl' and add it to components/script/dom/webidls
*Create the 'errorevent.rs' file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png|frame|center|alt = Building Servo|Step to build servo]]
[[File:Building servo fin.png|frame|center|alt = Building Servo|After Building Servo]]
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png|frame|center|alt = Running servo|After running servo]]

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:12:47Z

Sbastik: /* Servo */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

== Introduction ==
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png|frame|center|alt = Building Servo|Step to build servo]]
[[File:Building servo fin.png|frame|center|alt = Building Servo|After Building Servo]]
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png|frame|center|alt = Running servo|After running servo]]

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

File:Servo arch.png

2014-10-29T03:11:44Z

Sbastik:

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:08:58Z

Sbastik: /* Steps to execute our program */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

== Introduction ==
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png|frame|center|alt = Building Servo|Step to build servo]]
[[File:Building servo fin.png|frame|center|alt = Building Servo|After Building Servo]]
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png|frame|center|alt = Running servo|After running servo]]

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:06:40Z

Sbastik: /* Steps to execute our program */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

== Introduction ==
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:Building servo.png|frame|center|alt = Building Servo|Step to build servo]]

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:06:19Z

Sbastik: /* Steps to execute our program */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

== Introduction ==
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:Building servo.png|frame|left|alt = Building Servo|Step to build servo]]

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

File:After running program.png

2014-10-29T03:03:49Z

Sbastik:

File:Building servo fin.png

2014-10-29T03:03:33Z

Sbastik:

File:Building servo.png

2014-10-29T03:03:22Z

Sbastik:

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:01:01Z

Sbastik: /* Project Description */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:00:23Z

Sbastik: /* Project Description */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:59:59Z

Sbastik: /* Project Description */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:58:57Z

Sbastik: /* RUST Programming Language */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST programming language.
* The file on compilation generates erroreventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
:*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
:*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
:*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
:*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
:*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

:*'''Simple''': We have tried to not complicate the code but keep it simple.
:*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
:*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
:*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:58:28Z

Sbastik: /* RUST Programming Language */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
:* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
:* We were required to write a errorevent.rs file, which is written in RUST programming language.
:* The file on compilation generates erroreventBinding.rs file
:* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
:*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
:*We were required to write a errorevent.rs file, which is written in RUST programming language.
:*The file on compilation generates erroreventBinding.rs file
:*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
:*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
:*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
:*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
:*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
:*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

:*'''Simple''': We have tried to not complicate the code but keep it simple.
:*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
:*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
:*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:57:16Z

Sbastik: /* Introduction */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo is written in RUST programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
:* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
:* We were required to write a errorevent.rs file, which is written in RUST programming language.
:* The file on compilation generates erroreventBinding.rs file
:* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
:*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
:*We were required to write a errorevent.rs file, which is written in RUST programming language.
:*The file on compilation generates erroreventBinding.rs file
:*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
:*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
:*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
:*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
:*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
:*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

:*'''Simple''': We have tried to not complicate the code but keep it simple.
:*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
:*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
:*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:55:45Z

Sbastik: /* Introduction */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo is written in RUST programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
:* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
:* We were required to write a errorevent.rs file, which is written in RUST programming language.
:* The file on compilation generates erroreventBinding.rs file
:* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
:*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
:*We were required to write a errorevent.rs file, which is written in RUST programming language.
:*The file on compilation generates erroreventBinding.rs file
:*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
:*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
:*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
:*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
:*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
:*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

:*'''Simple''': We have tried to not complicate the code but keep it simple.
:*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
:*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
:*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:54:46Z

Sbastik: /* Steps to execute our program */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo is written in RUST programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
:* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
:* We were required to write a errorevent.rs file, which is written in RUST programming language.
:* The file on compilation generates erroreventBinding.rs file
:* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
:*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
:*We were required to write a errorevent.rs file, which is written in RUST programming language.
:*The file on compilation generates erroreventBinding.rs file
:*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
:*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
:*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
:*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
:*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
:*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

:*'''Simple''': We have tried to not complicate the code but keep it simple.
:*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
:*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
:*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:53:42Z

Sbastik: /* Implementation Steps */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo is written in RUST programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
:* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
:* We were required to write a errorevent.rs file, which is written in RUST programming language.
:* The file on compilation generates erroreventBinding.rs file
:* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
:*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
:*We were required to write a errorevent.rs file, which is written in RUST programming language.
:*The file on compilation generates erroreventBinding.rs file
:*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1''':===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2''':===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
:*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
:*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
:*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
:*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
:*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
== Design Principles ==

:*'''Simple''': We have tried to not complicate the code but keep it simple.
:*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
:*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
:*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:52:33Z

Sbastik: /* Step 2: */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo is written in RUST programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==

== Implementation Steps ==

== Steps to execute our program ==
==='''Step 1''':===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2''':===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
:*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
:*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
:*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
:*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
:*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
== Design Principles ==

:*'''Simple''': We have tried to not complicate the code but keep it simple.
:*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
:*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
:*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:52:12Z

Sbastik: /* Step 2: */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo is written in RUST programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==

== Implementation Steps ==

== Steps to execute our program ==
==='''Step 1''':===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2''':===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
:*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
:*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
:*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
:*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
:*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html

== Design Principles ==

:*'''Simple''': We have tried to not complicate the code but keep it simple.
:*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
:*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
:*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:49:57Z

Sbastik: /* Step 1: */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo is written in RUST programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==

== Implementation Steps ==

== Steps to execute our program ==
==='''Step 1''':===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2''':===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
:*Create a new file ‘errorevent.webild’ and add it to components/script/dom/webidls
:*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
:*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
:*Build servo and fix any compile errors in the implementation.

== Design Principles ==

:*'''Simple''': We have tried to not complicate the code but keep it simple.
:*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
:*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
:*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:49:04Z

Sbastik: /* Steps to execute our program */

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:46:19Z

Sbastik: /* Design Principles */

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:45:33Z

Sbastik: /* Design Principles */

CSC/ECE 517 Fall 2014

2014-10-28T02:45:53Z

Sbastik:

*[[CSC/ECE_517_Fall_2014/sample_page]]
*[[CSC/ECE_517_Fall_2014/ch1a 22 as]]
*[[CSC/ECE 517 Fall 2014/ch1a 19 mx]]
*[[CSC/ECE 517 Fall 2014/ch1a 3 zq]]
*[[CSC/ECE 517 Fall 2014/ch1a 4 lf]]
*[[CSC/ECE 517 Fall 2014/ch1a 4 wl]]
*[[CSC/ECE 517 Fall 2014/ch1a a7 ch]]
*[[CSC/ECE 517 Fall 2014/ch1a 25 rs]]
*[[CSC/ECE 517 Fall 2014/ch1a 25 jf]]
*[[CSC/ECE 517 Fall 2014/ch1a 8 os]]
*[[CSC/ECE 517 Fall 2014/ch1a 8 sn]]
*[[CSC/ECE 517 Fall 2014/ch1a 15 gs]]
*[[CSC/ECE 517 Fall 2014/ch1a 10 hu]]
*[[CSC/ECE 517 Fall 2014/ch1a 20 kv]]
*[[CSC/ECE 517 Fall 2014/ch1a 21 as]]
*[[CSC/ECE 517 Fall 2014/ch1a 24 sa]]
*[[CSC/ECE 517 Fall 2014/ch1a 26 sn]]
*[[CSC/ECE 517 Fall 2014/ch1a 6 rl]]
*[[CSC/ECE 517 Fall 2014/ch1a 2 ss]]
*[[CSC/ECE 517 Fall 2014/ch1a 16 av]]
*[[CSC/ECE 517 Fall 2014/ch1a 1 rm]]
*[[CSC/ECE 517 Fall 2014/ch1a 1 sj]]
*[[CSC/ECE 517 Fall 2014/ch1a 23 ss]]
*[[CSC/ECE 517 Fall 2014/ch1a 20 rn]]
*[[CSC/ECE 517 Fall 2014/ch1a 22 sp]]
*[[CSC/ECE 517 Fall 2014/oss M1454 rss]]

*[[CSC/ECE 517 Fall 2014/ch1a 26 gn]]

*[[CSC/ECE 517 Fall 2014/ch1a 13 va]]
*[[CSC/ECE 517 Fall 2014/ch1a 9 aa]]
*[[CSC/ECE 517 Fall 2014/ch1a 9 kn]]
*[[CSC/ECE 517 Fall 2014/ch1a 11 ap]]
*[[CSC/ECE 517 Fall 2014/ch1a 25 ks]]
*[[CSC/ECE 517 Fall 2014/ch1a 7 kz]]
*[[CSC/ECE_517_Fall_2014/ch1a_6_bn]]
*[[CSC/ECE_517_Fall_2014/ch1a 10 zz]]
*[[CSC/ECE_517_Fall_2014/ch1a 16 va]]
*[[CSC/ECE_517_Fall_2014/ch1a F1415 rv]]
*[[CSC/ECE_517_Fall_2014/ch1a_3_cp]]
*[[CSC/ECE 517 Fall 2014/ch1b 26 sa]]
*[[CSC/ECE_517_Fall_2014/ch1b_28_cg]]
*[[CSC/ECE_517_Fall_2014/ch1b 29 ry]]
*[[CSC/ECE_517_Fall_2014/ch1b 30 cs]]
*[[CSC/ECE_517_Fall_2014/ch1b_33_jy]]
*[[CSC/ECE_517_Fall_2014/ch1b_27_js]]
*[[CSC/ECE 517 Fall 2014/oss E1465 oak]]
*[[CSC/ECE 517 Fall 2014/oss_M1456_kdv]]
*[[CSC/ECE 517 Fall 2014/oss_M1453_sst]]
*[[CSC/ECE 517 Fall 2014/oss_E1456_akk]]
*[[CSC/ECE_517_Fall_2014/oss_M1455_asa]]
*[[CSC/ECE_517_Fall_2014/oss_E1458_sst]]
*[[CSC/ECE_517_Fall_2014/oss_E1457_ags]]
*[[CSC/ECE_517_Fall_2014/OSS_E1466_gjf]]
*[[CSC/ECE_517_Fall_2014/oss_M1452_jns]]
*[[CSC/ECE_517_Fall_2014/oss_E1462_nms]]
*[[CSC/ECE_517_Fall_2014/OSS_S1455_ajp]]

CSC/ECE 517 Fall 2014/ch1a 8 sn

2014-09-19T23:56:15Z

Sbastik: /* Other Frameworks */

== '''Django Framework''' ==

Django<ref>https://www.djangoproject.com/</ref><ref>http://www.djangobook.com/en/2.0/index.html</ref>(2005) is a high level, but heavy, open source Python<ref>http://www.python.org/</ref> web framework used to build a large scale web application. Django is named after Django Reinhardt, a gypsy jazz guitarist from the 1930s to early 1950s. A web framework is necessary to help the developers and the testers to develop highly scalable and efficient large scale web applications. Django deals with the most important problem in the domain of Web development – repetition. Even though web development is a really interesting task, there are a lot of things that require unnecessary efforts and time of the developers as well as the testers. With an MVT<ref>http://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names</ref> (Model View Template) Framework, Django is very modular and thus very much suitable for highly cohesive<ref>http://en.wikipedia.org/wiki/Cohesion_(computer_science)</ref> and low coupling<ref> http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref> tasks.

__TOC__

== '''History''' ==
In 1998, Python CGI<ref>http://en.wikipedia.org/wiki/CGI</ref> was used to develop web applications from scratch using Python. In order to create a web application using Python CGI, we just have to create a Python script that generates output in the HTML format. We then save the script to a Web server with a <code>“.cgi”</code> extension and visit the page in our Web browser. Following is the sample way of creating a simple website using the script.

<pre>
#!/usr/bin/env python
import MySQLdb
print "Content-Type: text/html\n"
print "<html><head><title>Food items</title></head>"
print "<body>"
print "<h1>Food items</h1>"
print "<ul>"
connection = MySQLdb.connect(user='username', passwd='password', db='food_db')
cursor = connection.cursor()
cursor.execute("SELECT food_item_name FROM food_table ORDER BY rating DESC LIMIT 10")
for row in cursor.fetchall():
print "<li>%s</li>" % row[0]
print "</ul>"
print "</body></html>"
connection.close()
</pre>

The above script generates an HTML page which will display a list of all the food items in the descending order of their rating by interacting with the corresponding table in the database.

Even though the code has several advantages such as making a website (with only one page) from the scratch is not difficult. The code is readable and understandable to all audiences, etc. But this approach has a lot of disadvantages. The disadvantages include repetition of code (such as database connection, authentication, etc.) for a multi-page web application. Also, if discrete entities, like databases with different configuration, are to be included in the project then we will have to rewrite and reconfigure all the pages in the web application. Thus, using CGI for web application development makes it inefficient to build and deploy.

Almost all of the problems posed by Python CGI scripting mentioned above were solved by Django. Django provided a programming infrastructure for large scale web applications, so that the developers can focus on writing clean, maintainable code without worrying about the different aspects of Project Scaffolding<ref>http://en.wikipedia.org/wiki/Scaffold_(programming)</ref>. Based on the DRY<ref>http://en.wikipedia.org/wiki/Don't_repeat_yourself</ref>(Don’t Repeat Yourself) principle, Django aims at reducing repetitive pieces of information of all kinds in software development. Django also supports pluggability of different applications into the web applications that you are developing.

Also, Major websites such as [http://pinterest.com Pinterest], [http://instagram.com Instagram] were developed using Django.

=== Other Frameworks ===
:*Flask<ref>http://flask.pocoo.org/</ref>: It is a web framework that only provides the important and skeletal libraries required for basic web-development. Features such as data abstraction, unlike Django, is not provided by Flask.
:*Pyramid<ref>http://www.pylonsproject.org/projects/pyramid/about</ref>: It is a web framework which strictly follows MVC pattern. It has an additional feature, unlike Django, of maintaining a dictionary of View-to-URL-Mapping.
:*Ruby on Rails<ref>http://rubyonrails.org/</ref>It is a framework which strictly follows MVC pattern. It follows the Don't Repeat Yourself(DRY) and Convention over Configuration(CoC)<ref>http://en.wikipedia.org/wiki/Convention_over_configuration</ref> principle.
:*web2py<ref>http://www.web2py.com/init/default/what</ref>: It is a web framework which follows the convention of Ruby on Rails.

== '''Architecture''' ==

[[File:Django_layers.png|frame|right|alt = MVT Architecture|Django's Model-View-Template Achitecture]]

Most of the web frameworks- such as Ruby on Rails framework- are based on the MVC pattern. MVC, which stands for Model View Controller, is a pattern which provides loose coupling among different parts of the application. In MVC Pattern, Model deals with the direct interaction with the databases. Views deal with the representation of the data on the browser. Controller deals with the user interactions and redirecting each of the user interactions to the respective module responsible for dealing with it.

On the other hand, Django framework does not really fit into the MVC framework. As mentioned earlier, it follows the MTV framework which stands for (Model Template View) Framework. Controller corresponds to the View in Django Framework. In case of the Views in Django, it plays the role of the controller. It fetches the data and decides how the data is to be displayed.

===Applications===

In Django terminology, an installation of Django is considered as a “Project”.

The smallest logical subset of files/folders that is fairly independent from the rest of the project can be called as an application. These subset of files include (but are not limited to) models, views, templates, static files, URLs, etc. A single Django project can have multiple applications, each of which contains the files that define an application.

All the applications that must be included inside the main project should be explicitly mentioned inside the variable <code>INSTALLED_APPS</code> inside the <code>settings.py</code>.

<pre>INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'books'
)</pre>

=== Models ===

In Django, a model is defined as the single source for all the data. It defines how data is accessed, processed and validated. It also contains the structure and relationship of all the data that is used by the application. Models are used to define the structure of your database. Each model is converted into a database table and each attribute inside a model is converted into a column of that table. All this is handled by Django implicitly.

Consider the following example about an application called ‘books’ that contains:
:*Author: which has a first_name and last_name attributes
:*Book: which has title, author and publication date as its attributes

We can write models for the above application like:

<pre>class Author(models.Model):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=40)

class Book(models.Model):
title = models.CharField(max_length=100)
authors = models.ManyToManyField(Author)
publication_date = models.DateField()
</pre>

Once all the models for your application have been created, you can validate them by using:
<pre>python manage.py validate <app_name></pre>
Django also dynamically generates “Create Table” statements for each of these models. These statement can be viewed using the command:
<pre>python manage.py sqlall <app_name></pre>
The above command would give the following output:
<pre>BEGIN;
CREATE TABLE "books_author" (
"id" serial NOT NULL PRIMARY KEY,
"first_name" varchar(30) NOT NULL,
"last_name" varchar(40) NOT NULL,
)
;
CREATE TABLE "books_book" (
"id" serial NOT NULL PRIMARY KEY,
"title" varchar(100) NOT NULL,
"publication_date" date NOT NULL
)
;
CREATE TABLE "books_book_authors" (
"id" serial NOT NULL PRIMARY KEY,
"book_id" integer NOT NULL REFERENCES "books_book" ("id") DEFERRABLE INITIALLY DEFERRED,
"author_id" integer NOT NULL REFERENCES "books_author" ("id") DEFERRABLE INITIALLY DEFERRED,
UNIQUE ("book_id", "author_id")
)
;
COMMIT;
</pre>
and all the tables would be created immediately as soon as you run the command stated below:
<pre>python manage.py syncdb</pre>

=== Views ===
The front-end of the web-application is equally important as the model and the controllers. The basic function of the view is to accept an HTTP request and send a response. Basically Django has two types of views – Generic Views & Class based views. Generic views just take one parameter – “request”. Following is the format of the code to display Hello World.

<pre>
from django.http import HttpResponse
def hello_world(request)
return HttpResponse(“hello world”)
</pre>

Here, the method class hello_world has a parameter called “request”. This is the parameter that contains all the information of the HttpRequest. After the request has been processed, the HttpResponse object is returned back. This HttpResponse object is initialized with the string “hello world”.

Generic views mostly consist of functions. Maintaining a program with a lot of functions is difficult. This reduces the modularity of the program. In order to support classes, Class based views were introduced. Class based views consist of classes which handle all the functionality in the front end. Classes are extensible and hence reusable. We can inherit different views(classes) and include it in our class. For example, if we want to include a view which displays the contacts, we will write the following code.

<pre>from django.views.generic import ListView
from books.models import contacts
class ContactsList(ListView)
model = contacts
</pre>

In the above program, we have imported the ListView from the generic module. As we want to display the contacts from the database, we have imported the database “contacts”. The class ContactsList inherits the ListView class and extracts all the functionality in that class. The “contacts” database is imported and assigned to the model so as to display the contacts in the form of a list view.

Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function.
Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function. In order to do that, we will have to write the following code:
<pre>
from django.conf.urls.defaults import patterns, include, url
from hellworldproject.views import hello
urlpatterns = patterns(‘’. url(r’hello_world/$, hello_world)
</pre>

In the above code, the “pattern” function saves the required URL pattern in the “urlpatters” attribute.
So, after everything is set up, we run our web application with a url say <code>[web-address]/hello_world/</code>. Now, Django first goes to the <code>settings.py</code> file in the project directory and searches for the files which handles the URLConf part. Suppose the name of the files is <code>urls.py</code>. It dives into the urls.py files and linearly matches the requested url with the url patterns in the file and checks which method call is responsible to handle the request. After that, when it finds the method(here, hello_world), it passes an HttpRequest object to the method. After the required processing the request, it creates an HttpResponse object and then continues with the further processes the response by converting it into HTML code by adding the necessary formatting to the response in order for it to be displayed as a view on the screen.

=== Templates ===
In Django, templates are generally used to define how webpages of the application are supposed to look like. Template defines the structure of the webpage and also has additional elements that help access variables, run python statements and much more.

Data can be passed to templates which can be used by the templates to display to the user or perform actions on the data and create dynamic views based on the data.

==== Variables ====
We can access any data passed to the templates and use them as regular python variables. The below lines of code shows how variables can be accessed:
<pre>Author: {{author.last_name}}, {{ author.first_name }}</pre>
which will just print the author’s name on the webpage.

==== Tags ====
Templates also provide the ability to write python code inside them and execute them just like they would run inside a <code>“.py”</code> file. These elements are known as tags and look like <code>{% tag %}</code>

Given below is the example of a “for” loop that is defined inside a template:
<pre>{% for book in books_list %}
<li>{{ book.title }}</li>
{% endfor %}</pre>

You can process data (though it is not logical to do so in a template), write conditional statements or just declare variables inside tags and used them later in the template file.

==== Filters ====
Filters in templates can be defined as helper functions. They are a very powerful tool that reduces the code needed for basic (or sometimes even complex) post-processing of data.

For example, the title of a book could be added to your application as one of ‘HARRY POTTER’, ‘HaRrY pOtTeR’ or ‘harry potter’. To standardize the format of the book title which you want to show on your website, we can simply write
<pre>{{book.title|title }}</pre>
which capitalizes the first character of each word and turn all other characters to lower.

Django also provide the ability to write custom filters and make it available to all the templates in your application. Django provides template tags and filters to control internationalization in templates. They allow for granular control of translations, formatting, and time zone conversions.

=== Admin Site ===
For a certain class of Web sites, an admin interface is an essential part of the infrastructure.

This is a Web-based interface, limited to trusted site administrators, that enables the adding, editing and deletion of site content. So the admin site has to authenticate users, display and handle forms, validate input, and so on. But the best part about Django is that it does all of this and more for you – in just a few of lines of code. This is also one of the reasons why Django is called a “heavy” web development framework.

To access the Django admin interface, we just have to add <code>/admin</code> to your project url.

[[File:Admin01.png|frame|center|alt = This is the login page of Django Admin Site|Django Admin site login page]]

We would also have to create a superuser, which can be done by following the steps given below.
<pre>$ python manage.py createsuperuser</pre>
Enter the admin username and email address:
<pre>Username: admin
Email address: admin@example.com</pre>
Choose the password for the admin account:
<pre>
Password: **********
Password (again): *********
Superuser created successfully.</pre>

[[File:Admin02.png|frame|center|alt = The default first page of the admin site|Default admin site home page]]

Django contains a file called <code>admin.py</code> where you can define models for the admin site and then enable them so that they will appear on the admin site.
Using the example of the Author Model described in the sections above, let us add it to the admin site:
<pre>
class AuthorAdmin(admin.ModelAdmin):
pass

admin.site.register(Author);
</pre>

These out-of-the-box features of the Django framework is what makes it the perfect option for creating content driven websites in relatively no time at all.

== '''Features''' ==
Django has the following features to name a few:
:*It facilitates developers with a template comprising minimal number of classes, modules, packages etc. so that the developers can focus more on the core business logic.
:*It contains an ORM (Object-Relational Mapper) that allows for the use of standard Python language. The developers need not learn any query processing language.
:*It provides with a template framework suitable for making the views.
:*It supports pluggability – that is it supports including other installed applications into your own application.
:*It has a built in administrative interface to manage the web application from an administrative level, thus providing access control.
:*It is multi-lingual
:*It supports a very useful Geographical web framework "GeoDjango"<ref>https://docs.djangoproject.com/en/1.6/ref/contrib/gis/</ref>

== '''Comparison with other web frameworks''' ==
=== Django vs Ruby on Rails ===
Most of the differences lie in the way the MVC pattern is interpreted by both the frameworks.<ref>https://bernardopires.com/2014/03/rails-vs-django-an-in-depth-technical-comparison/</ref>

==== Models:====
Everything in Ruby on Rails is based on migrations. If at any point of time, the schema of the database is changed and if it has to be reverted back to the previous schema then we can do that with the help of migrations. In case of Django, we need to depend on a third-party extension “South” (until Django 1.6) to support migrations.

==== Controllers: ====
Django considers the entire framework as the controller but Ruby on Rails has a separate entity called controllers that manage the task of interpreting the user interactions and routing to the correct method that handles the request. That is why Django is said to follow the MVT(Model View Template) framework and Ruby on Rails strictly follows MVC framework.

==== Views: ====
In Django, the amount of code that can be pushed into the views(i.e., the template) part of the application is very stringent. Only basic codes like conditional statements and simple loops are allowed. As the controller objects are not really accessible in the views, not much of the manipulation can be done in the views section of the application. This enforces a strict modularity between the models, views and templates section in the Django application making the application maintenance easier. In case of Rails, as the controller objects are accessible in the views as well, a lot of unnecessary calculations can be included in the views. This reduces modularity in the application. Thus, Django has an upper hand over Rails for this reason.

==== Other Features ====
Django has in-built features like User authentication and admin support in its web applications. This makes developing admin based web application very easy. There is no such thing in Rails as such.

=== Django vs Web2py ===

Web2py is inspired by Ruby on Rails. It supports Convention over Configuration just like Ruby on Rails. The administrative interface can be accessed from the browser for web2py. But, for Django, the developer has to manually configure everything.<ref>http://www.web2py.com/init/default/what</ref>
====Models====
Django doesn’t support migrations by itself(until 1.6). web2py supports database migrations. Also, many to many references between the tables are represented in a different way in Django and web2py. Django creates an intermediate link table whereas web2py includes the references as fields in the table.

====Controllers====
Web2py manages all the imports, and other things related to project scaffolding by itself. The developer just has to focus on the application development unlike Django wherein the user has to take care of all the imports in the code.

====Views====
If a view is undefined, then Django throws an error. But in case of web2py, it searches for mycontroller/index.html in the myapp. If that file is not present, then it creates a generic view which contains the raw response in a dictionary format on the browser.

====Other features====
One feature, Transactions, is supported by both Django and web2py. But the way transaction “commits” are executed is different. Django has two options “auto-commit” and “commit_on_success”. But in case of web2py, it by default commits if the transaction is success and doesn’t commit in case of failure of the transaction.

== References ==
<references/>

CSC/ECE 517 Fall 2014/ch1a 8 sn

2014-09-19T23:53:10Z

Sbastik: /* Other Frameworks */

== '''Django Framework''' ==

Django<ref>https://www.djangoproject.com/</ref><ref>http://www.djangobook.com/en/2.0/index.html</ref>(2005) is a high level, but heavy, open source Python<ref>http://www.python.org/</ref> web framework used to build a large scale web application. Django is named after Django Reinhardt, a gypsy jazz guitarist from the 1930s to early 1950s. A web framework is necessary to help the developers and the testers to develop highly scalable and efficient large scale web applications. Django deals with the most important problem in the domain of Web development – repetition. Even though web development is a really interesting task, there are a lot of things that require unnecessary efforts and time of the developers as well as the testers. With an MVT<ref>http://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names</ref> (Model View Template) Framework, Django is very modular and thus very much suitable for highly cohesive<ref>http://en.wikipedia.org/wiki/Cohesion_(computer_science)</ref> and low coupling<ref> http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref> tasks.

__TOC__

== '''History''' ==
In 1998, Python CGI<ref>http://en.wikipedia.org/wiki/CGI</ref> was used to develop web applications from scratch using Python. In order to create a web application using Python CGI, we just have to create a Python script that generates output in the HTML format. We then save the script to a Web server with a <code>“.cgi”</code> extension and visit the page in our Web browser. Following is the sample way of creating a simple website using the script.

<pre>
#!/usr/bin/env python
import MySQLdb
print "Content-Type: text/html\n"
print "<html><head><title>Food items</title></head>"
print "<body>"
print "<h1>Food items</h1>"
print "<ul>"
connection = MySQLdb.connect(user='username', passwd='password', db='food_db')
cursor = connection.cursor()
cursor.execute("SELECT food_item_name FROM food_table ORDER BY rating DESC LIMIT 10")
for row in cursor.fetchall():
print "<li>%s</li>" % row[0]
print "</ul>"
print "</body></html>"
connection.close()
</pre>

The above script generates an HTML page which will display a list of all the food items in the descending order of their rating by interacting with the corresponding table in the database.

Even though the code has several advantages such as making a website (with only one page) from the scratch is not difficult. The code is readable and understandable to all audiences, etc. But this approach has a lot of disadvantages. The disadvantages include repetition of code (such as database connection, authentication, etc.) for a multi-page web application. Also, if discrete entities, like databases with different configuration, are to be included in the project then we will have to rewrite and reconfigure all the pages in the web application. Thus, using CGI for web application development makes it inefficient to build and deploy.

Almost all of the problems posed by Python CGI scripting mentioned above were solved by Django. Django provided a programming infrastructure for large scale web applications, so that the developers can focus on writing clean, maintainable code without worrying about the different aspects of Project Scaffolding<ref>http://en.wikipedia.org/wiki/Scaffold_(programming)</ref>. Based on the DRY<ref>http://en.wikipedia.org/wiki/Don't_repeat_yourself</ref>(Don’t Repeat Yourself) principle, Django aims at reducing repetitive pieces of information of all kinds in software development. Django also supports pluggability of different applications into the web applications that you are developing.

Also, Major websites such as [http://pinterest.com Pinterest], [http://instagram.com Instagram] were developed using Django.

=== Other Frameworks ===
:*Flask<ref>http://flask.pocoo.org/</ref>: It is a web framework that only provides the important and skeletal libraries required for basic web-development. Features such as data abstraction, unlike Django, is not provided by Flask.
:*Pyramid<ref>http://www.pylonsproject.org/projects/pyramid/about</ref>: It is a web framework which strictly follows MVC pattern. It has an additional feature, unlike Django, of maintaining a dictionary of View-to-URL-Mapping.
:*Ruby on Rails<ref>http://rubyonrails.org/</ref>It is a framework which strictly follows MVC pattern. It follows the Don't Repeat Yourself(DRY) and Convention over Configuration(CoC) principle.
:*web2py<ref>http://www.web2py.com/init/default/what</ref>: It is a web framework which follows the convention of Ruby on Rails.

== '''Architecture''' ==

[[File:Django_layers.png|frame|right|alt = MVT Architecture|Django's Model-View-Template Achitecture]]

Most of the web frameworks- such as Ruby on Rails framework- are based on the MVC pattern. MVC, which stands for Model View Controller, is a pattern which provides loose coupling among different parts of the application. In MVC Pattern, Model deals with the direct interaction with the databases. Views deal with the representation of the data on the browser. Controller deals with the user interactions and redirecting each of the user interactions to the respective module responsible for dealing with it.

On the other hand, Django framework does not really fit into the MVC framework. As mentioned earlier, it follows the MTV framework which stands for (Model Template View) Framework. Controller corresponds to the View in Django Framework. In case of the Views in Django, it plays the role of the controller. It fetches the data and decides how the data is to be displayed.

===Applications===

In Django terminology, an installation of Django is considered as a “Project”.

The smallest logical subset of files/folders that is fairly independent from the rest of the project can be called as an application. These subset of files include (but are not limited to) models, views, templates, static files, URLs, etc. A single Django project can have multiple applications, each of which contains the files that define an application.

All the applications that must be included inside the main project should be explicitly mentioned inside the variable <code>INSTALLED_APPS</code> inside the <code>settings.py</code>.

<pre>INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'books'
)</pre>

=== Models ===

In Django, a model is defined as the single source for all the data. It defines how data is accessed, processed and validated. It also contains the structure and relationship of all the data that is used by the application. Models are used to define the structure of your database. Each model is converted into a database table and each attribute inside a model is converted into a column of that table. All this is handled by Django implicitly.

Consider the following example about an application called ‘books’ that contains:
:*Author: which has a first_name and last_name attributes
:*Book: which has title, author and publication date as its attributes

We can write models for the above application like:

<pre>class Author(models.Model):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=40)

class Book(models.Model):
title = models.CharField(max_length=100)
authors = models.ManyToManyField(Author)
publication_date = models.DateField()
</pre>

Once all the models for your application have been created, you can validate them by using:
<pre>python manage.py validate <app_name></pre>
Django also dynamically generates “Create Table” statements for each of these models. These statement can be viewed using the command:
<pre>python manage.py sqlall <app_name></pre>
The above command would give the following output:
<pre>BEGIN;
CREATE TABLE "books_author" (
"id" serial NOT NULL PRIMARY KEY,
"first_name" varchar(30) NOT NULL,
"last_name" varchar(40) NOT NULL,
)
;
CREATE TABLE "books_book" (
"id" serial NOT NULL PRIMARY KEY,
"title" varchar(100) NOT NULL,
"publication_date" date NOT NULL
)
;
CREATE TABLE "books_book_authors" (
"id" serial NOT NULL PRIMARY KEY,
"book_id" integer NOT NULL REFERENCES "books_book" ("id") DEFERRABLE INITIALLY DEFERRED,
"author_id" integer NOT NULL REFERENCES "books_author" ("id") DEFERRABLE INITIALLY DEFERRED,
UNIQUE ("book_id", "author_id")
)
;
COMMIT;
</pre>
and all the tables would be created immediately as soon as you run the command stated below:
<pre>python manage.py syncdb</pre>

=== Views ===
The front-end of the web-application is equally important as the model and the controllers. The basic function of the view is to accept an HTTP request and send a response. Basically Django has two types of views – Generic Views & Class based views. Generic views just take one parameter – “request”. Following is the format of the code to display Hello World.

<pre>
from django.http import HttpResponse
def hello_world(request)
return HttpResponse(“hello world”)
</pre>

Here, the method class hello_world has a parameter called “request”. This is the parameter that contains all the information of the HttpRequest. After the request has been processed, the HttpResponse object is returned back. This HttpResponse object is initialized with the string “hello world”.

Generic views mostly consist of functions. Maintaining a program with a lot of functions is difficult. This reduces the modularity of the program. In order to support classes, Class based views were introduced. Class based views consist of classes which handle all the functionality in the front end. Classes are extensible and hence reusable. We can inherit different views(classes) and include it in our class. For example, if we want to include a view which displays the contacts, we will write the following code.

<pre>from django.views.generic import ListView
from books.models import contacts
class ContactsList(ListView)
model = contacts
</pre>

In the above program, we have imported the ListView from the generic module. As we want to display the contacts from the database, we have imported the database “contacts”. The class ContactsList inherits the ListView class and extracts all the functionality in that class. The “contacts” database is imported and assigned to the model so as to display the contacts in the form of a list view.

Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function.
Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function. In order to do that, we will have to write the following code:
<pre>
from django.conf.urls.defaults import patterns, include, url
from hellworldproject.views import hello
urlpatterns = patterns(‘’. url(r’hello_world/$, hello_world)
</pre>

In the above code, the “pattern” function saves the required URL pattern in the “urlpatters” attribute.
So, after everything is set up, we run our web application with a url say <code>[web-address]/hello_world/</code>. Now, Django first goes to the <code>settings.py</code> file in the project directory and searches for the files which handles the URLConf part. Suppose the name of the files is <code>urls.py</code>. It dives into the urls.py files and linearly matches the requested url with the url patterns in the file and checks which method call is responsible to handle the request. After that, when it finds the method(here, hello_world), it passes an HttpRequest object to the method. After the required processing the request, it creates an HttpResponse object and then continues with the further processes the response by converting it into HTML code by adding the necessary formatting to the response in order for it to be displayed as a view on the screen.

=== Templates ===
In Django, templates are generally used to define how webpages of the application are supposed to look like. Template defines the structure of the webpage and also has additional elements that help access variables, run python statements and much more.

Data can be passed to templates which can be used by the templates to display to the user or perform actions on the data and create dynamic views based on the data.

==== Variables ====
We can access any data passed to the templates and use them as regular python variables. The below lines of code shows how variables can be accessed:
<pre>Author: {{author.last_name}}, {{ author.first_name }}</pre>
which will just print the author’s name on the webpage.

==== Tags ====
Templates also provide the ability to write python code inside them and execute them just like they would run inside a <code>“.py”</code> file. These elements are known as tags and look like <code>{% tag %}</code>

Given below is the example of a “for” loop that is defined inside a template:
<pre>{% for book in books_list %}
<li>{{ book.title }}</li>
{% endfor %}</pre>

You can process data (though it is not logical to do so in a template), write conditional statements or just declare variables inside tags and used them later in the template file.

==== Filters ====
Filters in templates can be defined as helper functions. They are a very powerful tool that reduces the code needed for basic (or sometimes even complex) post-processing of data.

For example, the title of a book could be added to your application as one of ‘HARRY POTTER’, ‘HaRrY pOtTeR’ or ‘harry potter’. To standardize the format of the book title which you want to show on your website, we can simply write
<pre>{{book.title|title }}</pre>
which capitalizes the first character of each word and turn all other characters to lower.

Django also provide the ability to write custom filters and make it available to all the templates in your application. Django provides template tags and filters to control internationalization in templates. They allow for granular control of translations, formatting, and time zone conversions.

=== Admin Site ===
For a certain class of Web sites, an admin interface is an essential part of the infrastructure.

This is a Web-based interface, limited to trusted site administrators, that enables the adding, editing and deletion of site content. So the admin site has to authenticate users, display and handle forms, validate input, and so on. But the best part about Django is that it does all of this and more for you – in just a few of lines of code. This is also one of the reasons why Django is called a “heavy” web development framework.

To access the Django admin interface, we just have to add <code>/admin</code> to your project url.

[[File:Admin01.png|frame|center|alt = This is the login page of Django Admin Site|Django Admin site login page]]

We would also have to create a superuser, which can be done by following the steps given below.
<pre>$ python manage.py createsuperuser</pre>
Enter the admin username and email address:
<pre>Username: admin
Email address: admin@example.com</pre>
Choose the password for the admin account:
<pre>
Password: **********
Password (again): *********
Superuser created successfully.</pre>

[[File:Admin02.png|frame|center|alt = The default first page of the admin site|Default admin site home page]]

Django contains a file called <code>admin.py</code> where you can define models for the admin site and then enable them so that they will appear on the admin site.
Using the example of the Author Model described in the sections above, let us add it to the admin site:
<pre>
class AuthorAdmin(admin.ModelAdmin):
pass

admin.site.register(Author);
</pre>

These out-of-the-box features of the Django framework is what makes it the perfect option for creating content driven websites in relatively no time at all.

== '''Features''' ==
Django has the following features to name a few:
:*It facilitates developers with a template comprising minimal number of classes, modules, packages etc. so that the developers can focus more on the core business logic.
:*It contains an ORM (Object-Relational Mapper) that allows for the use of standard Python language. The developers need not learn any query processing language.
:*It provides with a template framework suitable for making the views.
:*It supports pluggability – that is it supports including other installed applications into your own application.
:*It has a built in administrative interface to manage the web application from an administrative level, thus providing access control.
:*It is multi-lingual
:*It supports a very useful Geographical web framework "GeoDjango"<ref>https://docs.djangoproject.com/en/1.6/ref/contrib/gis/</ref>

== '''Comparison with other web frameworks''' ==
=== Django vs Ruby on Rails ===
Most of the differences lie in the way the MVC pattern is interpreted by both the frameworks.<ref>https://bernardopires.com/2014/03/rails-vs-django-an-in-depth-technical-comparison/</ref>

==== Models:====
Everything in Ruby on Rails is based on migrations. If at any point of time, the schema of the database is changed and if it has to be reverted back to the previous schema then we can do that with the help of migrations. In case of Django, we need to depend on a third-party extension “South” (until Django 1.6) to support migrations.

==== Controllers: ====
Django considers the entire framework as the controller but Ruby on Rails has a separate entity called controllers that manage the task of interpreting the user interactions and routing to the correct method that handles the request. That is why Django is said to follow the MVT(Model View Template) framework and Ruby on Rails strictly follows MVC framework.

==== Views: ====
In Django, the amount of code that can be pushed into the views(i.e., the template) part of the application is very stringent. Only basic codes like conditional statements and simple loops are allowed. As the controller objects are not really accessible in the views, not much of the manipulation can be done in the views section of the application. This enforces a strict modularity between the models, views and templates section in the Django application making the application maintenance easier. In case of Rails, as the controller objects are accessible in the views as well, a lot of unnecessary calculations can be included in the views. This reduces modularity in the application. Thus, Django has an upper hand over Rails for this reason.

==== Other Features ====
Django has in-built features like User authentication and admin support in its web applications. This makes developing admin based web application very easy. There is no such thing in Rails as such.

=== Django vs Web2py ===

Web2py is inspired by Ruby on Rails. It supports Convention over Configuration just like Ruby on Rails. The administrative interface can be accessed from the browser for web2py. But, for Django, the developer has to manually configure everything.<ref>http://www.web2py.com/init/default/what</ref>
====Models====
Django doesn’t support migrations by itself(until 1.6). web2py supports database migrations. Also, many to many references between the tables are represented in a different way in Django and web2py. Django creates an intermediate link table whereas web2py includes the references as fields in the table.

====Controllers====
Web2py manages all the imports, and other things related to project scaffolding by itself. The developer just has to focus on the application development unlike Django wherein the user has to take care of all the imports in the code.

====Views====
If a view is undefined, then Django throws an error. But in case of web2py, it searches for mycontroller/index.html in the myapp. If that file is not present, then it creates a generic view which contains the raw response in a dictionary format on the browser.

====Other features====
One feature, Transactions, is supported by both Django and web2py. But the way transaction “commits” are executed is different. Django has two options “auto-commit” and “commit_on_success”. But in case of web2py, it by default commits if the transaction is success and doesn’t commit in case of failure of the transaction.

== References ==
<references/>

CSC/ECE 517 Fall 2014/ch1a 8 sn

2014-09-19T23:50:56Z

Sbastik: /* Comparison with other web frameworks */

== '''Django Framework''' ==

Django<ref>https://www.djangoproject.com/</ref><ref>http://www.djangobook.com/en/2.0/index.html</ref>(2005) is a high level, but heavy, open source Python<ref>http://www.python.org/</ref> web framework used to build a large scale web application. Django is named after Django Reinhardt, a gypsy jazz guitarist from the 1930s to early 1950s. A web framework is necessary to help the developers and the testers to develop highly scalable and efficient large scale web applications. Django deals with the most important problem in the domain of Web development – repetition. Even though web development is a really interesting task, there are a lot of things that require unnecessary efforts and time of the developers as well as the testers. With an MVT<ref>http://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names</ref> (Model View Template) Framework, Django is very modular and thus very much suitable for highly cohesive<ref>http://en.wikipedia.org/wiki/Cohesion_(computer_science)</ref> and low coupling<ref> http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref> tasks.

__TOC__

== '''History''' ==
In 1998, Python CGI<ref>http://en.wikipedia.org/wiki/CGI</ref> was used to develop web applications from scratch using Python. In order to create a web application using Python CGI, we just have to create a Python script that generates output in the HTML format. We then save the script to a Web server with a <code>“.cgi”</code> extension and visit the page in our Web browser. Following is the sample way of creating a simple website using the script.

<pre>
#!/usr/bin/env python
import MySQLdb
print "Content-Type: text/html\n"
print "<html><head><title>Food items</title></head>"
print "<body>"
print "<h1>Food items</h1>"
print "<ul>"
connection = MySQLdb.connect(user='username', passwd='password', db='food_db')
cursor = connection.cursor()
cursor.execute("SELECT food_item_name FROM food_table ORDER BY rating DESC LIMIT 10")
for row in cursor.fetchall():
print "<li>%s</li>" % row[0]
print "</ul>"
print "</body></html>"
connection.close()
</pre>

The above script generates an HTML page which will display a list of all the food items in the descending order of their rating by interacting with the corresponding table in the database.

Even though the code has several advantages such as making a website (with only one page) from the scratch is not difficult. The code is readable and understandable to all audiences, etc. But this approach has a lot of disadvantages. The disadvantages include repetition of code (such as database connection, authentication, etc.) for a multi-page web application. Also, if discrete entities, like databases with different configuration, are to be included in the project then we will have to rewrite and reconfigure all the pages in the web application. Thus, using CGI for web application development makes it inefficient to build and deploy.

Almost all of the problems posed by Python CGI scripting mentioned above were solved by Django. Django provided a programming infrastructure for large scale web applications, so that the developers can focus on writing clean, maintainable code without worrying about the different aspects of Project Scaffolding<ref>http://en.wikipedia.org/wiki/Scaffold_(programming)</ref>. Based on the DRY<ref>http://en.wikipedia.org/wiki/Don't_repeat_yourself</ref>(Don’t Repeat Yourself) principle, Django aims at reducing repetitive pieces of information of all kinds in software development. Django also supports pluggability of different applications into the web applications that you are developing.

Also, Major websites such as [http://pinterest.com Pinterest], [http://instagram.com Instagram] were developed using Django.

=== Other Frameworks ===
:*Flask<ref>http://flask.pocoo.org/</ref>: It is a web framework that only provides the important and skeletal libraries required for basic web-development. Features such as data abstraction, unlike Django, is not provided by Flask.
:*Pyramid<ref>http://www.pylonsproject.org/projects/pyramid/about</ref>: It is a web framework which strictly follows MVC pattern. It has an additional feature, unlike Django, of maintaining a dictionary of View-to-URL-Mapping.
:*web2py<ref>http://www.web2py.com/init/default/what</ref>: It is a web framework which follows the convention of Ruby on Rails.

== '''Architecture''' ==

[[File:Django_layers.png|frame|right|alt = MVT Architecture|Django's Model-View-Template Achitecture]]

Most of the web frameworks- such as Ruby on Rails framework- are based on the MVC pattern. MVC, which stands for Model View Controller, is a pattern which provides loose coupling among different parts of the application. In MVC Pattern, Model deals with the direct interaction with the databases. Views deal with the representation of the data on the browser. Controller deals with the user interactions and redirecting each of the user interactions to the respective module responsible for dealing with it.

On the other hand, Django framework does not really fit into the MVC framework. As mentioned earlier, it follows the MTV framework which stands for (Model Template View) Framework. Controller corresponds to the View in Django Framework. In case of the Views in Django, it plays the role of the controller. It fetches the data and decides how the data is to be displayed.

===Applications===

In Django terminology, an installation of Django is considered as a “Project”.

The smallest logical subset of files/folders that is fairly independent from the rest of the project can be called as an application. These subset of files include (but are not limited to) models, views, templates, static files, URLs, etc. A single Django project can have multiple applications, each of which contains the files that define an application.

All the applications that must be included inside the main project should be explicitly mentioned inside the variable <code>INSTALLED_APPS</code> inside the <code>settings.py</code>.

<pre>INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'books'
)</pre>

=== Models ===

In Django, a model is defined as the single source for all the data. It defines how data is accessed, processed and validated. It also contains the structure and relationship of all the data that is used by the application. Models are used to define the structure of your database. Each model is converted into a database table and each attribute inside a model is converted into a column of that table. All this is handled by Django implicitly.

Consider the following example about an application called ‘books’ that contains:
:*Author: which has a first_name and last_name attributes
:*Book: which has title, author and publication date as its attributes

We can write models for the above application like:

<pre>class Author(models.Model):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=40)

class Book(models.Model):
title = models.CharField(max_length=100)
authors = models.ManyToManyField(Author)
publication_date = models.DateField()
</pre>

Once all the models for your application have been created, you can validate them by using:
<pre>python manage.py validate <app_name></pre>
Django also dynamically generates “Create Table” statements for each of these models. These statement can be viewed using the command:
<pre>python manage.py sqlall <app_name></pre>
The above command would give the following output:
<pre>BEGIN;
CREATE TABLE "books_author" (
"id" serial NOT NULL PRIMARY KEY,
"first_name" varchar(30) NOT NULL,
"last_name" varchar(40) NOT NULL,
)
;
CREATE TABLE "books_book" (
"id" serial NOT NULL PRIMARY KEY,
"title" varchar(100) NOT NULL,
"publication_date" date NOT NULL
)
;
CREATE TABLE "books_book_authors" (
"id" serial NOT NULL PRIMARY KEY,
"book_id" integer NOT NULL REFERENCES "books_book" ("id") DEFERRABLE INITIALLY DEFERRED,
"author_id" integer NOT NULL REFERENCES "books_author" ("id") DEFERRABLE INITIALLY DEFERRED,
UNIQUE ("book_id", "author_id")
)
;
COMMIT;
</pre>
and all the tables would be created immediately as soon as you run the command stated below:
<pre>python manage.py syncdb</pre>

=== Views ===
The front-end of the web-application is equally important as the model and the controllers. The basic function of the view is to accept an HTTP request and send a response. Basically Django has two types of views – Generic Views & Class based views. Generic views just take one parameter – “request”. Following is the format of the code to display Hello World.

<pre>
from django.http import HttpResponse
def hello_world(request)
return HttpResponse(“hello world”)
</pre>

Here, the method class hello_world has a parameter called “request”. This is the parameter that contains all the information of the HttpRequest. After the request has been processed, the HttpResponse object is returned back. This HttpResponse object is initialized with the string “hello world”.

Generic views mostly consist of functions. Maintaining a program with a lot of functions is difficult. This reduces the modularity of the program. In order to support classes, Class based views were introduced. Class based views consist of classes which handle all the functionality in the front end. Classes are extensible and hence reusable. We can inherit different views(classes) and include it in our class. For example, if we want to include a view which displays the contacts, we will write the following code.

<pre>from django.views.generic import ListView
from books.models import contacts
class ContactsList(ListView)
model = contacts
</pre>

In the above program, we have imported the ListView from the generic module. As we want to display the contacts from the database, we have imported the database “contacts”. The class ContactsList inherits the ListView class and extracts all the functionality in that class. The “contacts” database is imported and assigned to the model so as to display the contacts in the form of a list view.

Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function.
Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function. In order to do that, we will have to write the following code:
<pre>
from django.conf.urls.defaults import patterns, include, url
from hellworldproject.views import hello
urlpatterns = patterns(‘’. url(r’hello_world/$, hello_world)
</pre>

In the above code, the “pattern” function saves the required URL pattern in the “urlpatters” attribute.
So, after everything is set up, we run our web application with a url say <code>[web-address]/hello_world/</code>. Now, Django first goes to the <code>settings.py</code> file in the project directory and searches for the files which handles the URLConf part. Suppose the name of the files is <code>urls.py</code>. It dives into the urls.py files and linearly matches the requested url with the url patterns in the file and checks which method call is responsible to handle the request. After that, when it finds the method(here, hello_world), it passes an HttpRequest object to the method. After the required processing the request, it creates an HttpResponse object and then continues with the further processes the response by converting it into HTML code by adding the necessary formatting to the response in order for it to be displayed as a view on the screen.

=== Templates ===
In Django, templates are generally used to define how webpages of the application are supposed to look like. Template defines the structure of the webpage and also has additional elements that help access variables, run python statements and much more.

Data can be passed to templates which can be used by the templates to display to the user or perform actions on the data and create dynamic views based on the data.

==== Variables ====
We can access any data passed to the templates and use them as regular python variables. The below lines of code shows how variables can be accessed:
<pre>Author: {{author.last_name}}, {{ author.first_name }}</pre>
which will just print the author’s name on the webpage.

==== Tags ====
Templates also provide the ability to write python code inside them and execute them just like they would run inside a <code>“.py”</code> file. These elements are known as tags and look like <code>{% tag %}</code>

Given below is the example of a “for” loop that is defined inside a template:
<pre>{% for book in books_list %}
<li>{{ book.title }}</li>
{% endfor %}</pre>

You can process data (though it is not logical to do so in a template), write conditional statements or just declare variables inside tags and used them later in the template file.

==== Filters ====
Filters in templates can be defined as helper functions. They are a very powerful tool that reduces the code needed for basic (or sometimes even complex) post-processing of data.

For example, the title of a book could be added to your application as one of ‘HARRY POTTER’, ‘HaRrY pOtTeR’ or ‘harry potter’. To standardize the format of the book title which you want to show on your website, we can simply write
<pre>{{book.title|title }}</pre>
which capitalizes the first character of each word and turn all other characters to lower.

Django also provide the ability to write custom filters and make it available to all the templates in your application. Django provides template tags and filters to control internationalization in templates. They allow for granular control of translations, formatting, and time zone conversions.

=== Admin Site ===
For a certain class of Web sites, an admin interface is an essential part of the infrastructure.

This is a Web-based interface, limited to trusted site administrators, that enables the adding, editing and deletion of site content. So the admin site has to authenticate users, display and handle forms, validate input, and so on. But the best part about Django is that it does all of this and more for you – in just a few of lines of code. This is also one of the reasons why Django is called a “heavy” web development framework.

To access the Django admin interface, we just have to add <code>/admin</code> to your project url.

[[File:Admin01.png|frame|center|alt = This is the login page of Django Admin Site|Django Admin site login page]]

We would also have to create a superuser, which can be done by following the steps given below.
<pre>$ python manage.py createsuperuser</pre>
Enter the admin username and email address:
<pre>Username: admin
Email address: admin@example.com</pre>
Choose the password for the admin account:
<pre>
Password: **********
Password (again): *********
Superuser created successfully.</pre>

[[File:Admin02.png|frame|center|alt = The default first page of the admin site|Default admin site home page]]

Django contains a file called <code>admin.py</code> where you can define models for the admin site and then enable them so that they will appear on the admin site.
Using the example of the Author Model described in the sections above, let us add it to the admin site:
<pre>
class AuthorAdmin(admin.ModelAdmin):
pass

admin.site.register(Author);
</pre>

These out-of-the-box features of the Django framework is what makes it the perfect option for creating content driven websites in relatively no time at all.

== '''Features''' ==
Django has the following features to name a few:
:*It facilitates developers with a template comprising minimal number of classes, modules, packages etc. so that the developers can focus more on the core business logic.
:*It contains an ORM (Object-Relational Mapper) that allows for the use of standard Python language. The developers need not learn any query processing language.
:*It provides with a template framework suitable for making the views.
:*It supports pluggability – that is it supports including other installed applications into your own application.
:*It has a built in administrative interface to manage the web application from an administrative level, thus providing access control.
:*It is multi-lingual
:*It supports a very useful Geographical web framework "GeoDjango"<ref>https://docs.djangoproject.com/en/1.6/ref/contrib/gis/</ref>

== '''Comparison with other web frameworks''' ==
=== Django vs Ruby on Rails ===
Most of the differences lie in the way the MVC pattern is interpreted by both the frameworks.<ref>https://bernardopires.com/2014/03/rails-vs-django-an-in-depth-technical-comparison/</ref>

==== Models:====
Everything in Ruby on Rails is based on migrations. If at any point of time, the schema of the database is changed and if it has to be reverted back to the previous schema then we can do that with the help of migrations. In case of Django, we need to depend on a third-party extension “South” (until Django 1.6) to support migrations.

==== Controllers: ====
Django considers the entire framework as the controller but Ruby on Rails has a separate entity called controllers that manage the task of interpreting the user interactions and routing to the correct method that handles the request. That is why Django is said to follow the MVT(Model View Template) framework and Ruby on Rails strictly follows MVC framework.

==== Views: ====
In Django, the amount of code that can be pushed into the views(i.e., the template) part of the application is very stringent. Only basic codes like conditional statements and simple loops are allowed. As the controller objects are not really accessible in the views, not much of the manipulation can be done in the views section of the application. This enforces a strict modularity between the models, views and templates section in the Django application making the application maintenance easier. In case of Rails, as the controller objects are accessible in the views as well, a lot of unnecessary calculations can be included in the views. This reduces modularity in the application. Thus, Django has an upper hand over Rails for this reason.

==== Other Features ====
Django has in-built features like User authentication and admin support in its web applications. This makes developing admin based web application very easy. There is no such thing in Rails as such.

=== Django vs Web2py ===

Web2py is inspired by Ruby on Rails. It supports Convention over Configuration just like Ruby on Rails. The administrative interface can be accessed from the browser for web2py. But, for Django, the developer has to manually configure everything.<ref>http://www.web2py.com/init/default/what</ref>
====Models====
Django doesn’t support migrations by itself(until 1.6). web2py supports database migrations. Also, many to many references between the tables are represented in a different way in Django and web2py. Django creates an intermediate link table whereas web2py includes the references as fields in the table.

====Controllers====
Web2py manages all the imports, and other things related to project scaffolding by itself. The developer just has to focus on the application development unlike Django wherein the user has to take care of all the imports in the code.

====Views====
If a view is undefined, then Django throws an error. But in case of web2py, it searches for mycontroller/index.html in the myapp. If that file is not present, then it creates a generic view which contains the raw response in a dictionary format on the browser.

====Other features====
One feature, Transactions, is supported by both Django and web2py. But the way transaction “commits” are executed is different. Django has two options “auto-commit” and “commit_on_success”. But in case of web2py, it by default commits if the transaction is success and doesn’t commit in case of failure of the transaction.

== References ==
<references/>

CSC/ECE 517 Fall 2014/ch1a 8 sn

2014-09-19T23:50:46Z

Sbastik: /* Features */

== '''Django Framework''' ==

Django<ref>https://www.djangoproject.com/</ref><ref>http://www.djangobook.com/en/2.0/index.html</ref>(2005) is a high level, but heavy, open source Python<ref>http://www.python.org/</ref> web framework used to build a large scale web application. Django is named after Django Reinhardt, a gypsy jazz guitarist from the 1930s to early 1950s. A web framework is necessary to help the developers and the testers to develop highly scalable and efficient large scale web applications. Django deals with the most important problem in the domain of Web development – repetition. Even though web development is a really interesting task, there are a lot of things that require unnecessary efforts and time of the developers as well as the testers. With an MVT<ref>http://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names</ref> (Model View Template) Framework, Django is very modular and thus very much suitable for highly cohesive<ref>http://en.wikipedia.org/wiki/Cohesion_(computer_science)</ref> and low coupling<ref> http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref> tasks.

__TOC__

== '''History''' ==
In 1998, Python CGI<ref>http://en.wikipedia.org/wiki/CGI</ref> was used to develop web applications from scratch using Python. In order to create a web application using Python CGI, we just have to create a Python script that generates output in the HTML format. We then save the script to a Web server with a <code>“.cgi”</code> extension and visit the page in our Web browser. Following is the sample way of creating a simple website using the script.

<pre>
#!/usr/bin/env python
import MySQLdb
print "Content-Type: text/html\n"
print "<html><head><title>Food items</title></head>"
print "<body>"
print "<h1>Food items</h1>"
print "<ul>"
connection = MySQLdb.connect(user='username', passwd='password', db='food_db')
cursor = connection.cursor()
cursor.execute("SELECT food_item_name FROM food_table ORDER BY rating DESC LIMIT 10")
for row in cursor.fetchall():
print "<li>%s</li>" % row[0]
print "</ul>"
print "</body></html>"
connection.close()
</pre>

The above script generates an HTML page which will display a list of all the food items in the descending order of their rating by interacting with the corresponding table in the database.

Even though the code has several advantages such as making a website (with only one page) from the scratch is not difficult. The code is readable and understandable to all audiences, etc. But this approach has a lot of disadvantages. The disadvantages include repetition of code (such as database connection, authentication, etc.) for a multi-page web application. Also, if discrete entities, like databases with different configuration, are to be included in the project then we will have to rewrite and reconfigure all the pages in the web application. Thus, using CGI for web application development makes it inefficient to build and deploy.

Almost all of the problems posed by Python CGI scripting mentioned above were solved by Django. Django provided a programming infrastructure for large scale web applications, so that the developers can focus on writing clean, maintainable code without worrying about the different aspects of Project Scaffolding<ref>http://en.wikipedia.org/wiki/Scaffold_(programming)</ref>. Based on the DRY<ref>http://en.wikipedia.org/wiki/Don't_repeat_yourself</ref>(Don’t Repeat Yourself) principle, Django aims at reducing repetitive pieces of information of all kinds in software development. Django also supports pluggability of different applications into the web applications that you are developing.

Also, Major websites such as [http://pinterest.com Pinterest], [http://instagram.com Instagram] were developed using Django.

=== Other Frameworks ===
:*Flask<ref>http://flask.pocoo.org/</ref>: It is a web framework that only provides the important and skeletal libraries required for basic web-development. Features such as data abstraction, unlike Django, is not provided by Flask.
:*Pyramid<ref>http://www.pylonsproject.org/projects/pyramid/about</ref>: It is a web framework which strictly follows MVC pattern. It has an additional feature, unlike Django, of maintaining a dictionary of View-to-URL-Mapping.
:*web2py<ref>http://www.web2py.com/init/default/what</ref>: It is a web framework which follows the convention of Ruby on Rails.

== '''Architecture''' ==

[[File:Django_layers.png|frame|right|alt = MVT Architecture|Django's Model-View-Template Achitecture]]

Most of the web frameworks- such as Ruby on Rails framework- are based on the MVC pattern. MVC, which stands for Model View Controller, is a pattern which provides loose coupling among different parts of the application. In MVC Pattern, Model deals with the direct interaction with the databases. Views deal with the representation of the data on the browser. Controller deals with the user interactions and redirecting each of the user interactions to the respective module responsible for dealing with it.

On the other hand, Django framework does not really fit into the MVC framework. As mentioned earlier, it follows the MTV framework which stands for (Model Template View) Framework. Controller corresponds to the View in Django Framework. In case of the Views in Django, it plays the role of the controller. It fetches the data and decides how the data is to be displayed.

===Applications===

In Django terminology, an installation of Django is considered as a “Project”.

The smallest logical subset of files/folders that is fairly independent from the rest of the project can be called as an application. These subset of files include (but are not limited to) models, views, templates, static files, URLs, etc. A single Django project can have multiple applications, each of which contains the files that define an application.

All the applications that must be included inside the main project should be explicitly mentioned inside the variable <code>INSTALLED_APPS</code> inside the <code>settings.py</code>.

<pre>INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'books'
)</pre>

=== Models ===

In Django, a model is defined as the single source for all the data. It defines how data is accessed, processed and validated. It also contains the structure and relationship of all the data that is used by the application. Models are used to define the structure of your database. Each model is converted into a database table and each attribute inside a model is converted into a column of that table. All this is handled by Django implicitly.

Consider the following example about an application called ‘books’ that contains:
:*Author: which has a first_name and last_name attributes
:*Book: which has title, author and publication date as its attributes

We can write models for the above application like:

<pre>class Author(models.Model):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=40)

class Book(models.Model):
title = models.CharField(max_length=100)
authors = models.ManyToManyField(Author)
publication_date = models.DateField()
</pre>

Once all the models for your application have been created, you can validate them by using:
<pre>python manage.py validate <app_name></pre>
Django also dynamically generates “Create Table” statements for each of these models. These statement can be viewed using the command:
<pre>python manage.py sqlall <app_name></pre>
The above command would give the following output:
<pre>BEGIN;
CREATE TABLE "books_author" (
"id" serial NOT NULL PRIMARY KEY,
"first_name" varchar(30) NOT NULL,
"last_name" varchar(40) NOT NULL,
)
;
CREATE TABLE "books_book" (
"id" serial NOT NULL PRIMARY KEY,
"title" varchar(100) NOT NULL,
"publication_date" date NOT NULL
)
;
CREATE TABLE "books_book_authors" (
"id" serial NOT NULL PRIMARY KEY,
"book_id" integer NOT NULL REFERENCES "books_book" ("id") DEFERRABLE INITIALLY DEFERRED,
"author_id" integer NOT NULL REFERENCES "books_author" ("id") DEFERRABLE INITIALLY DEFERRED,
UNIQUE ("book_id", "author_id")
)
;
COMMIT;
</pre>
and all the tables would be created immediately as soon as you run the command stated below:
<pre>python manage.py syncdb</pre>

=== Views ===
The front-end of the web-application is equally important as the model and the controllers. The basic function of the view is to accept an HTTP request and send a response. Basically Django has two types of views – Generic Views & Class based views. Generic views just take one parameter – “request”. Following is the format of the code to display Hello World.

<pre>
from django.http import HttpResponse
def hello_world(request)
return HttpResponse(“hello world”)
</pre>

Here, the method class hello_world has a parameter called “request”. This is the parameter that contains all the information of the HttpRequest. After the request has been processed, the HttpResponse object is returned back. This HttpResponse object is initialized with the string “hello world”.

Generic views mostly consist of functions. Maintaining a program with a lot of functions is difficult. This reduces the modularity of the program. In order to support classes, Class based views were introduced. Class based views consist of classes which handle all the functionality in the front end. Classes are extensible and hence reusable. We can inherit different views(classes) and include it in our class. For example, if we want to include a view which displays the contacts, we will write the following code.

<pre>from django.views.generic import ListView
from books.models import contacts
class ContactsList(ListView)
model = contacts
</pre>

In the above program, we have imported the ListView from the generic module. As we want to display the contacts from the database, we have imported the database “contacts”. The class ContactsList inherits the ListView class and extracts all the functionality in that class. The “contacts” database is imported and assigned to the model so as to display the contacts in the form of a list view.

Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function.
Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function. In order to do that, we will have to write the following code:
<pre>
from django.conf.urls.defaults import patterns, include, url
from hellworldproject.views import hello
urlpatterns = patterns(‘’. url(r’hello_world/$, hello_world)
</pre>

In the above code, the “pattern” function saves the required URL pattern in the “urlpatters” attribute.
So, after everything is set up, we run our web application with a url say <code>[web-address]/hello_world/</code>. Now, Django first goes to the <code>settings.py</code> file in the project directory and searches for the files which handles the URLConf part. Suppose the name of the files is <code>urls.py</code>. It dives into the urls.py files and linearly matches the requested url with the url patterns in the file and checks which method call is responsible to handle the request. After that, when it finds the method(here, hello_world), it passes an HttpRequest object to the method. After the required processing the request, it creates an HttpResponse object and then continues with the further processes the response by converting it into HTML code by adding the necessary formatting to the response in order for it to be displayed as a view on the screen.

=== Templates ===
In Django, templates are generally used to define how webpages of the application are supposed to look like. Template defines the structure of the webpage and also has additional elements that help access variables, run python statements and much more.

Data can be passed to templates which can be used by the templates to display to the user or perform actions on the data and create dynamic views based on the data.

==== Variables ====
We can access any data passed to the templates and use them as regular python variables. The below lines of code shows how variables can be accessed:
<pre>Author: {{author.last_name}}, {{ author.first_name }}</pre>
which will just print the author’s name on the webpage.

==== Tags ====
Templates also provide the ability to write python code inside them and execute them just like they would run inside a <code>“.py”</code> file. These elements are known as tags and look like <code>{% tag %}</code>

Given below is the example of a “for” loop that is defined inside a template:
<pre>{% for book in books_list %}
<li>{{ book.title }}</li>
{% endfor %}</pre>

You can process data (though it is not logical to do so in a template), write conditional statements or just declare variables inside tags and used them later in the template file.

==== Filters ====
Filters in templates can be defined as helper functions. They are a very powerful tool that reduces the code needed for basic (or sometimes even complex) post-processing of data.

For example, the title of a book could be added to your application as one of ‘HARRY POTTER’, ‘HaRrY pOtTeR’ or ‘harry potter’. To standardize the format of the book title which you want to show on your website, we can simply write
<pre>{{book.title|title }}</pre>
which capitalizes the first character of each word and turn all other characters to lower.

Django also provide the ability to write custom filters and make it available to all the templates in your application. Django provides template tags and filters to control internationalization in templates. They allow for granular control of translations, formatting, and time zone conversions.

=== Admin Site ===
For a certain class of Web sites, an admin interface is an essential part of the infrastructure.

This is a Web-based interface, limited to trusted site administrators, that enables the adding, editing and deletion of site content. So the admin site has to authenticate users, display and handle forms, validate input, and so on. But the best part about Django is that it does all of this and more for you – in just a few of lines of code. This is also one of the reasons why Django is called a “heavy” web development framework.

To access the Django admin interface, we just have to add <code>/admin</code> to your project url.

[[File:Admin01.png|frame|center|alt = This is the login page of Django Admin Site|Django Admin site login page]]

We would also have to create a superuser, which can be done by following the steps given below.
<pre>$ python manage.py createsuperuser</pre>
Enter the admin username and email address:
<pre>Username: admin
Email address: admin@example.com</pre>
Choose the password for the admin account:
<pre>
Password: **********
Password (again): *********
Superuser created successfully.</pre>

[[File:Admin02.png|frame|center|alt = The default first page of the admin site|Default admin site home page]]

Django contains a file called <code>admin.py</code> where you can define models for the admin site and then enable them so that they will appear on the admin site.
Using the example of the Author Model described in the sections above, let us add it to the admin site:
<pre>
class AuthorAdmin(admin.ModelAdmin):
pass

admin.site.register(Author);
</pre>

These out-of-the-box features of the Django framework is what makes it the perfect option for creating content driven websites in relatively no time at all.

== '''Features''' ==
Django has the following features to name a few:
:*It facilitates developers with a template comprising minimal number of classes, modules, packages etc. so that the developers can focus more on the core business logic.
:*It contains an ORM (Object-Relational Mapper) that allows for the use of standard Python language. The developers need not learn any query processing language.
:*It provides with a template framework suitable for making the views.
:*It supports pluggability – that is it supports including other installed applications into your own application.
:*It has a built in administrative interface to manage the web application from an administrative level, thus providing access control.
:*It is multi-lingual
:*It supports a very useful Geographical web framework "GeoDjango"<ref>https://docs.djangoproject.com/en/1.6/ref/contrib/gis/</ref>

== Comparison with other web frameworks ==
=== Django vs Ruby on Rails ===
Most of the differences lie in the way the MVC pattern is interpreted by both the frameworks.<ref>https://bernardopires.com/2014/03/rails-vs-django-an-in-depth-technical-comparison/</ref>

==== Models:====
Everything in Ruby on Rails is based on migrations. If at any point of time, the schema of the database is changed and if it has to be reverted back to the previous schema then we can do that with the help of migrations. In case of Django, we need to depend on a third-party extension “South” (until Django 1.6) to support migrations.

==== Controllers: ====
Django considers the entire framework as the controller but Ruby on Rails has a separate entity called controllers that manage the task of interpreting the user interactions and routing to the correct method that handles the request. That is why Django is said to follow the MVT(Model View Template) framework and Ruby on Rails strictly follows MVC framework.

==== Views: ====
In Django, the amount of code that can be pushed into the views(i.e., the template) part of the application is very stringent. Only basic codes like conditional statements and simple loops are allowed. As the controller objects are not really accessible in the views, not much of the manipulation can be done in the views section of the application. This enforces a strict modularity between the models, views and templates section in the Django application making the application maintenance easier. In case of Rails, as the controller objects are accessible in the views as well, a lot of unnecessary calculations can be included in the views. This reduces modularity in the application. Thus, Django has an upper hand over Rails for this reason.

==== Other Features ====
Django has in-built features like User authentication and admin support in its web applications. This makes developing admin based web application very easy. There is no such thing in Rails as such.

=== Django vs Web2py ===

Web2py is inspired by Ruby on Rails. It supports Convention over Configuration just like Ruby on Rails. The administrative interface can be accessed from the browser for web2py. But, for Django, the developer has to manually configure everything.<ref>http://www.web2py.com/init/default/what</ref>
====Models====
Django doesn’t support migrations by itself(until 1.6). web2py supports database migrations. Also, many to many references between the tables are represented in a different way in Django and web2py. Django creates an intermediate link table whereas web2py includes the references as fields in the table.

====Controllers====
Web2py manages all the imports, and other things related to project scaffolding by itself. The developer just has to focus on the application development unlike Django wherein the user has to take care of all the imports in the code.

====Views====
If a view is undefined, then Django throws an error. But in case of web2py, it searches for mycontroller/index.html in the myapp. If that file is not present, then it creates a generic view which contains the raw response in a dictionary format on the browser.

====Other features====
One feature, Transactions, is supported by both Django and web2py. But the way transaction “commits” are executed is different. Django has two options “auto-commit” and “commit_on_success”. But in case of web2py, it by default commits if the transaction is success and doesn’t commit in case of failure of the transaction.

== References ==
<references/>

CSC/ECE 517 Fall 2014/ch1a 8 sn

2014-09-19T23:50:29Z

Sbastik: /* Architecture */

== '''Django Framework''' ==

Django<ref>https://www.djangoproject.com/</ref><ref>http://www.djangobook.com/en/2.0/index.html</ref>(2005) is a high level, but heavy, open source Python<ref>http://www.python.org/</ref> web framework used to build a large scale web application. Django is named after Django Reinhardt, a gypsy jazz guitarist from the 1930s to early 1950s. A web framework is necessary to help the developers and the testers to develop highly scalable and efficient large scale web applications. Django deals with the most important problem in the domain of Web development – repetition. Even though web development is a really interesting task, there are a lot of things that require unnecessary efforts and time of the developers as well as the testers. With an MVT<ref>http://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names</ref> (Model View Template) Framework, Django is very modular and thus very much suitable for highly cohesive<ref>http://en.wikipedia.org/wiki/Cohesion_(computer_science)</ref> and low coupling<ref> http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref> tasks.

__TOC__

== '''History''' ==
In 1998, Python CGI<ref>http://en.wikipedia.org/wiki/CGI</ref> was used to develop web applications from scratch using Python. In order to create a web application using Python CGI, we just have to create a Python script that generates output in the HTML format. We then save the script to a Web server with a <code>“.cgi”</code> extension and visit the page in our Web browser. Following is the sample way of creating a simple website using the script.

<pre>
#!/usr/bin/env python
import MySQLdb
print "Content-Type: text/html\n"
print "<html><head><title>Food items</title></head>"
print "<body>"
print "<h1>Food items</h1>"
print "<ul>"
connection = MySQLdb.connect(user='username', passwd='password', db='food_db')
cursor = connection.cursor()
cursor.execute("SELECT food_item_name FROM food_table ORDER BY rating DESC LIMIT 10")
for row in cursor.fetchall():
print "<li>%s</li>" % row[0]
print "</ul>"
print "</body></html>"
connection.close()
</pre>

The above script generates an HTML page which will display a list of all the food items in the descending order of their rating by interacting with the corresponding table in the database.

Even though the code has several advantages such as making a website (with only one page) from the scratch is not difficult. The code is readable and understandable to all audiences, etc. But this approach has a lot of disadvantages. The disadvantages include repetition of code (such as database connection, authentication, etc.) for a multi-page web application. Also, if discrete entities, like databases with different configuration, are to be included in the project then we will have to rewrite and reconfigure all the pages in the web application. Thus, using CGI for web application development makes it inefficient to build and deploy.

Almost all of the problems posed by Python CGI scripting mentioned above were solved by Django. Django provided a programming infrastructure for large scale web applications, so that the developers can focus on writing clean, maintainable code without worrying about the different aspects of Project Scaffolding<ref>http://en.wikipedia.org/wiki/Scaffold_(programming)</ref>. Based on the DRY<ref>http://en.wikipedia.org/wiki/Don't_repeat_yourself</ref>(Don’t Repeat Yourself) principle, Django aims at reducing repetitive pieces of information of all kinds in software development. Django also supports pluggability of different applications into the web applications that you are developing.

Also, Major websites such as [http://pinterest.com Pinterest], [http://instagram.com Instagram] were developed using Django.

=== Other Frameworks ===
:*Flask<ref>http://flask.pocoo.org/</ref>: It is a web framework that only provides the important and skeletal libraries required for basic web-development. Features such as data abstraction, unlike Django, is not provided by Flask.
:*Pyramid<ref>http://www.pylonsproject.org/projects/pyramid/about</ref>: It is a web framework which strictly follows MVC pattern. It has an additional feature, unlike Django, of maintaining a dictionary of View-to-URL-Mapping.
:*web2py<ref>http://www.web2py.com/init/default/what</ref>: It is a web framework which follows the convention of Ruby on Rails.

== '''Architecture''' ==

[[File:Django_layers.png|frame|right|alt = MVT Architecture|Django's Model-View-Template Achitecture]]

Most of the web frameworks- such as Ruby on Rails framework- are based on the MVC pattern. MVC, which stands for Model View Controller, is a pattern which provides loose coupling among different parts of the application. In MVC Pattern, Model deals with the direct interaction with the databases. Views deal with the representation of the data on the browser. Controller deals with the user interactions and redirecting each of the user interactions to the respective module responsible for dealing with it.

On the other hand, Django framework does not really fit into the MVC framework. As mentioned earlier, it follows the MTV framework which stands for (Model Template View) Framework. Controller corresponds to the View in Django Framework. In case of the Views in Django, it plays the role of the controller. It fetches the data and decides how the data is to be displayed.

===Applications===

In Django terminology, an installation of Django is considered as a “Project”.

The smallest logical subset of files/folders that is fairly independent from the rest of the project can be called as an application. These subset of files include (but are not limited to) models, views, templates, static files, URLs, etc. A single Django project can have multiple applications, each of which contains the files that define an application.

All the applications that must be included inside the main project should be explicitly mentioned inside the variable <code>INSTALLED_APPS</code> inside the <code>settings.py</code>.

<pre>INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'books'
)</pre>

=== Models ===

In Django, a model is defined as the single source for all the data. It defines how data is accessed, processed and validated. It also contains the structure and relationship of all the data that is used by the application. Models are used to define the structure of your database. Each model is converted into a database table and each attribute inside a model is converted into a column of that table. All this is handled by Django implicitly.

Consider the following example about an application called ‘books’ that contains:
:*Author: which has a first_name and last_name attributes
:*Book: which has title, author and publication date as its attributes

We can write models for the above application like:

<pre>class Author(models.Model):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=40)

class Book(models.Model):
title = models.CharField(max_length=100)
authors = models.ManyToManyField(Author)
publication_date = models.DateField()
</pre>

Once all the models for your application have been created, you can validate them by using:
<pre>python manage.py validate <app_name></pre>
Django also dynamically generates “Create Table” statements for each of these models. These statement can be viewed using the command:
<pre>python manage.py sqlall <app_name></pre>
The above command would give the following output:
<pre>BEGIN;
CREATE TABLE "books_author" (
"id" serial NOT NULL PRIMARY KEY,
"first_name" varchar(30) NOT NULL,
"last_name" varchar(40) NOT NULL,
)
;
CREATE TABLE "books_book" (
"id" serial NOT NULL PRIMARY KEY,
"title" varchar(100) NOT NULL,
"publication_date" date NOT NULL
)
;
CREATE TABLE "books_book_authors" (
"id" serial NOT NULL PRIMARY KEY,
"book_id" integer NOT NULL REFERENCES "books_book" ("id") DEFERRABLE INITIALLY DEFERRED,
"author_id" integer NOT NULL REFERENCES "books_author" ("id") DEFERRABLE INITIALLY DEFERRED,
UNIQUE ("book_id", "author_id")
)
;
COMMIT;
</pre>
and all the tables would be created immediately as soon as you run the command stated below:
<pre>python manage.py syncdb</pre>

=== Views ===
The front-end of the web-application is equally important as the model and the controllers. The basic function of the view is to accept an HTTP request and send a response. Basically Django has two types of views – Generic Views & Class based views. Generic views just take one parameter – “request”. Following is the format of the code to display Hello World.

<pre>
from django.http import HttpResponse
def hello_world(request)
return HttpResponse(“hello world”)
</pre>

Here, the method class hello_world has a parameter called “request”. This is the parameter that contains all the information of the HttpRequest. After the request has been processed, the HttpResponse object is returned back. This HttpResponse object is initialized with the string “hello world”.

Generic views mostly consist of functions. Maintaining a program with a lot of functions is difficult. This reduces the modularity of the program. In order to support classes, Class based views were introduced. Class based views consist of classes which handle all the functionality in the front end. Classes are extensible and hence reusable. We can inherit different views(classes) and include it in our class. For example, if we want to include a view which displays the contacts, we will write the following code.

<pre>from django.views.generic import ListView
from books.models import contacts
class ContactsList(ListView)
model = contacts
</pre>

In the above program, we have imported the ListView from the generic module. As we want to display the contacts from the database, we have imported the database “contacts”. The class ContactsList inherits the ListView class and extracts all the functionality in that class. The “contacts” database is imported and assigned to the model so as to display the contacts in the form of a list view.

Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function.
Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function. In order to do that, we will have to write the following code:
<pre>
from django.conf.urls.defaults import patterns, include, url
from hellworldproject.views import hello
urlpatterns = patterns(‘’. url(r’hello_world/$, hello_world)
</pre>

In the above code, the “pattern” function saves the required URL pattern in the “urlpatters” attribute.
So, after everything is set up, we run our web application with a url say <code>[web-address]/hello_world/</code>. Now, Django first goes to the <code>settings.py</code> file in the project directory and searches for the files which handles the URLConf part. Suppose the name of the files is <code>urls.py</code>. It dives into the urls.py files and linearly matches the requested url with the url patterns in the file and checks which method call is responsible to handle the request. After that, when it finds the method(here, hello_world), it passes an HttpRequest object to the method. After the required processing the request, it creates an HttpResponse object and then continues with the further processes the response by converting it into HTML code by adding the necessary formatting to the response in order for it to be displayed as a view on the screen.

=== Templates ===
In Django, templates are generally used to define how webpages of the application are supposed to look like. Template defines the structure of the webpage and also has additional elements that help access variables, run python statements and much more.

Data can be passed to templates which can be used by the templates to display to the user or perform actions on the data and create dynamic views based on the data.

==== Variables ====
We can access any data passed to the templates and use them as regular python variables. The below lines of code shows how variables can be accessed:
<pre>Author: {{author.last_name}}, {{ author.first_name }}</pre>
which will just print the author’s name on the webpage.

==== Tags ====
Templates also provide the ability to write python code inside them and execute them just like they would run inside a <code>“.py”</code> file. These elements are known as tags and look like <code>{% tag %}</code>

Given below is the example of a “for” loop that is defined inside a template:
<pre>{% for book in books_list %}
<li>{{ book.title }}</li>
{% endfor %}</pre>

You can process data (though it is not logical to do so in a template), write conditional statements or just declare variables inside tags and used them later in the template file.

==== Filters ====
Filters in templates can be defined as helper functions. They are a very powerful tool that reduces the code needed for basic (or sometimes even complex) post-processing of data.

For example, the title of a book could be added to your application as one of ‘HARRY POTTER’, ‘HaRrY pOtTeR’ or ‘harry potter’. To standardize the format of the book title which you want to show on your website, we can simply write
<pre>{{book.title|title }}</pre>
which capitalizes the first character of each word and turn all other characters to lower.

Django also provide the ability to write custom filters and make it available to all the templates in your application. Django provides template tags and filters to control internationalization in templates. They allow for granular control of translations, formatting, and time zone conversions.

=== Admin Site ===
For a certain class of Web sites, an admin interface is an essential part of the infrastructure.

This is a Web-based interface, limited to trusted site administrators, that enables the adding, editing and deletion of site content. So the admin site has to authenticate users, display and handle forms, validate input, and so on. But the best part about Django is that it does all of this and more for you – in just a few of lines of code. This is also one of the reasons why Django is called a “heavy” web development framework.

To access the Django admin interface, we just have to add <code>/admin</code> to your project url.

[[File:Admin01.png|frame|center|alt = This is the login page of Django Admin Site|Django Admin site login page]]

We would also have to create a superuser, which can be done by following the steps given below.
<pre>$ python manage.py createsuperuser</pre>
Enter the admin username and email address:
<pre>Username: admin
Email address: admin@example.com</pre>
Choose the password for the admin account:
<pre>
Password: **********
Password (again): *********
Superuser created successfully.</pre>

[[File:Admin02.png|frame|center|alt = The default first page of the admin site|Default admin site home page]]

Django contains a file called <code>admin.py</code> where you can define models for the admin site and then enable them so that they will appear on the admin site.
Using the example of the Author Model described in the sections above, let us add it to the admin site:
<pre>
class AuthorAdmin(admin.ModelAdmin):
pass

admin.site.register(Author);
</pre>

These out-of-the-box features of the Django framework is what makes it the perfect option for creating content driven websites in relatively no time at all.

== Features ==
Django has the following features to name a few:
:*It facilitates developers with a template comprising minimal number of classes, modules, packages etc. so that the developers can focus more on the core business logic.
:*It contains an ORM (Object-Relational Mapper) that allows for the use of standard Python language. The developers need not learn any query processing language.
:*It provides with a template framework suitable for making the views.
:*It supports pluggability – that is it supports including other installed applications into your own application.
:*It has a built in administrative interface to manage the web application from an administrative level, thus providing access control.
:*It is multi-lingual
:*It supports a very useful Geographical web framework "GeoDjango"<ref>https://docs.djangoproject.com/en/1.6/ref/contrib/gis/</ref>

== Comparison with other web frameworks ==
=== Django vs Ruby on Rails ===
Most of the differences lie in the way the MVC pattern is interpreted by both the frameworks.<ref>https://bernardopires.com/2014/03/rails-vs-django-an-in-depth-technical-comparison/</ref>

==== Models:====
Everything in Ruby on Rails is based on migrations. If at any point of time, the schema of the database is changed and if it has to be reverted back to the previous schema then we can do that with the help of migrations. In case of Django, we need to depend on a third-party extension “South” (until Django 1.6) to support migrations.

==== Controllers: ====
Django considers the entire framework as the controller but Ruby on Rails has a separate entity called controllers that manage the task of interpreting the user interactions and routing to the correct method that handles the request. That is why Django is said to follow the MVT(Model View Template) framework and Ruby on Rails strictly follows MVC framework.

==== Views: ====
In Django, the amount of code that can be pushed into the views(i.e., the template) part of the application is very stringent. Only basic codes like conditional statements and simple loops are allowed. As the controller objects are not really accessible in the views, not much of the manipulation can be done in the views section of the application. This enforces a strict modularity between the models, views and templates section in the Django application making the application maintenance easier. In case of Rails, as the controller objects are accessible in the views as well, a lot of unnecessary calculations can be included in the views. This reduces modularity in the application. Thus, Django has an upper hand over Rails for this reason.

==== Other Features ====
Django has in-built features like User authentication and admin support in its web applications. This makes developing admin based web application very easy. There is no such thing in Rails as such.

=== Django vs Web2py ===

Web2py is inspired by Ruby on Rails. It supports Convention over Configuration just like Ruby on Rails. The administrative interface can be accessed from the browser for web2py. But, for Django, the developer has to manually configure everything.<ref>http://www.web2py.com/init/default/what</ref>
====Models====
Django doesn’t support migrations by itself(until 1.6). web2py supports database migrations. Also, many to many references between the tables are represented in a different way in Django and web2py. Django creates an intermediate link table whereas web2py includes the references as fields in the table.

====Controllers====
Web2py manages all the imports, and other things related to project scaffolding by itself. The developer just has to focus on the application development unlike Django wherein the user has to take care of all the imports in the code.

====Views====
If a view is undefined, then Django throws an error. But in case of web2py, it searches for mycontroller/index.html in the myapp. If that file is not present, then it creates a generic view which contains the raw response in a dictionary format on the browser.

====Other features====
One feature, Transactions, is supported by both Django and web2py. But the way transaction “commits” are executed is different. Django has two options “auto-commit” and “commit_on_success”. But in case of web2py, it by default commits if the transaction is success and doesn’t commit in case of failure of the transaction.

== References ==
<references/>

CSC/ECE 517 Fall 2014/ch1a 8 sn

2014-09-19T23:50:19Z

Sbastik: /* History */

== '''Django Framework''' ==

Django<ref>https://www.djangoproject.com/</ref><ref>http://www.djangobook.com/en/2.0/index.html</ref>(2005) is a high level, but heavy, open source Python<ref>http://www.python.org/</ref> web framework used to build a large scale web application. Django is named after Django Reinhardt, a gypsy jazz guitarist from the 1930s to early 1950s. A web framework is necessary to help the developers and the testers to develop highly scalable and efficient large scale web applications. Django deals with the most important problem in the domain of Web development – repetition. Even though web development is a really interesting task, there are a lot of things that require unnecessary efforts and time of the developers as well as the testers. With an MVT<ref>http://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names</ref> (Model View Template) Framework, Django is very modular and thus very much suitable for highly cohesive<ref>http://en.wikipedia.org/wiki/Cohesion_(computer_science)</ref> and low coupling<ref> http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref> tasks.

__TOC__

== '''History''' ==
In 1998, Python CGI<ref>http://en.wikipedia.org/wiki/CGI</ref> was used to develop web applications from scratch using Python. In order to create a web application using Python CGI, we just have to create a Python script that generates output in the HTML format. We then save the script to a Web server with a <code>“.cgi”</code> extension and visit the page in our Web browser. Following is the sample way of creating a simple website using the script.

<pre>
#!/usr/bin/env python
import MySQLdb
print "Content-Type: text/html\n"
print "<html><head><title>Food items</title></head>"
print "<body>"
print "<h1>Food items</h1>"
print "<ul>"
connection = MySQLdb.connect(user='username', passwd='password', db='food_db')
cursor = connection.cursor()
cursor.execute("SELECT food_item_name FROM food_table ORDER BY rating DESC LIMIT 10")
for row in cursor.fetchall():
print "<li>%s</li>" % row[0]
print "</ul>"
print "</body></html>"
connection.close()
</pre>

The above script generates an HTML page which will display a list of all the food items in the descending order of their rating by interacting with the corresponding table in the database.

Even though the code has several advantages such as making a website (with only one page) from the scratch is not difficult. The code is readable and understandable to all audiences, etc. But this approach has a lot of disadvantages. The disadvantages include repetition of code (such as database connection, authentication, etc.) for a multi-page web application. Also, if discrete entities, like databases with different configuration, are to be included in the project then we will have to rewrite and reconfigure all the pages in the web application. Thus, using CGI for web application development makes it inefficient to build and deploy.

Almost all of the problems posed by Python CGI scripting mentioned above were solved by Django. Django provided a programming infrastructure for large scale web applications, so that the developers can focus on writing clean, maintainable code without worrying about the different aspects of Project Scaffolding<ref>http://en.wikipedia.org/wiki/Scaffold_(programming)</ref>. Based on the DRY<ref>http://en.wikipedia.org/wiki/Don't_repeat_yourself</ref>(Don’t Repeat Yourself) principle, Django aims at reducing repetitive pieces of information of all kinds in software development. Django also supports pluggability of different applications into the web applications that you are developing.

Also, Major websites such as [http://pinterest.com Pinterest], [http://instagram.com Instagram] were developed using Django.

=== Other Frameworks ===
:*Flask<ref>http://flask.pocoo.org/</ref>: It is a web framework that only provides the important and skeletal libraries required for basic web-development. Features such as data abstraction, unlike Django, is not provided by Flask.
:*Pyramid<ref>http://www.pylonsproject.org/projects/pyramid/about</ref>: It is a web framework which strictly follows MVC pattern. It has an additional feature, unlike Django, of maintaining a dictionary of View-to-URL-Mapping.
:*web2py<ref>http://www.web2py.com/init/default/what</ref>: It is a web framework which follows the convention of Ruby on Rails.

== Architecture ==

[[File:Django_layers.png|frame|right|alt = MVT Architecture|Django's Model-View-Template Achitecture]]

Most of the web frameworks- such as Ruby on Rails framework- are based on the MVC pattern. MVC, which stands for Model View Controller, is a pattern which provides loose coupling among different parts of the application. In MVC Pattern, Model deals with the direct interaction with the databases. Views deal with the representation of the data on the browser. Controller deals with the user interactions and redirecting each of the user interactions to the respective module responsible for dealing with it.

On the other hand, Django framework does not really fit into the MVC framework. As mentioned earlier, it follows the MTV framework which stands for (Model Template View) Framework. Controller corresponds to the View in Django Framework. In case of the Views in Django, it plays the role of the controller. It fetches the data and decides how the data is to be displayed.

===Applications===

In Django terminology, an installation of Django is considered as a “Project”.

The smallest logical subset of files/folders that is fairly independent from the rest of the project can be called as an application. These subset of files include (but are not limited to) models, views, templates, static files, URLs, etc. A single Django project can have multiple applications, each of which contains the files that define an application.

All the applications that must be included inside the main project should be explicitly mentioned inside the variable <code>INSTALLED_APPS</code> inside the <code>settings.py</code>.

<pre>INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'books'
)</pre>

=== Models ===

In Django, a model is defined as the single source for all the data. It defines how data is accessed, processed and validated. It also contains the structure and relationship of all the data that is used by the application. Models are used to define the structure of your database. Each model is converted into a database table and each attribute inside a model is converted into a column of that table. All this is handled by Django implicitly.

Consider the following example about an application called ‘books’ that contains:
:*Author: which has a first_name and last_name attributes
:*Book: which has title, author and publication date as its attributes

We can write models for the above application like:

<pre>class Author(models.Model):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=40)

class Book(models.Model):
title = models.CharField(max_length=100)
authors = models.ManyToManyField(Author)
publication_date = models.DateField()
</pre>

Once all the models for your application have been created, you can validate them by using:
<pre>python manage.py validate <app_name></pre>
Django also dynamically generates “Create Table” statements for each of these models. These statement can be viewed using the command:
<pre>python manage.py sqlall <app_name></pre>
The above command would give the following output:
<pre>BEGIN;
CREATE TABLE "books_author" (
"id" serial NOT NULL PRIMARY KEY,
"first_name" varchar(30) NOT NULL,
"last_name" varchar(40) NOT NULL,
)
;
CREATE TABLE "books_book" (
"id" serial NOT NULL PRIMARY KEY,
"title" varchar(100) NOT NULL,
"publication_date" date NOT NULL
)
;
CREATE TABLE "books_book_authors" (
"id" serial NOT NULL PRIMARY KEY,
"book_id" integer NOT NULL REFERENCES "books_book" ("id") DEFERRABLE INITIALLY DEFERRED,
"author_id" integer NOT NULL REFERENCES "books_author" ("id") DEFERRABLE INITIALLY DEFERRED,
UNIQUE ("book_id", "author_id")
)
;
COMMIT;
</pre>
and all the tables would be created immediately as soon as you run the command stated below:
<pre>python manage.py syncdb</pre>

=== Views ===
The front-end of the web-application is equally important as the model and the controllers. The basic function of the view is to accept an HTTP request and send a response. Basically Django has two types of views – Generic Views & Class based views. Generic views just take one parameter – “request”. Following is the format of the code to display Hello World.

<pre>
from django.http import HttpResponse
def hello_world(request)
return HttpResponse(“hello world”)
</pre>

Here, the method class hello_world has a parameter called “request”. This is the parameter that contains all the information of the HttpRequest. After the request has been processed, the HttpResponse object is returned back. This HttpResponse object is initialized with the string “hello world”.

Generic views mostly consist of functions. Maintaining a program with a lot of functions is difficult. This reduces the modularity of the program. In order to support classes, Class based views were introduced. Class based views consist of classes which handle all the functionality in the front end. Classes are extensible and hence reusable. We can inherit different views(classes) and include it in our class. For example, if we want to include a view which displays the contacts, we will write the following code.

<pre>from django.views.generic import ListView
from books.models import contacts
class ContactsList(ListView)
model = contacts
</pre>

In the above program, we have imported the ListView from the generic module. As we want to display the contacts from the database, we have imported the database “contacts”. The class ContactsList inherits the ListView class and extracts all the functionality in that class. The “contacts” database is imported and assigned to the model so as to display the contacts in the form of a list view.

Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function.
Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function. In order to do that, we will have to write the following code:
<pre>
from django.conf.urls.defaults import patterns, include, url
from hellworldproject.views import hello
urlpatterns = patterns(‘’. url(r’hello_world/$, hello_world)
</pre>

In the above code, the “pattern” function saves the required URL pattern in the “urlpatters” attribute.
So, after everything is set up, we run our web application with a url say <code>[web-address]/hello_world/</code>. Now, Django first goes to the <code>settings.py</code> file in the project directory and searches for the files which handles the URLConf part. Suppose the name of the files is <code>urls.py</code>. It dives into the urls.py files and linearly matches the requested url with the url patterns in the file and checks which method call is responsible to handle the request. After that, when it finds the method(here, hello_world), it passes an HttpRequest object to the method. After the required processing the request, it creates an HttpResponse object and then continues with the further processes the response by converting it into HTML code by adding the necessary formatting to the response in order for it to be displayed as a view on the screen.

=== Templates ===
In Django, templates are generally used to define how webpages of the application are supposed to look like. Template defines the structure of the webpage and also has additional elements that help access variables, run python statements and much more.

Data can be passed to templates which can be used by the templates to display to the user or perform actions on the data and create dynamic views based on the data.

==== Variables ====
We can access any data passed to the templates and use them as regular python variables. The below lines of code shows how variables can be accessed:
<pre>Author: {{author.last_name}}, {{ author.first_name }}</pre>
which will just print the author’s name on the webpage.

==== Tags ====
Templates also provide the ability to write python code inside them and execute them just like they would run inside a <code>“.py”</code> file. These elements are known as tags and look like <code>{% tag %}</code>

Given below is the example of a “for” loop that is defined inside a template:
<pre>{% for book in books_list %}
<li>{{ book.title }}</li>
{% endfor %}</pre>

You can process data (though it is not logical to do so in a template), write conditional statements or just declare variables inside tags and used them later in the template file.

==== Filters ====
Filters in templates can be defined as helper functions. They are a very powerful tool that reduces the code needed for basic (or sometimes even complex) post-processing of data.

For example, the title of a book could be added to your application as one of ‘HARRY POTTER’, ‘HaRrY pOtTeR’ or ‘harry potter’. To standardize the format of the book title which you want to show on your website, we can simply write
<pre>{{book.title|title }}</pre>
which capitalizes the first character of each word and turn all other characters to lower.

Django also provide the ability to write custom filters and make it available to all the templates in your application. Django provides template tags and filters to control internationalization in templates. They allow for granular control of translations, formatting, and time zone conversions.

=== Admin Site ===
For a certain class of Web sites, an admin interface is an essential part of the infrastructure.

This is a Web-based interface, limited to trusted site administrators, that enables the adding, editing and deletion of site content. So the admin site has to authenticate users, display and handle forms, validate input, and so on. But the best part about Django is that it does all of this and more for you – in just a few of lines of code. This is also one of the reasons why Django is called a “heavy” web development framework.

To access the Django admin interface, we just have to add <code>/admin</code> to your project url.

[[File:Admin01.png|frame|center|alt = This is the login page of Django Admin Site|Django Admin site login page]]

We would also have to create a superuser, which can be done by following the steps given below.
<pre>$ python manage.py createsuperuser</pre>
Enter the admin username and email address:
<pre>Username: admin
Email address: admin@example.com</pre>
Choose the password for the admin account:
<pre>
Password: **********
Password (again): *********
Superuser created successfully.</pre>

[[File:Admin02.png|frame|center|alt = The default first page of the admin site|Default admin site home page]]

Django contains a file called <code>admin.py</code> where you can define models for the admin site and then enable them so that they will appear on the admin site.
Using the example of the Author Model described in the sections above, let us add it to the admin site:
<pre>
class AuthorAdmin(admin.ModelAdmin):
pass

admin.site.register(Author);
</pre>

These out-of-the-box features of the Django framework is what makes it the perfect option for creating content driven websites in relatively no time at all.

== Features ==
Django has the following features to name a few:
:*It facilitates developers with a template comprising minimal number of classes, modules, packages etc. so that the developers can focus more on the core business logic.
:*It contains an ORM (Object-Relational Mapper) that allows for the use of standard Python language. The developers need not learn any query processing language.
:*It provides with a template framework suitable for making the views.
:*It supports pluggability – that is it supports including other installed applications into your own application.
:*It has a built in administrative interface to manage the web application from an administrative level, thus providing access control.
:*It is multi-lingual
:*It supports a very useful Geographical web framework "GeoDjango"<ref>https://docs.djangoproject.com/en/1.6/ref/contrib/gis/</ref>

== Comparison with other web frameworks ==
=== Django vs Ruby on Rails ===
Most of the differences lie in the way the MVC pattern is interpreted by both the frameworks.<ref>https://bernardopires.com/2014/03/rails-vs-django-an-in-depth-technical-comparison/</ref>

==== Models:====
Everything in Ruby on Rails is based on migrations. If at any point of time, the schema of the database is changed and if it has to be reverted back to the previous schema then we can do that with the help of migrations. In case of Django, we need to depend on a third-party extension “South” (until Django 1.6) to support migrations.

==== Controllers: ====
Django considers the entire framework as the controller but Ruby on Rails has a separate entity called controllers that manage the task of interpreting the user interactions and routing to the correct method that handles the request. That is why Django is said to follow the MVT(Model View Template) framework and Ruby on Rails strictly follows MVC framework.

==== Views: ====
In Django, the amount of code that can be pushed into the views(i.e., the template) part of the application is very stringent. Only basic codes like conditional statements and simple loops are allowed. As the controller objects are not really accessible in the views, not much of the manipulation can be done in the views section of the application. This enforces a strict modularity between the models, views and templates section in the Django application making the application maintenance easier. In case of Rails, as the controller objects are accessible in the views as well, a lot of unnecessary calculations can be included in the views. This reduces modularity in the application. Thus, Django has an upper hand over Rails for this reason.

==== Other Features ====
Django has in-built features like User authentication and admin support in its web applications. This makes developing admin based web application very easy. There is no such thing in Rails as such.

=== Django vs Web2py ===

Web2py is inspired by Ruby on Rails. It supports Convention over Configuration just like Ruby on Rails. The administrative interface can be accessed from the browser for web2py. But, for Django, the developer has to manually configure everything.<ref>http://www.web2py.com/init/default/what</ref>
====Models====
Django doesn’t support migrations by itself(until 1.6). web2py supports database migrations. Also, many to many references between the tables are represented in a different way in Django and web2py. Django creates an intermediate link table whereas web2py includes the references as fields in the table.

====Controllers====
Web2py manages all the imports, and other things related to project scaffolding by itself. The developer just has to focus on the application development unlike Django wherein the user has to take care of all the imports in the code.

====Views====
If a view is undefined, then Django throws an error. But in case of web2py, it searches for mycontroller/index.html in the myapp. If that file is not present, then it creates a generic view which contains the raw response in a dictionary format on the browser.

====Other features====
One feature, Transactions, is supported by both Django and web2py. But the way transaction “commits” are executed is different. Django has two options “auto-commit” and “commit_on_success”. But in case of web2py, it by default commits if the transaction is success and doesn’t commit in case of failure of the transaction.

== References ==
<references/>

CSC/ECE 517 Fall 2014/ch1a 8 sn

2014-09-19T23:48:28Z

Sbastik: /* Comparison with other web frameworks */

== '''Django Framework''' ==

Django<ref>https://www.djangoproject.com/</ref><ref>http://www.djangobook.com/en/2.0/index.html</ref>(2005) is a high level, but heavy, open source Python<ref>http://www.python.org/</ref> web framework used to build a large scale web application. Django is named after Django Reinhardt, a gypsy jazz guitarist from the 1930s to early 1950s. A web framework is necessary to help the developers and the testers to develop highly scalable and efficient large scale web applications. Django deals with the most important problem in the domain of Web development – repetition. Even though web development is a really interesting task, there are a lot of things that require unnecessary efforts and time of the developers as well as the testers. With an MVT<ref>http://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names</ref> (Model View Template) Framework, Django is very modular and thus very much suitable for highly cohesive<ref>http://en.wikipedia.org/wiki/Cohesion_(computer_science)</ref> and low coupling<ref> http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref> tasks.

__TOC__

== History ==
In 1998, Python CGI<ref>http://en.wikipedia.org/wiki/CGI</ref> was used to develop web applications from scratch using Python. In order to create a web application using Python CGI, we just have to create a Python script that generates output in the HTML format. We then save the script to a Web server with a <code>“.cgi”</code> extension and visit the page in our Web browser. Following is the sample way of creating a simple website using the script.

<pre>
#!/usr/bin/env python
import MySQLdb
print "Content-Type: text/html\n"
print "<html><head><title>Food items</title></head>"
print "<body>"
print "<h1>Food items</h1>"
print "<ul>"
connection = MySQLdb.connect(user='username', passwd='password', db='food_db')
cursor = connection.cursor()
cursor.execute("SELECT food_item_name FROM food_table ORDER BY rating DESC LIMIT 10")
for row in cursor.fetchall():
print "<li>%s</li>" % row[0]
print "</ul>"
print "</body></html>"
connection.close()
</pre>

The above script generates an HTML page which will display a list of all the food items in the descending order of their rating by interacting with the corresponding table in the database.

Even though the code has several advantages such as making a website (with only one page) from the scratch is not difficult. The code is readable and understandable to all audiences, etc. But this approach has a lot of disadvantages. The disadvantages include repetition of code (such as database connection, authentication, etc.) for a multi-page web application. Also, if discrete entities, like databases with different configuration, are to be included in the project then we will have to rewrite and reconfigure all the pages in the web application. Thus, using CGI for web application development makes it inefficient to build and deploy.

Almost all of the problems posed by Python CGI scripting mentioned above were solved by Django. Django provided a programming infrastructure for large scale web applications, so that the developers can focus on writing clean, maintainable code without worrying about the different aspects of Project Scaffolding<ref>http://en.wikipedia.org/wiki/Scaffold_(programming)</ref>. Based on the DRY<ref>http://en.wikipedia.org/wiki/Don't_repeat_yourself</ref>(Don’t Repeat Yourself) principle, Django aims at reducing repetitive pieces of information of all kinds in software development. Django also supports pluggability of different applications into the web applications that you are developing.

Also, Major websites such as [http://pinterest.com Pinterest], [http://instagram.com Instagram] were developed using Django.

=== Other Frameworks ===
:*Flask<ref>http://flask.pocoo.org/</ref>: It is a web framework that only provides the important and skeletal libraries required for basic web-development. Features such as data abstraction, unlike Django, is not provided by Flask.
:*Pyramid<ref>http://www.pylonsproject.org/projects/pyramid/about</ref>: It is a web framework which strictly follows MVC pattern. It has an additional feature, unlike Django, of maintaining a dictionary of View-to-URL-Mapping.
:*web2py<ref>http://www.web2py.com/init/default/what</ref>: It is a web framework which follows the convention of Ruby on Rails.

== Architecture ==

[[File:Django_layers.png|frame|right|alt = MVT Architecture|Django's Model-View-Template Achitecture]]

Most of the web frameworks- such as Ruby on Rails framework- are based on the MVC pattern. MVC, which stands for Model View Controller, is a pattern which provides loose coupling among different parts of the application. In MVC Pattern, Model deals with the direct interaction with the databases. Views deal with the representation of the data on the browser. Controller deals with the user interactions and redirecting each of the user interactions to the respective module responsible for dealing with it.

On the other hand, Django framework does not really fit into the MVC framework. As mentioned earlier, it follows the MTV framework which stands for (Model Template View) Framework. Controller corresponds to the View in Django Framework. In case of the Views in Django, it plays the role of the controller. It fetches the data and decides how the data is to be displayed.

===Applications===

In Django terminology, an installation of Django is considered as a “Project”.

The smallest logical subset of files/folders that is fairly independent from the rest of the project can be called as an application. These subset of files include (but are not limited to) models, views, templates, static files, URLs, etc. A single Django project can have multiple applications, each of which contains the files that define an application.

All the applications that must be included inside the main project should be explicitly mentioned inside the variable <code>INSTALLED_APPS</code> inside the <code>settings.py</code>.

<pre>INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'books'
)</pre>

=== Models ===

In Django, a model is defined as the single source for all the data. It defines how data is accessed, processed and validated. It also contains the structure and relationship of all the data that is used by the application. Models are used to define the structure of your database. Each model is converted into a database table and each attribute inside a model is converted into a column of that table. All this is handled by Django implicitly.

Consider the following example about an application called ‘books’ that contains:
:*Author: which has a first_name and last_name attributes
:*Book: which has title, author and publication date as its attributes

We can write models for the above application like:

<pre>class Author(models.Model):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=40)

class Book(models.Model):
title = models.CharField(max_length=100)
authors = models.ManyToManyField(Author)
publication_date = models.DateField()
</pre>

Once all the models for your application have been created, you can validate them by using:
<pre>python manage.py validate <app_name></pre>
Django also dynamically generates “Create Table” statements for each of these models. These statement can be viewed using the command:
<pre>python manage.py sqlall <app_name></pre>
The above command would give the following output:
<pre>BEGIN;
CREATE TABLE "books_author" (
"id" serial NOT NULL PRIMARY KEY,
"first_name" varchar(30) NOT NULL,
"last_name" varchar(40) NOT NULL,
)
;
CREATE TABLE "books_book" (
"id" serial NOT NULL PRIMARY KEY,
"title" varchar(100) NOT NULL,
"publication_date" date NOT NULL
)
;
CREATE TABLE "books_book_authors" (
"id" serial NOT NULL PRIMARY KEY,
"book_id" integer NOT NULL REFERENCES "books_book" ("id") DEFERRABLE INITIALLY DEFERRED,
"author_id" integer NOT NULL REFERENCES "books_author" ("id") DEFERRABLE INITIALLY DEFERRED,
UNIQUE ("book_id", "author_id")
)
;
COMMIT;
</pre>
and all the tables would be created immediately as soon as you run the command stated below:
<pre>python manage.py syncdb</pre>

=== Views ===
The front-end of the web-application is equally important as the model and the controllers. The basic function of the view is to accept an HTTP request and send a response. Basically Django has two types of views – Generic Views & Class based views. Generic views just take one parameter – “request”. Following is the format of the code to display Hello World.

<pre>
from django.http import HttpResponse
def hello_world(request)
return HttpResponse(“hello world”)
</pre>

Here, the method class hello_world has a parameter called “request”. This is the parameter that contains all the information of the HttpRequest. After the request has been processed, the HttpResponse object is returned back. This HttpResponse object is initialized with the string “hello world”.

Generic views mostly consist of functions. Maintaining a program with a lot of functions is difficult. This reduces the modularity of the program. In order to support classes, Class based views were introduced. Class based views consist of classes which handle all the functionality in the front end. Classes are extensible and hence reusable. We can inherit different views(classes) and include it in our class. For example, if we want to include a view which displays the contacts, we will write the following code.

<pre>from django.views.generic import ListView
from books.models import contacts
class ContactsList(ListView)
model = contacts
</pre>

In the above program, we have imported the ListView from the generic module. As we want to display the contacts from the database, we have imported the database “contacts”. The class ContactsList inherits the ListView class and extracts all the functionality in that class. The “contacts” database is imported and assigned to the model so as to display the contacts in the form of a list view.

Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function.
Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function. In order to do that, we will have to write the following code:
<pre>
from django.conf.urls.defaults import patterns, include, url
from hellworldproject.views import hello
urlpatterns = patterns(‘’. url(r’hello_world/$, hello_world)
</pre>

In the above code, the “pattern” function saves the required URL pattern in the “urlpatters” attribute.
So, after everything is set up, we run our web application with a url say <code>[web-address]/hello_world/</code>. Now, Django first goes to the <code>settings.py</code> file in the project directory and searches for the files which handles the URLConf part. Suppose the name of the files is <code>urls.py</code>. It dives into the urls.py files and linearly matches the requested url with the url patterns in the file and checks which method call is responsible to handle the request. After that, when it finds the method(here, hello_world), it passes an HttpRequest object to the method. After the required processing the request, it creates an HttpResponse object and then continues with the further processes the response by converting it into HTML code by adding the necessary formatting to the response in order for it to be displayed as a view on the screen.

=== Templates ===
In Django, templates are generally used to define how webpages of the application are supposed to look like. Template defines the structure of the webpage and also has additional elements that help access variables, run python statements and much more.

Data can be passed to templates which can be used by the templates to display to the user or perform actions on the data and create dynamic views based on the data.

==== Variables ====
We can access any data passed to the templates and use them as regular python variables. The below lines of code shows how variables can be accessed:
<pre>Author: {{author.last_name}}, {{ author.first_name }}</pre>
which will just print the author’s name on the webpage.

==== Tags ====
Templates also provide the ability to write python code inside them and execute them just like they would run inside a <code>“.py”</code> file. These elements are known as tags and look like <code>{% tag %}</code>

Given below is the example of a “for” loop that is defined inside a template:
<pre>{% for book in books_list %}
<li>{{ book.title }}</li>
{% endfor %}</pre>

You can process data (though it is not logical to do so in a template), write conditional statements or just declare variables inside tags and used them later in the template file.

==== Filters ====
Filters in templates can be defined as helper functions. They are a very powerful tool that reduces the code needed for basic (or sometimes even complex) post-processing of data.

For example, the title of a book could be added to your application as one of ‘HARRY POTTER’, ‘HaRrY pOtTeR’ or ‘harry potter’. To standardize the format of the book title which you want to show on your website, we can simply write
<pre>{{book.title|title }}</pre>
which capitalizes the first character of each word and turn all other characters to lower.

Django also provide the ability to write custom filters and make it available to all the templates in your application. Django provides template tags and filters to control internationalization in templates. They allow for granular control of translations, formatting, and time zone conversions.

=== Admin Site ===
For a certain class of Web sites, an admin interface is an essential part of the infrastructure.

This is a Web-based interface, limited to trusted site administrators, that enables the adding, editing and deletion of site content. So the admin site has to authenticate users, display and handle forms, validate input, and so on. But the best part about Django is that it does all of this and more for you – in just a few of lines of code. This is also one of the reasons why Django is called a “heavy” web development framework.

To access the Django admin interface, we just have to add <code>/admin</code> to your project url.

[[File:Admin01.png|frame|center|alt = This is the login page of Django Admin Site|Django Admin site login page]]

We would also have to create a superuser, which can be done by following the steps given below.
<pre>$ python manage.py createsuperuser</pre>
Enter the admin username and email address:
<pre>Username: admin
Email address: admin@example.com</pre>
Choose the password for the admin account:
<pre>
Password: **********
Password (again): *********
Superuser created successfully.</pre>

[[File:Admin02.png|frame|center|alt = The default first page of the admin site|Default admin site home page]]

Django contains a file called <code>admin.py</code> where you can define models for the admin site and then enable them so that they will appear on the admin site.
Using the example of the Author Model described in the sections above, let us add it to the admin site:
<pre>
class AuthorAdmin(admin.ModelAdmin):
pass

admin.site.register(Author);
</pre>

These out-of-the-box features of the Django framework is what makes it the perfect option for creating content driven websites in relatively no time at all.

== Features ==
Django has the following features to name a few:
:*It facilitates developers with a template comprising minimal number of classes, modules, packages etc. so that the developers can focus more on the core business logic.
:*It contains an ORM (Object-Relational Mapper) that allows for the use of standard Python language. The developers need not learn any query processing language.
:*It provides with a template framework suitable for making the views.
:*It supports pluggability – that is it supports including other installed applications into your own application.
:*It has a built in administrative interface to manage the web application from an administrative level, thus providing access control.
:*It is multi-lingual
:*It supports a very useful Geographical web framework "GeoDjango"<ref>https://docs.djangoproject.com/en/1.6/ref/contrib/gis/</ref>

== Comparison with other web frameworks ==
=== Django vs Ruby on Rails ===
Most of the differences lie in the way the MVC pattern is interpreted by both the frameworks.<ref>https://bernardopires.com/2014/03/rails-vs-django-an-in-depth-technical-comparison/</ref>

==== Models:====
Everything in Ruby on Rails is based on migrations. If at any point of time, the schema of the database is changed and if it has to be reverted back to the previous schema then we can do that with the help of migrations. In case of Django, we need to depend on a third-party extension “South” (until Django 1.6) to support migrations.

==== Controllers: ====
Django considers the entire framework as the controller but Ruby on Rails has a separate entity called controllers that manage the task of interpreting the user interactions and routing to the correct method that handles the request. That is why Django is said to follow the MVT(Model View Template) framework and Ruby on Rails strictly follows MVC framework.

==== Views: ====
In Django, the amount of code that can be pushed into the views(i.e., the template) part of the application is very stringent. Only basic codes like conditional statements and simple loops are allowed. As the controller objects are not really accessible in the views, not much of the manipulation can be done in the views section of the application. This enforces a strict modularity between the models, views and templates section in the Django application making the application maintenance easier. In case of Rails, as the controller objects are accessible in the views as well, a lot of unnecessary calculations can be included in the views. This reduces modularity in the application. Thus, Django has an upper hand over Rails for this reason.

==== Other Features ====
Django has in-built features like User authentication and admin support in its web applications. This makes developing admin based web application very easy. There is no such thing in Rails as such.

=== Django vs Web2py ===

Web2py is inspired by Ruby on Rails. It supports Convention over Configuration just like Ruby on Rails. The administrative interface can be accessed from the browser for web2py. But, for Django, the developer has to manually configure everything.<ref>http://www.web2py.com/init/default/what</ref>
====Models====
Django doesn’t support migrations by itself(until 1.6). web2py supports database migrations. Also, many to many references between the tables are represented in a different way in Django and web2py. Django creates an intermediate link table whereas web2py includes the references as fields in the table.

====Controllers====
Web2py manages all the imports, and other things related to project scaffolding by itself. The developer just has to focus on the application development unlike Django wherein the user has to take care of all the imports in the code.

====Views====
If a view is undefined, then Django throws an error. But in case of web2py, it searches for mycontroller/index.html in the myapp. If that file is not present, then it creates a generic view which contains the raw response in a dictionary format on the browser.

====Other features====
One feature, Transactions, is supported by both Django and web2py. But the way transaction “commits” are executed is different. Django has two options “auto-commit” and “commit_on_success”. But in case of web2py, it by default commits if the transaction is success and doesn’t commit in case of failure of the transaction.

== References ==
<references/>

CSC/ECE 517 Fall 2014/ch1a 8 sn

2014-09-19T23:29:55Z

Sbastik: /* Django vs Ruby on Rails */

== '''Django Framework''' ==

Django<ref>https://www.djangoproject.com/</ref><ref>http://www.djangobook.com/en/2.0/index.html</ref>(2005) is a high level, but heavy, open source Python<ref>http://www.python.org/</ref> web framework used to build a large scale web application. Django is named after Django Reinhardt, a gypsy jazz guitarist from the 1930s to early 1950s. A web framework is necessary to help the developers and the testers to develop highly scalable and efficient large scale web applications. Django deals with the most important problem in the domain of Web development – repetition. Even though web development is a really interesting task, there are a lot of things that require unnecessary efforts and time of the developers as well as the testers. With an MVT<ref>http://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names</ref> (Model View Template) Framework, Django is very modular and thus very much suitable for highly cohesive<ref>http://en.wikipedia.org/wiki/Cohesion_(computer_science)</ref> and low coupling<ref> http://en.wikipedia.org/wiki/Coupling_(computer_programming)</ref> tasks.

__TOC__

== History ==
In 1998, Python CGI<ref>http://en.wikipedia.org/wiki/CGI</ref> was used to develop web applications from scratch using Python. In order to create a web application using Python CGI, we just have to create a Python script that generates output in the HTML format. We then save the script to a Web server with a <code>“.cgi”</code> extension and visit the page in our Web browser. Following is the sample way of creating a simple website using the script.

<pre>
#!/usr/bin/env python
import MySQLdb
print "Content-Type: text/html\n"
print "<html><head><title>Food items</title></head>"
print "<body>"
print "<h1>Food items</h1>"
print "<ul>"
connection = MySQLdb.connect(user='username', passwd='password', db='food_db')
cursor = connection.cursor()
cursor.execute("SELECT food_item_name FROM food_table ORDER BY rating DESC LIMIT 10")
for row in cursor.fetchall():
print "<li>%s</li>" % row[0]
print "</ul>"
print "</body></html>"
connection.close()
</pre>

The above script generates an HTML page which will display a list of all the food items in the descending order of their rating by interacting with the corresponding table in the database.

Even though the code has several advantages such as making a website (with only one page) from the scratch is not difficult. The code is readable and understandable to all audiences, etc. But this approach has a lot of disadvantages. The disadvantages include repetition of code (such as database connection, authentication, etc.) for a multi-page web application. Also, if discrete entities, like databases with different configuration, are to be included in the project then we will have to rewrite and reconfigure all the pages in the web application. Thus, using CGI for web application development makes it inefficient to build and deploy.

Almost all of the problems posed by Python CGI scripting mentioned above were solved by Django. Django provided a programming infrastructure for large scale web applications, so that the developers can focus on writing clean, maintainable code without worrying about the different aspects of Project Scaffolding<ref>http://en.wikipedia.org/wiki/Scaffold_(programming)</ref>. Based on the DRY<ref>http://en.wikipedia.org/wiki/Don't_repeat_yourself</ref>(Don’t Repeat Yourself) principle, Django aims at reducing repetitive pieces of information of all kinds in software development. Django also supports pluggability of different applications into the web applications that you are developing.

Also, Major websites such as [http://pinterest.com Pinterest], [http://instagram.com Instagram] were developed using Django.

=== Other Frameworks ===
:*Flask<ref>http://flask.pocoo.org/</ref>: It is a web framework that only provides the important and skeletal libraries required for basic web-development. Features such as data abstraction, unlike Django, is not provided by Flask.
:*Pyramid<ref>http://www.pylonsproject.org/projects/pyramid/about</ref>: It is a web framework which strictly follows MVC pattern. It has an additional feature, unlike Django, of maintaining a dictionary of View-to-URL-Mapping.
:*web2py<ref>http://www.web2py.com/init/default/what</ref>: It is a web framework which follows the convention of Ruby on Rails.

== Architecture ==

[[File:Django_layers.png|frame|right|alt = MVT Architecture|Django's Model-View-Template Achitecture]]

Most of the web frameworks- such as Ruby on Rails framework- are based on the MVC pattern. MVC, which stands for Model View Controller, is a pattern which provides loose coupling among different parts of the application. In MVC Pattern, Model deals with the direct interaction with the databases. Views deal with the representation of the data on the browser. Controller deals with the user interactions and redirecting each of the user interactions to the respective module responsible for dealing with it.

On the other hand, Django framework does not really fit into the MVC framework. As mentioned earlier, it follows the MTV framework which stands for (Model Template View) Framework. Controller corresponds to the View in Django Framework. In case of the Views in Django, it plays the role of the controller. It fetches the data and decides how the data is to be displayed.

===Applications===

In Django terminology, an installation of Django is considered as a “Project”.

The smallest logical subset of files/folders that is fairly independent from the rest of the project can be called as an application. These subset of files include (but are not limited to) models, views, templates, static files, URLs, etc. A single Django project can have multiple applications, each of which contains the files that define an application.

All the applications that must be included inside the main project should be explicitly mentioned inside the variable <code>INSTALLED_APPS</code> inside the <code>settings.py</code>.

<pre>INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'books'
)</pre>

=== Models ===

In Django, a model is defined as the single source for all the data. It defines how data is accessed, processed and validated. It also contains the structure and relationship of all the data that is used by the application. Models are used to define the structure of your database. Each model is converted into a database table and each attribute inside a model is converted into a column of that table. All this is handled by Django implicitly.

Consider the following example about an application called ‘books’ that contains:
:*Author: which has a first_name and last_name attributes
:*Book: which has title, author and publication date as its attributes

We can write models for the above application like:

<pre>class Author(models.Model):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=40)

class Book(models.Model):
title = models.CharField(max_length=100)
authors = models.ManyToManyField(Author)
publication_date = models.DateField()
</pre>

Once all the models for your application have been created, you can validate them by using:
<pre>python manage.py validate <app_name></pre>
Django also dynamically generates “Create Table” statements for each of these models. These statement can be viewed using the command:
<pre>python manage.py sqlall <app_name></pre>
The above command would give the following output:
<pre>BEGIN;
CREATE TABLE "books_author" (
"id" serial NOT NULL PRIMARY KEY,
"first_name" varchar(30) NOT NULL,
"last_name" varchar(40) NOT NULL,
)
;
CREATE TABLE "books_book" (
"id" serial NOT NULL PRIMARY KEY,
"title" varchar(100) NOT NULL,
"publication_date" date NOT NULL
)
;
CREATE TABLE "books_book_authors" (
"id" serial NOT NULL PRIMARY KEY,
"book_id" integer NOT NULL REFERENCES "books_book" ("id") DEFERRABLE INITIALLY DEFERRED,
"author_id" integer NOT NULL REFERENCES "books_author" ("id") DEFERRABLE INITIALLY DEFERRED,
UNIQUE ("book_id", "author_id")
)
;
COMMIT;
</pre>
and all the tables would be created immediately as soon as you run the command stated below:
<pre>python manage.py syncdb</pre>

=== Views ===
The front-end of the web-application is equally important as the model and the controllers. The basic function of the view is to accept an HTTP request and send a response. Basically Django has two types of views – Generic Views & Class based views. Generic views just take one parameter – “request”. Following is the format of the code to display Hello World.

<pre>
from django.http import HttpResponse
def hello_world(request)
return HttpResponse(“hello world”)
</pre>

Here, the method class hello_world has a parameter called “request”. This is the parameter that contains all the information of the HttpRequest. After the request has been processed, the HttpResponse object is returned back. This HttpResponse object is initialized with the string “hello world”.

Generic views mostly consist of functions. Maintaining a program with a lot of functions is difficult. This reduces the modularity of the program. In order to support classes, Class based views were introduced. Class based views consist of classes which handle all the functionality in the front end. Classes are extensible and hence reusable. We can inherit different views(classes) and include it in our class. For example, if we want to include a view which displays the contacts, we will write the following code.

<pre>from django.views.generic import ListView
from books.models import contacts
class ContactsList(ListView)
model = contacts
</pre>

In the above program, we have imported the ListView from the generic module. As we want to display the contacts from the database, we have imported the database “contacts”. The class ContactsList inherits the ListView class and extracts all the functionality in that class. The “contacts” database is imported and assigned to the model so as to display the contacts in the form of a list view.

Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function.
Just making the views is not enough. We need to map the views with the URL requests. This is done in the URLConf file – <code>urls.py</code>. It basically acts like a routing table to route the URL requests to the appropriate method call in the view. Suppose we want to make Django aware that the function <code>hello_world()</code> is actually a view function. In order to do that, we will have to write the following code:
<pre>
from django.conf.urls.defaults import patterns, include, url
from hellworldproject.views import hello
urlpatterns = patterns(‘’. url(r’hello_world/$, hello_world)
</pre>

In the above code, the “pattern” function saves the required URL pattern in the “urlpatters” attribute.
So, after everything is set up, we run our web application with a url say <code>[web-address]/hello_world/</code>. Now, Django first goes to the <code>settings.py</code> file in the project directory and searches for the files which handles the URLConf part. Suppose the name of the files is <code>urls.py</code>. It dives into the urls.py files and linearly matches the requested url with the url patterns in the file and checks which method call is responsible to handle the request. After that, when it finds the method(here, hello_world), it passes an HttpRequest object to the method. After the required processing the request, it creates an HttpResponse object and then continues with the further processes the response by converting it into HTML code by adding the necessary formatting to the response in order for it to be displayed as a view on the screen.

=== Templates ===
In Django, templates are generally used to define how webpages of the application are supposed to look like. Template defines the structure of the webpage and also has additional elements that help access variables, run python statements and much more.

Data can be passed to templates which can be used by the templates to display to the user or perform actions on the data and create dynamic views based on the data.

==== Variables ====
We can access any data passed to the templates and use them as regular python variables. The below lines of code shows how variables can be accessed:
<pre>Author: {{author.last_name}}, {{ author.first_name }}</pre>
which will just print the author’s name on the webpage.

==== Tags ====
Templates also provide the ability to write python code inside them and execute them just like they would run inside a <code>“.py”</code> file. These elements are known as tags and look like <code>{% tag %}</code>

Given below is the example of a “for” loop that is defined inside a template:
<pre>{% for book in books_list %}
<li>{{ book.title }}</li>
{% endfor %}</pre>

You can process data (though it is not logical to do so in a template), write conditional statements or just declare variables inside tags and used them later in the template file.

==== Filters ====
Filters in templates can be defined as helper functions. They are a very powerful tool that reduces the code needed for basic (or sometimes even complex) post-processing of data.

For example, the title of a book could be added to your application as one of ‘HARRY POTTER’, ‘HaRrY pOtTeR’ or ‘harry potter’. To standardize the format of the book title which you want to show on your website, we can simply write
<pre>{{book.title|title }}</pre>
which capitalizes the first character of each word and turn all other characters to lower.

Django also provide the ability to write custom filters and make it available to all the templates in your application. Django provides template tags and filters to control internationalization in templates. They allow for granular control of translations, formatting, and time zone conversions.

=== Admin Site ===
For a certain class of Web sites, an admin interface is an essential part of the infrastructure.

This is a Web-based interface, limited to trusted site administrators, that enables the adding, editing and deletion of site content. So the admin site has to authenticate users, display and handle forms, validate input, and so on. But the best part about Django is that it does all of this and more for you – in just a few of lines of code. This is also one of the reasons why Django is called a “heavy” web development framework.

To access the Django admin interface, we just have to add <code>/admin</code> to your project url.

[[File:Admin01.png|frame|center|alt = This is the login page of Django Admin Site|Django Admin site login page]]

We would also have to create a superuser, which can be done by following the steps given below.
<pre>$ python manage.py createsuperuser</pre>
Enter the admin username and email address:
<pre>Username: admin
Email address: admin@example.com</pre>
Choose the password for the admin account:
<pre>
Password: **********
Password (again): *********
Superuser created successfully.</pre>

[[File:Admin02.png|frame|center|alt = The default first page of the admin site|Default admin site home page]]

Django contains a file called <code>admin.py</code> where you can define models for the admin site and then enable them so that they will appear on the admin site.
Using the example of the Author Model described in the sections above, let us add it to the admin site:
<pre>
class AuthorAdmin(admin.ModelAdmin):
pass

admin.site.register(Author);
</pre>

These out-of-the-box features of the Django framework is what makes it the perfect option for creating content driven websites in relatively no time at all.

== Features ==
Django has the following features to name a few:
:*It facilitates developers with a template comprising minimal number of classes, modules, packages etc. so that the developers can focus more on the core business logic.
:*It contains an ORM (Object-Relational Mapper) that allows for the use of standard Python language. The developers need not learn any query processing language.
:*It provides with a template framework suitable for making the views.
:*It supports pluggability – that is it supports including other installed applications into your own application.
:*It has a built in administrative interface to manage the web application from an administrative level, thus providing access control.
:*It is multi-lingual
:*It supports a very useful Geographical web framework "GeoDjango"<ref>https://docs.djangoproject.com/en/1.6/ref/contrib/gis/</ref>

== Comparison with other web frameworks ==
=== Django vs Ruby on Rails ===
Most of the differences lie in the way the MVC pattern is interpreted by both the frameworks.<ref>https://bernardopires.com/2014/03/rails-vs-django-an-in-depth-technical-comparison/</ref>

==== Models:====
Everything in Ruby on Rails is based on migrations. If at any point of time, the schema of the database is changed and if it has to be reverted back to the previous schema then we can do that with the help of migrations. In case of Django, we need to depend on a third-party extension “South” (until Django 1.6) to support migrations.

==== Controllers: ====
Django considers the entire framework as the controller but Ruby on Rails has a separate entity called controllers that manage the task of interpreting the user interactions and routing to the correct method that handles the request. That is why Django is said to follow the MVT(Model View Template) framework and Ruby on Rails strictly follows MVC framework.

==== Views: ====
In Django, the amount of code that can be pushed into the views(i.e., the template) part of the application is very stringent. Only basic codes like conditional statements and simple loops are allowed. As the controller objects are not really accessible in the views, not much of the manipulation can be done in the views section of the application. This enforces a strict modularity between the models, views and templates section in the Django application making the application maintenance easier. In case of Rails, as the controller objects are accessible in the views as well, a lot of unnecessary calculations can be included in the views. This reduces modularity in the application. Thus, Django has an upper hand over Rails for this reason.

==== Other Features ====
Django has in-built features like User authentication and admin support in its web applications. This makes developing admin based web application very easy. There is no such thing in Rails as such.

== References ==
<references/>