Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revamp "Continue: Web Applications in Racket" #131

Open
sorawee opened this issue Nov 11, 2023 · 1 comment
Open

Revamp "Continue: Web Applications in Racket" #131

sorawee opened this issue Nov 11, 2023 · 1 comment

Comments

@sorawee
Copy link
Contributor

sorawee commented Nov 11, 2023

Here's a list of improvements that I wish to see:

Better spacing

The following image shows one of the issues.

Screenshot 2023-11-11 at 9 58 58 AM

There's too much space before the box, and not enough space after the box.

Consistent usage of contract

There's a weird mix of HtDP-style signature and actual Racket contract throughout the tutorial, which is confusing. We should pick one style and use it consistently.

Slightly off-topic, but while I know that the tutorial's target audience is readers of the first edition of HtDP, I'm not sure if that makes sense anymore.

Use appropriate tags

Several @tt should have been @litchar.

Linkify code

All links under #lang web-server/insta are broken.

Consistent naming

Right now, functions whose name is prefixed with render- are used in two different ways: they might return an xexp/c or a response?. It would be nice to make things consistent. Perhaps make-XXX-request for functions that return response? and render-XXX for functions that return xexpr/c?

Avoid "request" as an argument name.

This is to avoid incorrect linkified text.

@sarna
Copy link

sarna commented Nov 12, 2023

One aspect that confuses me: the tutorial uses functions from web-server/http/bindings (request-bindings, extract-binding/single, etc.) Meanwhile, the docs for this module effectively say these functions are deprecated:

These functions, while convenient, could introduce subtle errors into your application. Examples: that they are case-insensitive could introduce an error; if the data submitted is not in UTF-8 format, then the conversion to a string will fail; if an attacker submits a form field as if it were a file, when it is not, then the request-bindings will hold a bytes? object and your program will error; and, for file uploads you lose the filename. Therefore, we recommend against their use, but they are provided for compatibility with old code.

If you recommend against their use, why are they in the tutorial?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants