Flask session plan

[darrenvong]

Here's a rough structure of how I'm thinking the session and a half should go:

Beginning of Session 3 and 4

• Quickly go through my challenge of the week
• Brief recap on contents covered from session 2/3

Session 3

Before we go into the technical details on how to use Flask, cover:

• Why do we need/use a server?
  • A server is used so we can share our application with the world (over the Internet)
  • (Links to those who did the beginners course) I believe they used GitHub pages? Quickly explain that their (static) HTML pages are actually being served over the GitHub server, hence they can see their project publicly online.
  • A run through of what actually happens when we visit a website. This should be fairly high level which covers the request-response cycle. Include a diagram to help the explanation. The explanation should go along the lines of:
  • When we type in a web address in our browser, we are actually sending a (GET) request to a server running the website you want to visit;
  • Based on the address we typed, the server uses this information and sends back a response containing the relevant page's HTML to our browser;
  • Our browser processes the response HTML, along with any CSS and JavaScript, and renders out the pretty web pages that we see (this is typically when we see the page stops loading).
• What is Flask? Why do we use it?
  • Flask is a framework - a set of code written by somebody else that we can re-use
  • It's better to use Flask's code rather than writing our own as the code handling requests and responses are actually quite complicated!
  • So, by re-using Flask's code, it deals with said complex tasks for us and allows us to jump straight to building the interesting parts of our application

Now, the technical part:

• Live code together the very first, basic Flask app

  • Explain the code line by line as we type them together, HackIntyre style :wink:
  • It will do no more than just returning "Hello, #ShefCodeFirst students" or something when visiting "/"
  • Run the script with the usual python app.py command in the terminal (assuming we named our file app.py)
  • Visit localhost:5000 and they should be able to see "Hello, #ShefCodeFirst students" in their browser
  • Visit some random link like localhost:5000/ihf to show that it will lead to an error, since we haven't defined how to handle requests for ihf

• Follow up with an example which takes a URL parameter (similar to "arguments" mentioned in Python). E.g. a function with @app.route("/<name>") above will capture "darren" in the variable name if localhost:5000/darren is typed in the browser

Ignore the part in the curriculum note which says that we need to control-c and restart our server. It's wrong. With debug=True, Flask restarts the server automatically when it detects code changes.

• Set up a typical Flask app folder structure together

  • Each app should have a static folder where CSS, JavaScript and other resources (images, videos) are placed
  • It should also have a templates folder, where the HTML files go

• Linking up a basic HTML template together

  • Instead of returning texts as in previous parts, return a HTML template instead using the render_template function
  • Access data passed through the render_template function from Python in the templates

Session 4

Picking up from where we left off from the previous session, before we dive into the technical details:

• What is a template engine? Why do we use it?

  • Traditionally, web pages have been served as static HTML files - this is essentially what the girls learnt if they did the beginners course
  • However, it becomes tedious when each page has to be written from scratch even though there might be only be tiny changes. Templating helps to solve this as we already have the basic structure laid out. All that's left to do is for us to "fill the gap" with data coming in with the request.
  • Writing every HTML files by hand also becomes difficult when we don't know what the content are ahead of time. Facebook and Twitter are good examples where the feed is different for everyone depending who they are friends with/following etc...

• Routing?

  • The process of binding an URL to a specific function which will handle the request
  • Flask uses relative URLs - this is usually the string inclusive of the first single slash.
  • Relative URLs are used so that they work in a consistent way no matter where the application is hosted
  • /hello therefore can be accessed by <hostname>:<port_number>/hello

• POST requests

  • First, more on requests. In the last session, we said that when typing a web address in our browser, we are actually sending a GET request to the server running the website.
  • Problem with GET request: any extra data you send along are visible in the web address. This isn't very good when you are sending over sensitive data like your password to log in to Facebook!
  • To solve this problem, browsers send data to servers using a different kind of request known as a POST request

Now, the technical details:

• Sending data from HTML template back to Python
  • Update the HTML template to include a form
  • Remember to import request from Flask!
  • Maybe show a demo of what happen when submitting data with a form using a GET request to clarify
  • Define another function which can handle the GET requests about to be sent by the form
  • Update form method to use POST
  • Update decorator ("magic function") above function to handle POST requests instead
  • In both cases, use the request.value convenience CombinedMultiDict from Flask to grab data from requests to ease confusion!
• More usage of the Jinja2 HTML template
  • Show good practices like breaking down common HTML parts across all pages (headers/footers) of a typical website into separate template files?
  • Then use {% include "header.html" %} etc to load it into main page HTML template
  • Alternatively, seems to be recommended by the official Jinja2 guide, have a "base" template which basically contains the common bits (headers, footers etc) with blocks that can be replaced by page specific templates?

[darrenvong]

Just finished writing up a rough plan for the next two sessions... It's ended up a lot longer than I expected :joy:

Tagged you in as well @paulienuh since you're the pro of the Beginner's course. Do all of these make sense/will this structure transition well for those who have done the course?

[darrenvong]

Also @cgmcintyr when you have recovered from HackNotts and have a moment, take a look! :)

[trallard]

Ignore the part in the curriculum note which says that we need to control-c and restart our server. It's wrong. With debug=True, Flask restarts the server automatically when it detects code changes.

It might be worth pointing out that this is the case and that the debug=True enables live update of the app

Also

Show good practices like breaking down common HTML parts across all pages (headers/footers) of a typical website into separate template files?

I think this would be the best approach given the fact that most of them have not done the beginners course... IMO only, you're the boss here @darrenvong

[darrenvong]

Thanks for the feedback @trallard! I agree that the breaking down into parts pattern is probably the better route to go - the idea that this will then lead to re-usable bits seem more intuitive!

The base template then inherit style might be a bit confusing if not covered well, considering we won't really be doing anything Object Oriented related...

[pawlean]

Just wanted to say that after seeing the slides, I really liked how you've laid this out @darrenvong! A huge improvement from last year's for sure - I'll be sitting in and working through it myself too!

[darrenvong]

Hmm just gonna reopen this before session 4 is done so I can quickly find it :blush:

[darrenvong]

Still need to cover Sending data from HTML template back to Python part, otherwise we should be good to move forward...

[trallard]

So what is actually missing?

Did you cover the other way around from Python to the HTML template?

[darrenvong]

@trallard Yes, that was covered in session 3. The main things we haven't covered yet include:

• How to make a form in HTML to send POST requests;
• How to modify the decorator above a Python function to handle POST requests, and;
• How to retrieve data sent from the form on the Python (Flask/server) side.

It really should have been done and dusted in the last session, but sadly it went quite far off plan... 😭

[trallard]

Is all of the material for the missing bits in the repo now?

[darrenvong]

All the bits I've prepared are there, although I think @cgmcintyr has some additional slides when he quickly gave an overview on HTTP requests towards the end of the last session.

I've also slipped in forms in this week's challenge (tough to set one when we practically did nothing...), so if the girls engage with it then they should have an awareness of it by next session.