Hello everyone,
before we continue with a complete example, I’d like to pause for a moment and look at one single building block in isolation:
the HTML form.
This is exactly the point where many developers coming from FiveWin start to get confused, because it looks like a button should “do something”.
In the web world, it doesn’t.
A form contains no logic.
A submit button executes no code.
It only creates a request.
To make this as clear and readable as possible, I’ll show the form block using a Harbourino-style structure.
This is not a framework and not new syntax — it’s just a way to keep the source readable while learning.
In the final release, all of this disappears.
The flow works exactly like this:
The user clicks
<input type="submit" value="Submit">
The browser creates an HTTP request
(GET or POST, depending on the form’s method).
That request is received by the server
(including URL, method, headers, and optionally a body).
The server then executes action_page.prg exactly once.
The parameters sent via GET or POST
are processed inside action_page.prg.
The script generates a response
(usually HTML, sometimes plain text or JSON).
The server sends this response back to the browser.
The script terminates.
It does not keep running.
Two important clarifications:
The submit button does not send anything by itself.
It only tells the browser to submit the form.
The server does not “create HTML automatically”.
action_page.prg generates the HTML response,
and the server simply delivers it.
In one sentence:
The browser sends a request.
The server runs the PRG once.
The PRG processes the parameters and generates HTML.
The server returns that HTML to the browser.
That’s the complete and correct web execution model.
At this point it helps to briefly clarify how data is actually sent on the web.
A web request always consists of a few concrete parts.
You don’t need to remember many things — there are only four.
You can think of a web request like an email.
- The URL
This is the recipient.
Example:
https://example.com/action_page.prg
From a FiveWin point of view:
- URL ≈ program name
- URL ≈ email address
It defines which program will be executed on the server.
---
- The method (GET or POST)
This defines how the data is transmitted.
You can think of it like this:
- GET → information written on the outside
- POST → information inside the envelope
The two most common methods are GET and POST.
---
- Headers
Headers are metadata, comparable to the envelope information of an email.
They describe things like:
- browser type
- language
- encoding
- expected response type
At the beginning, you usually don’t need to care about them.
The browser fills them automatically.
---
- Body (optional)
The body is the actual content of the message.
This is where the form data is placed when using POST.
---
To make this even less abstract, here is how a request actually arrives at the server — as plain text.
---
Example: GET request (as received by the server)
GET /action_page.prg?fname=John&lname=Doe HTTP/1.1
Host: example.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
The important part is the first line:
GET /action_page.prg?fname=John&lname=Doe HTTP/1.1
- GET is the method
- /action_page.prg is the program
- everything after ? are the parameters
All following lines are headers.
---
Example: POST request (as received by the server)
POST /action_page.prg HTTP/1.1
Host: example.com
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 19
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html
Accept-Language: en-US,en;q=0.9
fname=John&lname=Doe
Here the structure is always the same:
- request line
- headers
- empty line
- body
With POST, the form values are in the body, not in the URL.
---
A very helpful mental model is again the email comparison:
- URL → recipient
- headers → envelope information
- body → message text
The server-side program reads this message once, generates a response, and then terminates.
From a FiveWin perspective, this is very similar to ShellExecute() with parameter passing:
- URL → program name
- GET parameters → command line parameters
- POST body → input data
- program runs once → produces output → exits
---
The most important takeaway is this:
A form does not execute code.
It creates a request.
The URL defined by the form decides which program runs,
and the method (GET or POST) decides where the data is located.
In the next step, we’ll put this block back into our Hello World example and see how everything fits together.
Best regards,
Otto
