Oct 1 | Forms; a to-do app

TL;DR#

Today closed HTML and CSS with forms, then started JavaScript: your agent built a to-do app, and you listed the parts of js/todo.js you do not recognize. Next Tuesday starts from those lists. The habit worth keeping: before you type anything into a form, look at where it sends the data and how.

Before next class#

Your second conversation with your client, for Mini Project 1. Record it in FEEDBACK.md in your Mini Project 1 repo, and put the features you have not built yet, in the Later section of your PRD.md, in the order your client ranks them. How to run it. Before you build their changes, consider writing a DESIGN.md with Design Direction.
Mini Project 2 opens Tuesday 10/06 at the start of class.
Push your work from today to your oim3690 repo: contact.html, and the to-do app as your agent wrote it (todo.html, css/todo.css, js/todo.js).
logs/wk05.md on GitHub by Sunday 10/04, with your list under exactly this heading:
```
## JS I Don't Understand (from the To-Do App)
```

Checkpoint 3 closes Sunday 10/11 and lists all of these.

Where a form sends your data#

A form has two attributes that decide what happens on Submit: action is the address the data goes to, and each input's name is the label its value is sent under. With the default method, GET, the values appear in the address bar after a ?.

<form action="https://www.google.com/search">
  <input name="q">
  <button type="submit">Search</button>
</form>

This runs a real Google search, because Google's search page reads a value named q. Amazon's search is https://www.amazon.com/s with a value named k. You can find both by searching on the site and reading the address bar.

The same trick works against you: a form can send what you type to any address its author chose. Before you enter anything personal, right-click the form, choose Inspect, and read its action.

What else the server receives#

The echo form from the forms slides showed the server more than your name: your IP address, an approximate location, your browser and your operating system. That information travels in the request headers and cookies, which your browser adds to every request.

A correction to something said in class: the long string of extra values in a Google search address, after q=, is Google's own tracking of the search session and of your clicks. The information about your computer travels in the headers.

Choosing GET or POST#

	GET	POST
Where the data goes	in the address bar	in the body of the request
Saved in your history	yes	no
Use it for	searching and reading	logins, sign-ups, anything sensitive

In class, a password field submitted with GET put the password in the address bar and the browsing history. Switched to method="post", it stayed out of both.

Small things a form does for you#

type="email", type="number" and type="tel" check the value before it is sent, and on a phone they bring up the matching keyboard.
required stops an empty submit.
Pressing Enter in a field submits the form.
A <label for="..."> makes its text clickable, so clicking the word focuses the field.

If Copilot Chat says your message came through empty#

Delete the lines of three backticks when you paste a prompt copied from a slide. Those lines mark a code block, and Copilot Chat then reads the message as empty.

The cube from the start of class#

The Rubik's cube at the start of class came from one prompt to Claude Code, in about five minutes. Asking it to make the cube "more Babson-ish" only changed the colors; asking it for ideas first gave a list to choose from, and then the agent asked for six campus photos. When you ask an agent for a change, describe the result you want concretely.

Forms; a to-do app

Topic Slides

Agenda Slides Open fullscreen ↗

Post-Class Notes