## What’s going on

• idfk.
• ditching one project
• new grading scale: lowest project worth 5%; others worth 15%.
• proj3 will be a simple static server
• flask, templating, using a basic model
• proj4 will be a full web app
• both sides of the coin
• also Debarun said he’d have proj2 graded by tomorrow (Tuesday)

## Two more model examples

• fl10_flaskr is an extremely simple model-based page
• shows the very basics of using a model to render a page
• there is a single Entry model
• you log in with admin/default
• then you can post stuff
• look at the templates!
• fl11_minitwit is a more complex extension of that
• User and Message models
• users can also follow each other (many-to-many relationship)
• you can register, login, logout, follow, and unfollow
• you can post “tweets” and they appear on your timeline
• tweets from all users appear on the public timeline
• this is something like what your proj3 will be!

## AJAX

• Motivation
• with both those examples, what happens every time you click a link?
• you go to a new page.
• what does “going to a new page” entail for the client?
• the current page is wiped from memory
• a new set of HTML, CSS, JS has to be parsed, represented, and displayed
• media (images, videos etc) must be re-fetched
• this is a stateless protocol, after all!
• what does “going to a new page” entail for the server?
• receive request and route to appropriate function
• then have to re-render an HTML page and respond
• blahhh
• this model of interaction is fine for static pages, but…
• as your app gets bigger…
• as more things are on screen at once…
• it gets more and more frustrating for the user
• and less and less performant for both
• SO…
• don’t reload the page.
• rather than fetching an entirely new page…
• just fetch the data you need from the server.
• once you have the data, the client can do a lot of the work.
• it can manipulate the DOM to display it to the user.
• this technique is known as AJAX.
• Asynchronous Javascript and XML.

## XML?

• well in the 90s/early 00s, there was a big push to use XML.
• it stands for “eXtensible Markup Language”
• basically, it’s a generic version of HTML.
• XML is flexible and can represent any data you like.
• you define a schema - a set of allowed structures
• and then the data is encoded in a text format that looks similar to HTML.
<person>
<name>John Smith</name>
<age>25</age>
<city>New York</city>
<state>NY</state>
<postalCode>10021-3100</postalCode>
<phoneNumbers>
<phoneNumber>
<type>mobile</type>
<number>123 456-7890</number>
</phoneNumber>
<phoneNumber>
<type>office</type>
<number>646 555-4567</number>
</phoneNumber>
</phoneNumbers>
<children></children>
<spouse></spouse>
</person>

• well it kinda sucks.
• it’s textual so that it’s human-readable, editable, and creatable…
• but good lord is that a lot of typing.
• making an XML parser is pretty complex.
• one that understands and enforces schemas even more so.
• XML is still very much widely in use, but for a lot of AJAX scenarios, we’ve switched over to…

### JSON

• it’s a much more natural fit for JS, since the values are a subset of allowable JS objects
• so the same data can be represented as:
{   "name": "John Smith",
"age": 25,
"city": "New York",
"state": "NY",
"postalCode": "10021-3100"
},
"phoneNumbers": [ { "type": "mobile",
"number": "123 456-7890"
},
{ "type": "office",
"number": "646 555-4567"
},
],
"children": [],
"spouse": null
}

• much less typing, and smaller
• smaller! that’s important for client-server communication
• if the server is serving 1000 clients, that can represent a significant bandwidth savings
• typically such JSON is minified - as much whitespace is stripped as possible
• so you’re kinda sacrificing some human readability…
• but there are tools to “prettify” it ;)
• of course, there are downsides
• it’s not typed or structured
• so there’s nothing preventing a buggy client/server putting e.g. a number for the name
• there are attempts to improve this
• okay, so how do we actually communicate the data - XML or JSON - between the client and server

## The JS XMLHttpRequest object

• this is the backbone of it all
• the XML in the name is kinda dumb since it doesn’t have to be XML at all
• so you can think of it as HttpRequest instead
• the XMLHttpRequest object lets JS make HTTP requests without loading a new page.
• these requests happen asynchronously - they do not block the browser and happen in the background
• so let’s look at some example code
let httpRequest = new XMLHttpRequest();
httpRequest.open('GET', 'js15_text.txt');
httpRequest.send();

• well that’s simple enough
• we make an instance
• set up an event handler which will be called when the request completes
• then open it
• and send it
• when the request completes…
• the alertContents function is called
• and it can extract the response from the request object.
• let’s look at 18_ajax.html
• this example may not work in all browsers
• in that case, in the same directory as the example file, do python -m http.server
• then go to its link (0.0.0.0:8000) and click the example file
• this has to do with CORS which we will talk about soon
• we can also send data to the server
• we set a header appropriately:
  req.setRequestHeader('Content-Type', 'application/json');

• and then send the data as an argument to .send():
  req.send("[1, 2, 3]");


## So where is a web app, anyway?

• the logic of the web app can really be split between the client and server any way you like
• the server really must manage the model and ensure its consistency
• but beyond that, there’s a lot of flexibility
• at one extreme…
• there is no AJAX
• all requests done with page reloads
• server does all work of form validation, page rendering etc.
• this is very “web 1.0” and for an example look at peoplesoft
• at the other extreme…
• the server is really nothing but a model API
• it serves empty templates
• and it’s the client which fills those templates in with JS and DOM manipulation
• and this is kinda what we’ll talk about next time, with REST
• the real web app is the friends we made along the way