What IS a Web Server Anyway?

This page introduces the concept of Dynamic web pages, and how you can implement them in APL within the MildServer.

A Web Server is a process running on a machine somewhere, which accepts connections via TCP/IP. Over these connections, the Web Server and its client (typically a "Web Browser") communicate using a protocol called HyperText Transfer Protocol, or HTTP. The incoming HTTP requests typically contain commands to retrieve a "resource". For example, "GET index.htm" would be a command to retrieve the contents of a named page. If the MildServer is working according to its design, you should not need to learn anything about TCP/IP or HTTP - this should all be handled automatically.

HTTP responses generally contain text in a format called HyperText Markup Language - or HTML - which web browsers know how to display. You WILL need to learn some basic HTML in order to write Web Applications. Although the MildServer contains functions which will help you generate HTML, you will need to know the basic principles of HTML in order to feel comfortable using them. It is a good idea to spend 20-30 minutes looking at the beginning of one of the many excellent HTML tutorials available on the internet. Understanding Cascading Style and Style Sheets makes it very much easier to produce good looking HTML pages, so it is also worth understanding a little bit about CSS and looking at one or two tutorials on this subject as well.

Much of the information on the internet is in the form of static web pages: These are simply files containing text marked up as HTML. When you request one of these pages from a Web Server, it simply transmits the content of the file to the client. The fact that a web page is static doesn't mean that it never changes: Your application could be updating the HTML files every few seconds with the latest information that you want to make available.

In addition to serving up static web pages, most Web Servers provide functionality which makes it possible to provide dynamic content:

Scripting: Most Web Servers allow pages to contain embedded code (or "script") which is executed when the resource is retrieved. This allows you to serve up web pages which provide a "user interface", and execute code on the server in response to input from the user.

Sessions: In order to support "applications" using scripting, Web Servers have ways to detect that a sequence of HTTP requests constitute a session. Script code can save session-related data on the server and access it during subsequent requests.

Security: Web Servers can require that the user log in, in order to access all or part of the web site.

Dynamic MildServer Pages

Imagine that we want to implement a very simple interactive Web Page containing a single edit field which we can reverse by clicking on a button:

The code required to implement the above page using the MildServer is:

:Class Reverse : MildPage

    :Include #.HTMLInput              ⍝ Useful functions for creating HTML pages

    :Field Public Name←''             ⍝ Name of edit field
    :Field Public Action←''           ⍝ All action buttons have this name

    ∇ Render req;html
      :Access Public

      DoAction                        ⍝ If a button was pressed, deal with it

      html←'<br>Enter Text: '
      html,←'Name'Edit Name           ⍝ An "Edit" called "Name" containing the Name
      html,←'<br><br>'
      html,←'Action'Submit'Reverse'   ⍝ A button named 'Action' with Caption 'Reverse'
      html,←'Action'Submit'Clear'     ⍝ ... another button named 'Action'

      html←req('submit'Form)html      ⍝ Put a 'submit' form around it
      html,←'a href="/"'Enclose'Home' ⍝ A link back to the index page

      req.Return html
    ∇

    ∇ DoAction
      :Select Action
      :Case 'Clear' ⋄ Name←''
      :Case 'Reverse' ⋄ Name←⌽Name
      :EndSelect
    ∇

:EndClass

How it Works

When the MildServer is asked to retrieve a file which has the extension ".dyalog" or ".msp" (MildServer Page), it expects the file to contain the source code for a Dyalog APL Class, and this class is expected to have a public method called Render. The MildServer will call Render with an instance of the HTTPRequest class as the right argument; this object contains information extracted from the incoming HTTP request. The Render function is expected to call one of the following methods on the HTTP request object, before it ends:

• req.Return (to respond with some HTML, as in the above example)
• req.Fail (to set an HTTP failure code)

• req.ReturnFile (to return the contents of an existing file)

In this case, the HTML produced is:

<form action="/reverse.dyalog" method="submit">
<br>Enter Text: <input  type=text size=10 id="Name" name=Name value="nevohteeB">
<br><br><input type="submit"  name="Action" value="Reverse" >
<input type="submit"  name="Action" value="Clear" >
</form>
<a href="/">Home</a>

Input Parameters

The MildServer extracts parameter names and values from the incoming HTTP request. Parameters typically correspond to HTML input controls in a form which the browser is displaying, and the contents of that input. For more details of how parameters are embedded in HTTP requests, see MildServer/Parameters). When the name of a parameter matches the name of a public field or property exposed by the referenced page, the MildServer will assign the corresponding value to that member before the Render method is called. Your APL code does not need to know anything about how to decode HTTP - it just needs to generate HTML in which the input controls have names that it will recognise when information is posted back.

In the above example, the following request was made:

http://localhost:8080/reverse?Name=Beethoven&Action=Reverse

The page class definition exposes two public fields called Name and Action, so before calling the Render function, the MildServer will set Name to Beethoven and Action to Reverse. Thus, the Render function transfers values from the instance of the page class into the HTML which is displayed by the browser. When the user submits the form back to the server, values of all input fields are relayed back to the server-side code, and the loop is closed: We are now able to write interactive applications driven by APL functions running on the Server.