Starting from:
$30
WEB-Project 4 Rendering Data using Mustache Solved
You are being provided with an index.js which provides the required commandline behavior to start the program:
./index.js PORT SENSORS_WS_BASE_URL where the arguments are:
PORT This required argument is the port at which the program listens for web requests.
SENSORS_WS_BASE_URL This required argument is the url specifying web URL at which an instance of the sensors web service from Project 3 should be running.
[In order to facilitate automated testing, all UI controls and result values are required to be labelled by HTML class names starting with the pre x tst-. In the requirements which follow, a mention of a name starting with tst- means that the relevant control or value must be labelled by that class.]
What you speci cally need to do is add code to the provided sensors.js such that your server displays the following pages:
Home Page at URL / This page should display links to the following pages:
• Sensor Types Search Page tst-sensor-types-search.
• Sensor Type Add Page tst-sensor-types-add.
• Sensors Search Page tst-sensors-search.
• Sensors Add Page tst-sensors-add.
Sensor Types Search Page This page must be identi ed by having any element with class tst-sensor-types-search-page. It should have two sections:
• A search form for sensor types allowing searching by all sensor type elds excepts the limits elds. (see below).
• A results section showing the results delivered by the underlying web service from the last search. Initially, the page should show the results of doing a sensor types search with all elds empty.
Sensor Types Add Page This page must be identi ed by having any element with class tst-sensor-types-add-page. It should contain a form allowing the user to specify values for all sensor type elds (see below). Successful submission of this form should create or update a sensor type using the underlying web service and transfer control to the sensor types search page set up to show the results for the sensor type just created or updated.
Sensors Search Page This page must be identi ed by having any element with class tst-sensors-search-page. It should have two sections:
• A search form for sensor types allowing searching by all sensor type elds excepts the expected elds. (see below).
• A results section showing the results delivered by the underlying web service from the last search. Initially, the page should show the results of doing a sensors search with all elds empty.
Sensors Add Page This page must be identi ed by having any element with class tst-sensors-add-page. It should contain a form allowing the user to specify values for all sensor elds (see below). Successful submission of this form should create or update a sensor using the underlying web service and transfer control to the sensor search page set up to show the results for the sensor just created or updated.
The results section shown for the above search pages should contain a maximum of 5 sets of results. Additionally, each set of results should show links for the next (tst-next) or previous (tst-prev) set of results, if applicable.
All of the above pages except the home page must contain a footer having links to the above pages with classes tst-home, tst-sensor-types-search, tst-¬ sensor-types-add, tst-sensors-search and tst-sensors-add respectively.
1.2.1 Sensor Type Fields
Sensor types have the following elds:
Sensor Type ID tst-sensor-type-id Uniquely identifying a sensor type. Can only contain alphanumerics, - or _ characters.
Manufacturer tst-manufacturer Can contain only -, ’, space or alphabetic characters.
Model Number tst-model-number Can contain only -, ’, space or alphanumeric characters.
Quantity tst-quantity Can only have internal values temperature, pressure, flow or humidity.
Minimum Limit tst-limits-min A number.
Maximum Limit tst-limits-max A number.
Note that there is no eld specifying the units for the limits. Instead, the application should ensure that an appropriate unit is sent to the web service based on the speci ed quantity: gpm for flow, % for humidity, PSI for pressure and C for temperature.
1.2.2 Sensor Fields
Sensors have the following elds:
Sensor ID tst-sensor-id Uniquely identifying a sensor. Can only contain alphanumerics, - or _ characters.
Model tst-model Can contain only alphanumerics, - or _ characters.
Period tst-period Must be an integer.
Expected Minimum tst-expected-min A number.
Expected Maximum tst-expected-max A number.
1.2.3 Error Handling
Invalid form input should result in the program re-displaying the form with suitable error messages. The redisplayed form input should retain its previous contents. It should also display any errors resulting from the underlying web services. Each error message must have HTML class error.
1.2.4 Implementation Restrictions
You must use mustache for rendering all templates. However, you may use any npm modules you nd useful; in that case, your submission must be set up so that npm ci downloads all the necessary modules.
In this project, all your code must run only on the server; you cannot run any code within the browser.
1.2.5 Look-and-Feel
There are no restrictions on the look-and-feel of the pages.
1.3 Working Project
A working version of the project is available at <http://zdu.binghamton.edu:2346 (note that this URL will work only from within the CS network).
[It does have a few rough edges which may be xed (for example, handling of empty results is not always intuitive for the end user). Please report any problems which seem serious].
1.4 Provided Files
The prj4-sol directory contains a start for your project. It contains the following les:
sensors.js This le will constitute the guts of your project. It should export a function which starts a web server on the port speci ed by its rst argument and use the web services wrapped by the wrapper object speci ed by its second argument.
sensors-ws.js This provides a wrapper object which wraps the Project 3 web services. The provided index.js creates an instance of this wrapper object and injects it into your sensors server. You should not need to change this le.
index.js This le provides the complete command-line behavior which is required by your program. It requires sensors.js and sensors-ws.js. You must not modify this le.
After validating the command line arguments, it instantiates an instance of the web service wrapper using the web service URL provided on the command line. It then calls the function exported by sensors.js passing it the port speci ed on the command-line and the instance of the web service wrapper.
widget-view.js This le provides a function which takes a JavaScript object and translates it into a view object which can then be rendered using the widget.ms mustance template. Its usage is described by comments within the le and built-in tests.
widget.ms A mustache template to render a view object created by widgetview.js.
mustache.js Provides a wrapper object which renders a view using a mustache template. Usage is documented in the le.
style.css A CSS stylesheet to provide styling to the project pages. Most of the style rules use only HTML element selectors but a few of them use classes. The use of these classes should be clear by examining the source of the pages rendered by the sample solution (CS-network only).
./index.js PORT SENSORS_WS_BASE_URL where the arguments are:
PORT This required argument is the port at which the program listens for web requests.
SENSORS_WS_BASE_URL This required argument is the url specifying web URL at which an instance of the sensors web service from Project 3 should be running.
[In order to facilitate automated testing, all UI controls and result values are required to be labelled by HTML class names starting with the pre x tst-. In the requirements which follow, a mention of a name starting with tst- means that the relevant control or value must be labelled by that class.]
What you speci cally need to do is add code to the provided sensors.js such that your server displays the following pages:
Home Page at URL / This page should display links to the following pages:
• Sensor Types Search Page tst-sensor-types-search.
• Sensor Type Add Page tst-sensor-types-add.
• Sensors Search Page tst-sensors-search.
• Sensors Add Page tst-sensors-add.
Sensor Types Search Page This page must be identi ed by having any element with class tst-sensor-types-search-page. It should have two sections:
• A search form for sensor types allowing searching by all sensor type elds excepts the limits elds. (see below).
• A results section showing the results delivered by the underlying web service from the last search. Initially, the page should show the results of doing a sensor types search with all elds empty.
Sensor Types Add Page This page must be identi ed by having any element with class tst-sensor-types-add-page. It should contain a form allowing the user to specify values for all sensor type elds (see below). Successful submission of this form should create or update a sensor type using the underlying web service and transfer control to the sensor types search page set up to show the results for the sensor type just created or updated.
Sensors Search Page This page must be identi ed by having any element with class tst-sensors-search-page. It should have two sections:
• A search form for sensor types allowing searching by all sensor type elds excepts the expected elds. (see below).
• A results section showing the results delivered by the underlying web service from the last search. Initially, the page should show the results of doing a sensors search with all elds empty.
Sensors Add Page This page must be identi ed by having any element with class tst-sensors-add-page. It should contain a form allowing the user to specify values for all sensor elds (see below). Successful submission of this form should create or update a sensor using the underlying web service and transfer control to the sensor search page set up to show the results for the sensor just created or updated.
The results section shown for the above search pages should contain a maximum of 5 sets of results. Additionally, each set of results should show links for the next (tst-next) or previous (tst-prev) set of results, if applicable.
All of the above pages except the home page must contain a footer having links to the above pages with classes tst-home, tst-sensor-types-search, tst-¬ sensor-types-add, tst-sensors-search and tst-sensors-add respectively.
1.2.1 Sensor Type Fields
Sensor types have the following elds:
Sensor Type ID tst-sensor-type-id Uniquely identifying a sensor type. Can only contain alphanumerics, - or _ characters.
Manufacturer tst-manufacturer Can contain only -, ’, space or alphabetic characters.
Model Number tst-model-number Can contain only -, ’, space or alphanumeric characters.
Quantity tst-quantity Can only have internal values temperature, pressure, flow or humidity.
Minimum Limit tst-limits-min A number.
Maximum Limit tst-limits-max A number.
Note that there is no eld specifying the units for the limits. Instead, the application should ensure that an appropriate unit is sent to the web service based on the speci ed quantity: gpm for flow, % for humidity, PSI for pressure and C for temperature.
1.2.2 Sensor Fields
Sensors have the following elds:
Sensor ID tst-sensor-id Uniquely identifying a sensor. Can only contain alphanumerics, - or _ characters.
Model tst-model Can contain only alphanumerics, - or _ characters.
Period tst-period Must be an integer.
Expected Minimum tst-expected-min A number.
Expected Maximum tst-expected-max A number.
1.2.3 Error Handling
Invalid form input should result in the program re-displaying the form with suitable error messages. The redisplayed form input should retain its previous contents. It should also display any errors resulting from the underlying web services. Each error message must have HTML class error.
1.2.4 Implementation Restrictions
You must use mustache for rendering all templates. However, you may use any npm modules you nd useful; in that case, your submission must be set up so that npm ci downloads all the necessary modules.
In this project, all your code must run only on the server; you cannot run any code within the browser.
1.2.5 Look-and-Feel
There are no restrictions on the look-and-feel of the pages.
1.3 Working Project
A working version of the project is available at <http://zdu.binghamton.edu:2346 (note that this URL will work only from within the CS network).
[It does have a few rough edges which may be xed (for example, handling of empty results is not always intuitive for the end user). Please report any problems which seem serious].
1.4 Provided Files
The prj4-sol directory contains a start for your project. It contains the following les:
sensors.js This le will constitute the guts of your project. It should export a function which starts a web server on the port speci ed by its rst argument and use the web services wrapped by the wrapper object speci ed by its second argument.
sensors-ws.js This provides a wrapper object which wraps the Project 3 web services. The provided index.js creates an instance of this wrapper object and injects it into your sensors server. You should not need to change this le.
index.js This le provides the complete command-line behavior which is required by your program. It requires sensors.js and sensors-ws.js. You must not modify this le.
After validating the command line arguments, it instantiates an instance of the web service wrapper using the web service URL provided on the command line. It then calls the function exported by sensors.js passing it the port speci ed on the command-line and the instance of the web service wrapper.
widget-view.js This le provides a function which takes a JavaScript object and translates it into a view object which can then be rendered using the widget.ms mustance template. Its usage is described by comments within the le and built-in tests.
widget.ms A mustache template to render a view object created by widgetview.js.
mustache.js Provides a wrapper object which renders a view using a mustache template. Usage is documented in the le.
style.css A CSS stylesheet to provide styling to the project pages. Most of the style rules use only HTML element selectors but a few of them use classes. The use of these classes should be clear by examining the source of the pages rendered by the sample solution (CS-network only).
1 file (20.7KB)
