Yaws has very nice support for generating dynamic content on the fly. We use embedded erlang code to generate the content. The Erlang code is separated from the HTML code by <erl> and </erl> markers. For example:
<html>
<h1>Foobar</h1>
<erl>
out(Arg) ->
{html, "Funky Stuff"}.
</erl>
<h1>Baz</h1>
</html>
Is a very small example where we have a HTML document with embedded erlang code. A file which contains embedded erlang code must have the file suffix .yaws
The embedded erlang code can return the different values which will trigger the yaws webserver to do different things. We list some of the simple return values here:
{html, DeepCharOrBinaryList} Which will make the value of DeepCharOrBinaryList be substituted into the HTML document.
{ehtml, ErlangTermStructure}
It is often more convenient to return erlang terms which are then transformed to HTML instead of returning plain HTML in string form using the html tag
Using the ehtml return value, we can return deep structured erlang terms that correspond directly to HTML code. For example:
{table, [{bgcolor, "tan"}],
{tr, [],
[{td, [{width, "70%"}], {p, [{class, "foo"}], "Hi there"}}]}}
Corresponds to the following HTML code:
<table bgcolor="tan">
<tr>
<td width="70%">
<p class="foo"> Hi there </p>
</td>
</tr>
</table>
{header, Header} If a header structure is returned, an additional header is inserted among the HTTP headers generated by yaws. This is used to insert for example Set-Cookie headers. The Header variable must not be newline terminated.
{allheaders, Header} If an allheaders structure is returned, all previous headers that have been generated, including those default hedaers generated by yaws itself are erased, and replaced by the headers in Headers. The variable Headers must be a list of {header, Str} tuples. The Str must not be newline terminated.
{status, StatusCodeInt} Is used to force yaws to return a different status code than the default 200 code.
ok Do nothing.
{content, MimeType, Content} Sets the mime type, that is the Content-Type: header to be MimeType The default value is of course "text/html", but applications that generate i.e wml or pdf, must set the Content-Type. A pdf generating application can for example return the tuple {content, "application/pdf", PdfContentData}
{redirect, URL} a redirect is issued to the location in URL
{redirect_local, Path} a redirect is issued to the local server using the same method (http or https) as the incoming request and the path part of the location header to the value in Path .
{'EXIT', normal} which will terminate the client connection in an uncontrolled way.
{ssi, File, Delimiter, Bindings} Using this construct, we can deep inside a ehtml structure, return (ssi) Server Side Include content from a file. This construct is further described in ssi.yaws.
The embedded erlang code can also return a list of the above values. For example the following value
[{status, 303},
{allheaders,
[{header, ["Location: ","https://www.funky.org/"]},
{header, ["Set-Cookie: ","namn=ruler;"]}
]},
{html,"<html> Redirected to funky.org </html>"}
Can be returned if we want to issue a redirect and set a cookie at the same time.
All possible return values from the out/1 function are documented in the man page for yaws_api (5)
It can also be instructive to look at the actual source for the pages we are viewing at this very moment. Here are some of them
The top page, index.yaws and then the corresponding source
This page, dynamic.yaws and then the corresponding source
The out/1 function is supplied with a record argument. The definition of that record is automatically included in the embedded erlang code and the record definition is:
-record(arg, {
clisock, %% the socket leading to the peer client
headers, %% #headers{} record
req, %% #http_request{} record
clidata, %% The client data (as a binary in POST requests)
querydata, %% Was the URL on the form of ....?query (GET reqs)
docroot, %% where is the data
fullpath, %% absolute path to requested yaws file
server_path, %% The normalized server path
pid, %% pid of the yaws worker process
opaque %% useful to pass static data
}).
And some of the refered records are defined as:
-record(http_request, {method,
path,
version}).
-record(headers, {
connection,
accept,
host,
if_modified_since,
if_match,
if_none_match,
if_range,
if_unmodified_since,
range,
referer,
user_agent,
accept_ranges,
cookie = [],
keep_alive,
content_length}).
Each chunk of erlang code will be compiled into a separate module. The module names are automatically generated. If we have functions inside the erlang chunks that we want to call from other chunks or modules, it is possible to explicitly name the modue that will be used as in:
<erl module=foobar>
out(A) ->
io:format('This is the foobar module',[]).
func() ->
i_am_exported_from_foobar.
</erl>