Skip to content
This repository
Fetching contributors…

Octocat-spinner-32-eaf2f5

Cannot retrieve contributors at this time

file 98 lines (72 sloc) 3.272 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>

<head>
 <meta name="keywords" content="Yaws">
 <title>Yaws</title>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 <link rel="stylesheet" type="text/css" href="style.css">
</head>

<body>

<h2> The source for the shopping cart </h2>

<p class=pp>The shoppingcart contains a number of tricks and "preferred" ways to
 code different typical solutions to servers side state applications.

The source itself resides in the www/shoppingcart directory in the
source code tree. A <a href="shopcart.erl">link to the source itself</a> to view from
the browser.
</p>
<h3> The first trick, the <tt>break</tt> statement </h3>

<p class="pp">
The source of all yaws pages (including example index.yaws)
look very similar in this application, specifically</p>

<div style="background: rgb(211, 211, 211)">
<pre>
out(A) -&gt;
    case shopcart:top(A) of
        ok -&gt;
            shopcart:index(A);
        X -&gt;
            X
    end.

</pre>
</div>

<p class=pp>All code, including the head containing the link
to the stylesheet is dynamically
generated. The first function in all code snippets in yaws files is always
a call to <tt>shopcart:top(A)</tt></p>
<p class=pp>The <tt>top/1</tt> function will check the cookie and if a cookie
which is associated to an active session is found, the request is granted,
otherwise the login page is displayed by the <tt>shopcart:login(A)</tt> function.</p>
<p class=pp>The last item displayed by the login function is the atom <tt>break</tt>. When the
yaws server sees the <tt>break</tt>, it will not process any more data from the
yaws page being requested. Thus, we can have the login call at the top of a yaws
page and still have subsequent html/yaws code on the same page.</p>


<h3>Redirect to the requested page</h3>

<p class=pp>Since the <tt>login(A)</tt> function is supplied with the
Arg of the requested page, the login function
will set the path of the requested page in a hidden field in the login form.
The code that processes the login form will then issue a redirect to the
value of this hidden field if the login in successful.</p>


<h3>Ehtml</h3>
<p class=pp>The use of the ehtml output syntax makes it more convenient to dynamically
generate structured content:</p>

<ul>
<li><p class=pp>
It is easier to get the structure right,</p></li>
<li><p class=pp>It
is easier to inject the dynamically generated parts in the structure,</p></li>
<li><p class=pp>It is <em>much </em> more beautiful.</p></li>
</ul>

<p class=pp>See the <a href="shopcart.erl">source</a> for a number of "proofs" for this.</p>

<h3>The use of the <b>yaws_session_server</b> </h3>
<p class=pp>The yaws_session_server is designed to facilitate server side
state applications. The yaws application writer is supplied
with the following capabilities and services:</p>

<ol>
<li><p class=pp>Truly random cookie generation. Each cookie can
subsequently be used to uniquely identify a session.</p></li>

<li><p class=pp>Maintenance of an opaque application state in an ets table.
This state is readily available to the yaws page by means of the cookie.</p></li>

<li><p class=pp>Old idle sessions are garbage collected.</p></li>
</ol>



</body>
</html>


Something went wrong with that request. Please try again.