Lecture 4.1 (Tuesday, Feb. 9)


  • You just turned in A1 (I can't go over solution until late days are over)
  • P1 out, project teams formed
  • You can trade until Thursday with the consent of both groups — just let me know
  • Don't worry about the assessment - if you did it, you'll get the credit. It's just kinda… broken.
  • A0 graded
  • No emoji — sad. Blame TRACS.


Good! Most of you submitted a working solution!

What's up with 7 instead of 5 paragraphs? If you write this:

<p>{{ lipsum(5) }}</p>

Then it turns into this:

<p>Lorem ipsum dolor sit amet…</p>
<!-- 3 more paragraphs -->

It looks like there are 6 <p> elements: the outer one, and then 5 within it. Not what we want — we just want the 5 paragraphs — but still not 7.

So what's up? <p> is an auto-closing element: if you have a <p> open, and you open a new one, the open paragraph is automatically closed (since nested paragraphs aren't a thing that make sense). So we have an empty paragraph, then 5 paragraphs of Lorem Ipsum.

Then, the parser encounters this stray </p> without any paragraph open. The HTML parsing algorithm's recovery figures that there should be a paragraph to close, so it just makes up an empty one, so we have another empty paragraph after the Lorem Ipsum.

That's what's happening. Just writing the following fixes it:

<h1>Assignment 0</h1>
{{ lipsum(5) }}


Programming is hard.

But it's also often simple, and it's a common mistake newer programmers make to think things are more complicated than they really are (and to write more complicated code).

In some ways, the hard thing is figuring out how simple things are.

The things that we are doing may at times be subtle, but they will rarely be super-complicated (except for the intrinsic complexity of the pile of duct tape that is the Internet).

So, when things seem super-complicated, ask: is there a simpler way to think about this?

Good software design principle: the simplest thing that could possibly work.

Seeing this takes practice. I don't know of a better way to achieve it than practice.

Things Working Together

So we saw the sequence diagram last week.

HTTP! Jinja! Python!

What's up with URLs?

They are just strings.

Let's review the model again:

  1. The browser requests the resource at the specified URL
  2. The server returns it
  3. The user clicks a link to load another URL

These things are entirely independent.

We ‘pass’ data from one thing to another entirely within the URL.

Though that's not how I particularly like to think of it.

The page

  • displays content
  • makes actions available

Some of those actions are visiting other pages/sites.


URL syntax review:


We have several parts:

http, the Hyper-Text Transport Protocol
example.com, the server to connect to
5000, the port number (if unspecified, the default is 80 for HTTP)
/wombat, the path to the resource on the server. If no path is specified, the path / is assumed.

Types of URLs

URLs come in 3 primary types:

A complete URL, including scheme and host. These URLs can be identified by the fact that they start with a scheme (sequence of letters followed by :, usually http or https for us). An absolute URL is the only kind of URL that is meaningful outside the context of a particular page.
A URL that starts with a / indicates a URL that is on the same server as the current page, but at a different path. The server-relative URL fully specifies the path (e.g. /static/gitignore.txt references the same resource path, no matter what page on the server uses it).
A URL that doesn't start with either a scheme or / is a relative url that is resolved relative to the URL of the current page.

To resolve a relative URL, do the following:

  1. If the current URL does not end with a / (after inserting the default / for URLs that don't have paths in them), then remove the last path element to obtain a URL for its containing ‘folder’. For example, http://example.com/static/gitignore.txt is in the folder http://example.com/static/.
  2. If the current URL does end in a /, then it is taken to be the folder URL.
  3. Resolve the URL using the current URL. A path element denotes the folder or file with that name in the ‘current’ folder. A path element of .. goes back up one path level.

Some examples follow.

Base URL
Relative URL
  • The base URL does not end in a /, so the last path element (swordfish.html) is removed to yield a ‘folder’ URL of http://aquarium.com/fish/.
  • guppie.html is then resolved within the folder URL.

Base URL
Link URL
  • The base URL ends in /, making it a folder URL
  • fred/ names a folder within that folder URL, yielding http://zoo.org/animals/monkey/fred/

Base URL
Link URL
The relative URL begins in /, making it a server-relative URL, so the entire path of the base URL is discarded and replaced with the relative URL.

Base URL
Link URL
The link URL begins in http://, so it is an absolute URL. No resolution is performed, the URL is visited as-is.

Poke around the class web site for more examples of relative URLs.


HTTP, URLs, basic HTML, basic data structures

  • What are the parts of a URL?
  • How are relative URLs resolved?
  • What are lists and dictionaries for?
  • What does some (basic) code do?
  • How do you access lists, dictionaries in Python?
  • How is HTTP structured? (Requests, responses)
  • How is an HTML document structured?
    • Tags, elements, and attributes
    • Core structure pieces
    • Commonly-used tags
    • Tags that don't use closing elements

Where we're going next

HTML + CSS. More HTTP. Then: storing data!


Start introducing this.