Address Book Example
This example demonstrates how to create a simple front end to a database table, that allows the user to view, create, edit and delete the entries.

Here is the table definition (we're using SQLite):
CREATE TABLE addressbook ( id INTEGER PRIMARY KEY, person_name TEXT, address TEXT, notes TEXT );
The application code is split into three diagrams: Main, which contains several simple constructs, used for building more complex ones, Views, which contains the code used for routines that are responsible for the HTML code generation, and Forms, which contains code for the form handling routines. The first part of the first diagram looks like this:

This construct is used in every routine that generates and outputs HTML code. The http_response operation is marked as a task-item, so it will be considered to be one of the goal operations, that must be executed. One of the template operations is tagged with the OUT tag – this allows it to be accessed from other places with a corresponding tag reference, thus hooking the whole construct. index.html is a file constant, used as a template for the HTML documents. Here is it's content:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="Content-type" content="text/html; charset=UTF-8"> <link rel="stylesheet" type="text/css" media="screen" href="style.css"> <title>Address Book, Aluminium 0.4 example</title> </head> <body> <h1>Address Book</h1> <p> [<a href="index.al">Addresses</a>] [<a href="new_entry.al">New Entry</a>] </p> <% echo(content); %> </body> </html>
As you can see, it prints the contents of a variable named content, which is passed as a user defined argument of the template operation. The rest of the first diagram looks like this:

The construct at the top is built to pass the :database argument to each operation tagged with the QUERY tag. The QUERY tag reference has the Include on tag use option switched on, so it will be included (along with the whole construct) into every routine where a QUERY item appears. The split operation is used to ensure that the single argument rule isn't broken when there is more than one QUERY item in a routine.
The last construct is there to provide a more convenient way of accessing HTTP request query data (by using GET tag reference for as many times as needed).
The next diagram contains the code for the routines that generate and output HTML code. The first part of this diagram looks like this:

The OUT tag reference is marked as a member of index routine, so this routine will contain the elements for HTML code generation and output, and the additional elements from this diagram (only the ones that are connected directly – see Routines from Manual Reference).
OUT refers to a template operation, so we're passing the arguments as if it was the operation itself: :data (from the list.html file constant), fields from the SQL query result, and HTTP request query data as variable get. Here is the content of the list.html file:
<%
function orderBy(o)
{
var q = '';
var vars = Object();
for (i in get) vars[i] = get[i];
vars.order = o;
if (vars.hasOwnProperty('order') && vars.order == o)
{
vars.desc = ((vars['desc'] == 'true') ? ('false') : ('true'));
}
else
{
vars.desc = 'true';
}
for (i in vars)
{
q += i + '=' + vars[i] + '&';
}
return q;
}
%>
<h2>Addresses</h2>
<table cellspacing="0" cellpadding="4">
<tr>
<th><a href="?<% echo(orderBy('person_name')); %>">Name</a></th>
<th><a href="?<% echo(orderBy('address')); %>">Address</a></th>
<th><a href="?<% echo(orderBy('notes')); %>">Notes</a></th>
<th> </th>
</tr>
<% for (i in id) { %>
<tr<% if (i % 2 == 1) echo(' style="background-color: #FFC;"'); %>>
<td><% echo(person_name[i]); %></td>
<td><% echo(address[i]); %></td>
<td><% echo(notes[i]); %></td>
<td>[<a href="edit_entry.al?id=<% echo(id[i]); %>">Edit</a>]
[<a href="confirm_delete.al?id=<% echo(id[i]); %>">Delete</a>]</td>
</tr>
<% } %>
</table>
The rest of the second diagram is built similarly:

The sql_query_record operation is used as an argument twice, but it does not violate the single-argument rule, as the two targets are marked as members of different routines, and will not appear in the same routine.
The last diagram contains the code for the form handling routines:

There are two task-operations in this diagram, so every routine generated from this code will perform the two tasks: execute a SQL query, and write an HTTP response (in this order). The three text constants are tagged with the FORM tag, and marked as members of routines. This will result in generation of three almost identical routines that differ only in query they execute.