WebFund 2015W Lecture 6: Difference between revisions

From Soma-notes
Created page with "==Topics & Readings== ==Audio & Video== The video and audio for the lecture given on January 21, 2015 are available below: * Video (w/ audio) in [http://homeostasis.scs.car..."
 
LeeCroft (talk | contribs)
No edit summary
 
(One intermediate revision by one other user not shown)
Line 9: Line 9:


==Notes==
==Notes==
<h3>Code from form-demo</h3>
<h4>Forms</h4>
What is a form?
A form is a way of sending information back to the server. A form can be added to an html page using the <code>&lt;form&gt;</code> tag (or simply <code>form</code> in a Jade page). There are two attributes of a form that should be noted:
<ul>
  <li>method: This can be given a value of either POST or GET to specify the request type that the form will send. The distinction is that the POST is meant for submitting some information to the server whereas the GET is typically just to request a resource. In both cases, the server must provide a response.</li>
  <li>action: The path that will be associated with the request.</li>
</ul>
Nested within a form are <code>input</code> tags used to create fields which the user can put data into. When the form is submitted, the data from these input fields is sent to the server. The <code>name</code> attribute of the <code>input</code> is used to distinguish between the different input fields on the server. The “#” sign is used to indicate an ID. When we look at the code inspector in our browser and see <code>&lt;input id= ...&gt;</code> then we know it’s the one specified in the index.jade file.
Instead of using the “GUI” of the form on the web, we could make the send request using the code inspector. It will, of course, be a bit more complicated but it can be done in more than one way.
The code running on your server is controllable by you as an administrator, the problem is in the code running in the web browser of the user since we have no way of knowing what’s happening, so we have to make every possible assumption to keep the code running correctly.
When adding an html button to a web page, it must be placed inside a form to be able to send a request when the button is clicked. The form can then be set up with a method that the developer chooses (such as GET) and the action is where we want to be redirected when we click on the button.
<h5>Example</h5>
<code><pre>
<form method=“get” action=“/“>
  <button type=“submit”>Home</button>
</form>
</pre></code>
The example above will display a button with the text “Home” on it and will take you to the home page once clicked.
<h4>Handling the form request</h4>
Inside the index.js file, the way the web server is set up to handle requests can be seen. The <code>router.get()</code> and <code>router.post()</code> methods are used to do this. For example, <code>router.post()</code> will be used to handle certain post requests which are received. The first parameter of the method tells which request of the specified type should be dealt with. For example, when the parameter is set to "/add", this indicates that the function will deal with post requests for the action "add". The second parameter is a function which is defined inline and specifies what action should be taken for the request. The parameters, "req" and "res" of this function are the request and response objects. The request object contains all data related to the request that was received. Within the "req" object, the data from any input fields of a form that was submitted in the request can be found. As such, The input field for city from the form demo can be accessed through <code>req.body.city</code>.
Note that the <code>router.get()</code> and <code>router.post()</code> methods are run at the time when that file is first required at the startup of the app. The functions which are defined inline (as the second parameter) of them however are not called at that time. They are supplied as the functions to be run when a specific type of request comes in. We have no way to know when and in what order they will actually be run, it depends entirely on the actions of the user. These functions typically end with some type of response returned to the client. This is done using the "res" object. In the web apps seen so far, this is usually done in the form of rendering a Jade template however the data need not be in this form. Any type of data can be given as a response, even plain text.
<h4>Storing data</h4>
In the file “index.js”, state is a variable in the file scope, and it’s an empty array. In JavaScript, we can push and pop elements to and from the array, respectively, so when we say <code>state.push(obj)</code> we’re adding an object <code>obj</code> to the array. But this is not really the most effective way to store data on a server. The usual way to do it is to store the data in a database since databases are known to be very good in concurrency. That is, we can manage multiple connections simultaneously.
<h3>Jade</h3>
Is res.render built-into node?
No it’s not. It is available through the Jade template engine.
When sending a response, we could make a web page directly within the application code and use res.send to send it, but it won't be nice looking code. That’s why we will want to use a webpage template engine in order to make our webpage which will make the code look cleaner. The template engine studied in this course is Jade.
<h3>Debug module</h3>
The debug module lets us print debug messages to the console. In order to do this, the debug module must be loaded into the file in which it is being used with a <code>require</code> call. This module can be downloaded and installed using NPM.
<h3>Node debugger</h3>
Node debugger lets us inspect and debug our code at any point we want in the code. Do not confuse this with the debug module!
<h3>JavaScript side-note</h3>
Take note of the distinction between the purpose of the JavaScript code run on server-side and client-side. The JavaScript code on the server-side is used to run the actual logic needed for the application. The JavaScript code which runs on the client-side (in the web browser) is typically used for user interface-type work. The code on the client-side can run based on user actions which do not require a request to be sent, it is within the web page that they already have. The server side JavaScript on the other hand requires a request to be received in order to initiate some sequence of events (related to the client).

Latest revision as of 03:59, 31 January 2015

Topics & Readings

Audio & Video

The video and audio for the lecture given on January 21, 2015 are available below:

Notes

Code from form-demo

Forms

What is a form?

A form is a way of sending information back to the server. A form can be added to an html page using the <form> tag (or simply form in a Jade page). There are two attributes of a form that should be noted:

  • method: This can be given a value of either POST or GET to specify the request type that the form will send. The distinction is that the POST is meant for submitting some information to the server whereas the GET is typically just to request a resource. In both cases, the server must provide a response.
  • action: The path that will be associated with the request.

Nested within a form are input tags used to create fields which the user can put data into. When the form is submitted, the data from these input fields is sent to the server. The name attribute of the input is used to distinguish between the different input fields on the server. The “#” sign is used to indicate an ID. When we look at the code inspector in our browser and see <input id= ...> then we know it’s the one specified in the index.jade file.

Instead of using the “GUI” of the form on the web, we could make the send request using the code inspector. It will, of course, be a bit more complicated but it can be done in more than one way.

The code running on your server is controllable by you as an administrator, the problem is in the code running in the web browser of the user since we have no way of knowing what’s happening, so we have to make every possible assumption to keep the code running correctly.

When adding an html button to a web page, it must be placed inside a form to be able to send a request when the button is clicked. The form can then be set up with a method that the developer chooses (such as GET) and the action is where we want to be redirected when we click on the button.

Example
<form method=“get” action=“/“>
  <button type=“submit”>Home</button>
</form>

The example above will display a button with the text “Home” on it and will take you to the home page once clicked.

Handling the form request

Inside the index.js file, the way the web server is set up to handle requests can be seen. The router.get() and router.post() methods are used to do this. For example, router.post() will be used to handle certain post requests which are received. The first parameter of the method tells which request of the specified type should be dealt with. For example, when the parameter is set to "/add", this indicates that the function will deal with post requests for the action "add". The second parameter is a function which is defined inline and specifies what action should be taken for the request. The parameters, "req" and "res" of this function are the request and response objects. The request object contains all data related to the request that was received. Within the "req" object, the data from any input fields of a form that was submitted in the request can be found. As such, The input field for city from the form demo can be accessed through req.body.city.

Note that the router.get() and router.post() methods are run at the time when that file is first required at the startup of the app. The functions which are defined inline (as the second parameter) of them however are not called at that time. They are supplied as the functions to be run when a specific type of request comes in. We have no way to know when and in what order they will actually be run, it depends entirely on the actions of the user. These functions typically end with some type of response returned to the client. This is done using the "res" object. In the web apps seen so far, this is usually done in the form of rendering a Jade template however the data need not be in this form. Any type of data can be given as a response, even plain text.

Storing data

In the file “index.js”, state is a variable in the file scope, and it’s an empty array. In JavaScript, we can push and pop elements to and from the array, respectively, so when we say state.push(obj) we’re adding an object obj to the array. But this is not really the most effective way to store data on a server. The usual way to do it is to store the data in a database since databases are known to be very good in concurrency. That is, we can manage multiple connections simultaneously.

Jade

Is res.render built-into node?

No it’s not. It is available through the Jade template engine.

When sending a response, we could make a web page directly within the application code and use res.send to send it, but it won't be nice looking code. That’s why we will want to use a webpage template engine in order to make our webpage which will make the code look cleaner. The template engine studied in this course is Jade.

Debug module

The debug module lets us print debug messages to the console. In order to do this, the debug module must be loaded into the file in which it is being used with a require call. This module can be downloaded and installed using NPM.

Node debugger

Node debugger lets us inspect and debug our code at any point we want in the code. Do not confuse this with the debug module!

JavaScript side-note

Take note of the distinction between the purpose of the JavaScript code run on server-side and client-side. The JavaScript code on the server-side is used to run the actual logic needed for the application. The JavaScript code which runs on the client-side (in the web browser) is typically used for user interface-type work. The code on the client-side can run based on user actions which do not require a request to be sent, it is within the web page that they already have. The server side JavaScript on the other hand requires a request to be received in order to initiate some sequence of events (related to the client).