Cookie Monster!

Mmmm, munchies.

Some people love them, some people hate them. They are in reality fairly harmless, but some think they will bring about the downfall of civilization. They are, of course, foxes...

Oh, some people think the same things about cookies, too.

A cookie is a tiny text file that sits on your computer. The server has asked for it to be stored there so it can either recognise you, or to allow you to personalise some aspects of a website.

As mentioned last session, www.empty-domain.com now uses cookies in an incredibly brief, restricted and, to be honest, pointless way. You can login to the site, and have it tell you your name all the time. Which is nice...

However, cookies can be used in a far more interesting way. For example, you could use cookies to check where on your site a visitor has been. If he goes to the (for example) sports section, you could learn this, and have your advertising to that user lean towards sporting goods. Of course, I'm not going to show you how to do that, I'm going to show you how to do my login box. :)

First, we'll need a way to read in data to put in the cookie, in this case the users name. We will have to use a form to do this - naturally the way of getting data will vary depending on the application. We encountered how hitop handles forms last time, but for a brief recap: form variables can be accessed by @GET NAME="FORM_varname" or ${FORM_varname} where varname is the name of the input from the form.

So, now we are in a position to create a login box. We need a simple form, that asks for your name and allows you to submit. The following should do the trick. What it produces is shown with a grey background.

The most important things to note from the for are the action="setcookie.live" attribute in the form declaration, and the name="name" attribute of the text input element. The action attribute tells the form where to send the data, so we now need a new file, setcookie.live. This will, unsurprisingly, set the cookies.

Time to start baking...

So, we know this page will be called by a form. So we know we should expect some form data. I'll assume you've set up your file as you want, with all the templates you want. I'll just be looking at the code you need to set the cookies. Which is...

<@SETCOOKIE name=NAME value='${FORM_name}' maxage="7200">

And that's it. It is that simple.
What, you want to know what it actually means? Damn...

Right. name=NAME is the name we want to give the cookie. It is important you don't give more than one cookie this name (unless you want to overwrite the data).
value='${FORM_name}' actually puts the data in the cookie. In this case, ${FORM_name} is the data that was input in the form the last page. maxage="7200" tells the cookie how long it should last before, um, going stale. This is the time in seconds it should last. After this time, it will not be sent to any server asking for it.

There are other attributes set in the cookie specification that you can also use. These are path=PATH and expires=DATE. path=PATH enables you to restrict your cookie to certain sections of your site, while expires=DATE enables you to set a fixed date for all of your cookies to expire. There is also a domain=DOMAIN_NAME attribute. See the cookie specification for more info.

Taking them out of the oven

Well, now the website visitor has a text file with their name in it sitting on their computer. Not a lot of use there, is it? We need a way of getting the data from them. This is achieved with the imaginatively named @GET.

Getting the cookie is just as simple as using @SETCOOKIE. It is simply a matter of putting <@GET name=COOKIE_NAME> wherever you want to have that data in your page. This is because, as with form data, hitoplive simply puts the data into normal variables that you can get at. The name of the cookie data follows the same pattern as accessing form data - COOKIE_ tells hitoplive it is data from a cookie, and NAME tells hitoplive the name of the cookie you want the data from. The example below shows how www.empty-domain.com shows your name on its pages.

You are logged in as <b><@GET name="COOKIE_NAME"></b>.<br>

Of course, there are other various issues we haven't covered here - the need to check whether a cookie exists, sending the user back to the page they came from, and so on. These items will be covered in a later session about decision making. Next, however, we move onto database integration.