Lecture 10 -- JavaScript; Cookies

November 3rd, 2009.

Testing: test_apps

Everyone who finished & handed it in did a good job, from what I could see. I want to show you one in particular... see


What's the problem? Multiple tests in one test function:

  • don't see results from test in isolation: first 'subtest' to break ends the tests.
  • contaminated state: what's in wsgi.input?

Can refactor to use setup/teardown to handle that, and separate into multiple functions.


Does anyone have any comments on the Next 6 Weeks document yet? Be sure to e-mail them to me, negative or positive.



Language in the browser.

two basic types of functions:

  • affecting look/feel, doing form validation (dynamism within site)
  • loading data from elsewhere

Good JS tutorial: http://www.w3schools.com/js/default.asp

JavaScript != Java. In fact, they're completely different.

JavaScript == ECMAScript.

JavaScript adds "behavior" to Web pages:

  • dynamic text
  • events
  • data validation
  • cookie creation

Object oriented, dynamic, in-browser scripting language.


<script type="text/javascript">
document.write("Hello World!");


JS factoids:

Dynamic. Interpreted.


Return of the semicolons!!

Return of the squigglies: { } used to denote blocks

// - C++ like comments /* */ - C like comments

Loosely typed:

var x

is now a variable.

No need to declare a variable, either. (But it's "good practice")

C-like operators (addition, subtraction, etc.) and comparisons (<, >, ==).

Logical operators are also C like -- "||", "&&"

Strings + numbers => strings.

Return of the round brackets:

if (condition) { block to be executed }

Object-oriented, but in a weird way: "bag of properties" with methods!

function some_function(...) {
   ... can reference 'this.foo' ...

function SomeClass(param1) {
   this.foo = param1;
   this.method = some_function;

var some_object = new SomeClass("fib");


(Can do 'for (property in object)' to iterate over properties, incl method)

Function declaration:

function name(var1, var2, ...) { block }

For loops as in C: for (var = starval; var < endval; var = var + inc) { }

While: while (condition) { ... }

do-while: do { ... } while (condition);


for-in: for (variable in object) { ... } - loops through array, or properties of an object.

JS properties on HTML elements:

onload and onUnload
onFocus, onBlur
onMouseOver and onMouseOut


try { ... } catch (x) { ... use x ... }

throw can throw any type of object, which can then be caught & used.

Object model

  • properties
  • methods


useful classes: String, Date, Array, Boolean, Math, RegExp

Accessing the Document Object Model (DOM):

 function change_title() {
     var x = document.getElementById("my_input");
     document.write('my value is ' + x.value);
     document.title = x.value;

document.write("The title is: " + document.title + "<p>");


New title: <input type="text" id='my_input'>
<input type="submit" value='change title' onclick='change_title()' >


Practical issues

JS code in <head> of document guaranteed to be executed before anything in <body>.

Can load scripts from elsewhere:

<script src='hello.js'></script>

JavaScript security: sandbox model.


Running arbitrary programs written by other people on your local computer is dangerous (duh).

For example, JS could redirect your page to your bank's login page, intercept your username and password and send them to someone else while logging you into your bank site, and then unload itself. Yay, your bank account for everyone!

(I'm not kidding.)

Sandbox model prevents this.

No access to local file systems, user data, or network capabilities, either. (Exception to this discussed next week, "AJAX")

"Same-Origin policy" - scripts loaded from one Web site cannot access data from pages loaded from another Web site.

var w = window.open("http://www.google.com");

// Now wait a while, hoping they'll start using the newly opened window.
// After 10 seconds, let's try to see what URL they're looking at!

var snoopedURL;
setTimeout("snoopedURL = w.location.href)", 10 * 1000);

(Can still reference external scripts, which will come in handy next week.)

What about "site farms", e.g. the CSE user accounts? Yes, 'www.cse.msu.edu' counts as the same site, so my Web page vs your Web page can do nasty things to each other.

Also, cross-site scripting (XSS) becomes an interesting problem... examples in a few weeks.

Can also bomb browsers:

  • infinite loops
  • memory hog
  • infinite recursion of frame elements
  • annoyances! (popup windows, etc.)

This is why Google Chrome runs browser tabs in different processes!

Concluding thoughts on JavaScript-the-language


(Taken without apology from: http://www.phonk.net/Gedachten/JavaScript)

JS can make Web pages and forms behave very differently from user expectations. One of the big reasons that the Web was adopted so quickly is that the user interface is relatively straightforward and simple; JS can change that. It also means that in order to write an interesting Web site you need to become a UI designer, too, and frankly most programmers suck at UI design.

Content generation via JS can make it more difficult to "reduce" Web pages into searchable archives of information.

Scripting JS-heavy Web pages gets quite ugly, as you'll see with Selenium next week.

Tying behavior into the browser so closely makes it difficult to build browser-neutral and platform-neutral sites (think mobile phones). The solution seems to be to build bigger & more powerful cell phones :)

It's easy to hack stuff together in JS, but to build anything big requires Real Programming.

JavaScript security is always something to think about.


JS removes (or, with AJAX, reduces) the latency inherent in having to do a page request to a remote server by putting the behavior on the page.

It's the only cross-platform cross-browser solution to doing this, and (unlike Flash) it's also open source, so you can go reverse-engineer other people's Web pages. (Definitely good for the growth of the Web!)

You guys already know how to program, so the Real Programming requirement isn't a problem for you.

Transferring information across multiple requests


  • cookies
  • carrying within URL
  • carrying within each form on page
  • going by IP address
  • ???



'Cookies' are bits of data ("morsels") that are set by the server on a particular path, stored client-side, and sent to the server whenever that path is hit by the client.

So, for example, your browser could have a cookie linked to

server 'google.com'

and every time you went to 'http://google.com', your browser would send that cookie in the headers.

Cookies are the basic mechanism used for retaining user authentication and storing small pieces of information in a user's browser.

To set a cookie, the server issues a 'Set-Cookie' header as part of its response to a client's HTTP request. In the response headers, then, you might see:

Set-Cookie: user=foo

If the client supports cookies, then any further requests -- now or later -- to the same server should result in the client sending the cookie back to the server. So, in the client headers sent with each request, you would expect to see:

Cookie: user=foo

This allows the server to link state across multiple requests without encoding it in the URL or in form variables. The benefits of this approach are that it carries across IP addresses and connections, and can be specific to each account or user on a computer.

Servers can specify additional cookie metadata like an expiration date (via the 'Expires' tag) and a limiting path on the server (via the 'Path' tag)

Cookies are the primary way that Web servers track user information across visits.

One question to ask: what prevents users from simply fabricating their own cookies in their own browser? (Nothing! The client has complete control over the client cookies.) We'll talk about how to deal with that later.)

Message board design, brainstorming

What are the essential components of a message board?