Implementing Web Interaction Using Eliom

The code of this tutorial has been tested with the 2.1 release of the Ocsigen bundle.

This chapter is a tutorial explaining how to create a small Web site with several pages, users, sessions, etc. Then, in next chapter, we will incorporate the features of this site with the program from the previous chapter, to show that we can mix this kind of interaction with client-side programs.

We assume you have read at least the first section of the previous chapter, which explained how to create a service and constuct valid HTML pages.

We will create a simple Web site with one main page and a page for each user (assuming we have several users already created). Then we will add a login/connection form. We will also add a registration form, in order to learn how to create dynamically new services, and why it is very useful.

The full code of the program can be downloaded.

Services

The main page

Let's start again from scratch with the following site.

open Eliom_pervasives
open HTML5

let main_service =
  Eliom_output.Html5.register_service
    ~path:[""] ~get_params:Eliom_parameters.unit
    (fun () () ->
      Lwt.return
        (html (head (title (pcdata "")) [])
                       (body [h1 [pcdata "Hello"]])))

Note that we are using Eliom_output.Html5, as we are not building a client side program for now.

Put this example in a file (tuto.ml), compile it like so:

eliomc -c tuto.ml

Finally, modify your configuration file as explained in the previous chapter to load the file tuto.cmo. Then launch Ocsigen to run the site.

Adding a page for each user

We will now create a page for each user. To do this, we will create a new service, taking the user name as parameter:

let user_service =
  Eliom_output.Html5.register_service
    ~path:[""] ~get_params:(Eliom_parameters.string "name")
    (fun name () ->
      Lwt.return
        (html (head (title (pcdata name)) [])
                       (body [h1 [pcdata name]])))

Add these lines to the same file, compile, start the server and verify that everything is working by trying, for example: http://localhost:8080/?name=toto.

Concept: Services with parameters

To define a service that accepts parameters in the URL (GET parameters), just add a description of the parameters you want in the ~get_params argument of the register_service function. In our example, the service is expecting a parameter called name, of type string.

The handler function (function implementing the service) always takes two parameters:

The first one corresponds to GET parameters (in our example, a string).
The second one corresponds to parameters that are sent in the body of the HTTP request (POST parameters). We will see soon how to make services with POST parameters.

The module Eliom_parameters defines the possible parameter types. For example if you write:

~get_params:(Eliom_parameters.int "i")

Eliom will try to find a parameter called i and to translate it into an int. In that case, the handler function will accept an int as the second parameter.

If you want to accept several parameters, you can do, for example:

~get_params:(int "i" ** string "s")

after opening the Eliom_parameters module. In that case, the handler function takes a pair of type (int * string).

Warning: The operator ** is an infix binary operator. It will always create pairs, and not triples or other tuples.

The module Eliom_parameters also defines other parameter types: for example floats, 64 bits integers, sum types, but also more complex types, like sets or lists of values. It is also possible to define your own parameter types.

For our program, we would prefer to take one part of the URL path as the parameter describing the name of the user. I change the definition of my service this way:

let user_service =
  Eliom_output.Html5.register_service
    ~path:["users"]
    ~get_params:
       (Eliom_parameters.suffix (Eliom_parameters.string "name"))
    (fun name () -> ... )

The user pages are now available at URLs http://localhost:8080/users/username.

Concept: Using parts of the path as page parameters

The module Eliom_parameters makes it possible to use parts of the path as service (GET) parameters.

In addition to Eliom_parameters.suffix, there are many other values allowing you to specify your expected parameters: for example, you may access the full suffix as a string, as a list of string, or you may want to mix suffix parameters with standard GET parameters. You can also accept, as parameters, parts of the path that are not a suffix of the path (using Eliom_parameters.const). See more information on suffixes in Eliom's manual.

Warning: Even if it is not displayed in the URL, suffix parameters have a parameter name. This allows one to make forms that point to those kind of services. Actually each "suffix service" has an equivalent without suffix (which is by default automatically redirected towards the suffix version if it is a GET request).

Links

We now want to add a link on each user page to go back to the main page.

Change the handler of user_service into:

(fun name () -> Lwt.return
  (html
    (head (title (pcdata name)) [])
    (body [h1 [pcdata name];
           p [Eliom_output.Html5.a
                ~service:main_service [pcdata "Home"] ()]])))

Links towards services with parameters

In our example above, the last parameter is () because the service does not expect any parameter. If the service expects, for example, a pair (int * string), you must provide a matching value as last parameter. OCaml checks at compile time that the type of the parameters in a link corresponds to the type expected by the service! Also note that the parameter names are generated automatically from the service, making it impossible to erroneously create bad links.

To show an example of a link with parameters, we will display the list of user pages on the main page. Here is the new version of the full program:

open Eliom_pervasives
open HTML5
open Eliom_parameters

let main_service =
  Eliom_services.service ~path:[""] ~get_params:unit ()

let user_service =
  Eliom_services.service
    ~path:["users"] ~get_params:(suffix (string "name")) ()

(* User names and passwords: *)
let users = ref [("Calvin", "123"); ("Hobbes", "456")]

let user_links () =
  ul (List.map (fun (name, _) -> 
                  li [Eliom_output.Html5.a
                        ~service:user_service [pcdata name] name])
               !users)

let _ = 
  Eliom_output.Html5.register
    ~service:main_service
    (fun () () ->
      Lwt.return
        (html (head (title (pcdata "")) [])
              (body [h1 [pcdata "Hello"];
                     user_links ()])));

  Eliom_output.Html5.register
    ~service:user_service
    (fun name () ->
      Lwt.return
        (html (head (title (pcdata name)) [])
              (body [h1 [pcdata name];
                     p [Eliom_output.Html5.a
                          ~service:main_service [pcdata "Home"] ()]])))

Concept: Database libraries

Ultimately we'll want to use a more sophisticated database module for managing user information, which we will write later in this tutorial. You can use any OCaml database binding (for example PGOcaml to program database queries). We will use our own database library called Macaque, which implements typed requests using comprehensions.

Just remember that your query functions must be cooperative with Lwt! For example PGOcaml is now implemented in monadic way, which makes it 100% compatible with Lwt. Macaque (the library we use later in this tutorial) is as well.

If your database module is not Lwt-cooperative but is thread-safe (for preemptive threads), you can use the Lwt_preemptive.detach function to make the blocking function be executed by a separate preemptive thread.

Sessions

Connection service

Now I want to add a connection form. First, I will create a service for checking the name and password. Since I don't want the username and password to be shown in the URL, I will use hidden parameters (or POST parameters). Thus, I'll need to create a new service taking these parameters:

let connection_service =
  Eliom_services.post_service
    ~fallback:main_service
    ~post_params:(string "name" ** string "password")
    ()

Concept: Hidden (POST) services

Services using the POST HTTP method are created using the function Eliom_services.post_service. As you can see, there is a major difference from the function Eliom_services.service: post_service does not take a path as parameter, but a GET service as a fallback.

This means that for each POST service, you must first create a GET service at the same path that will answer if the user sets a bookmark on the page and returns later without POST parameters. In this way, you will not get 404 errors if POST parameters are missing.

If the fallback has GET parameters, your service will have both GET and POST parameters. In that case, GET parameters will be in the URL and POST parameters will probably come from a form. In HTML, it is not possible to mix GET and POST parameters in the same form.

Now you can register a handler for the new service:

Eliom_output.Html5.register
    ~service:connection_service
    (fun () (name, password) ->
      let message =
        if check_pwd name password
        then "Hello "^name
        else "Wrong name or password"
      in
      Lwt.return
        (html (head (title (pcdata "")) [])
              (body [h1 [pcdata message];
                     user_links ()])));

where check_pwd is defined by:

let check_pwd name pwd =
  try List.assoc name !users = pwd with Not_found -> false

Connection form

For now, I will add the connection form only on the main page of the site.

Let's create a function for generating the form:

let connection_box () =
  Eliom_output.Html5.post_form ~service:connection_service
    (fun (name1, name2) ->
      [fieldset
         [label ~a:[Eliom_output.Html5.a_for name1] [pcdata "login: "];
          Eliom_output.Html5.string_input ~input_type:`Text
                                          ~name:name1 ();
          br ();
          label ~a:[Eliom_output.Html5.a_for name2] [pcdata "password: "];
          Eliom_output.Html5.string_input ~input_type:`Password
                                          ~name:name2 ();
          br ();
          Eliom_output.Html5.string_input ~input_type:`Submit
                                          ~value:"Connect" ()
         ]]) ()

Now, add a call to this function in the handler of the main service (for example just before the user links).

Concept: Forms

Form creation is very similar to link creation, using the functions Eliom_output.Html5.get_form and Eliom_output.Html5.post_form.

The first parameter is the service, and the last parameter (only for post_form) is for GET parameters you want sent in the URL, if the fallback of your POST service takes GET parameters.

The only difference is how we write form content: instead of simply giving the content as parameter to the get_form or post_form functions, you supply a function that creates the form from the names of the parameters the service is expecting. Thus, you don't need to remember the parameter names you chose while creating the service, and you can change them easily without having to update every form in your application.

In the example, note that the service is expecting a pair (string * string). The function given to post_form takes two parameters corresponding to the names of each field.

Eliom_output.Html5 defines constructors for all possible form fields. OCaml checks that the name you use matches the field. For example it is not possible to use the names above with Eliom_output.Html5.int_input as it is a name for a string.

Opening a session

Now we want to remember that the user is successfully connected. To do that we will set a reference when the user successfully connects, and we will restrict the scope of this reference to the session (that is, to the browser).

Define your Eliom reference with a default value:

let username = Eliom_references.eref ~scope:Eliom_common.session None

Here is the new connection_box function:

let connection_box () =
  lwt u = Eliom_references.get username in
  Lwt.return
    (match u with
      | Some s -> p [pcdata "You are connected as "; pcdata s]
      | None ->
        Eliom_output.Html5.post_form ~service:connection_service
          (fun (name1, name2) ->
            [fieldset
	       [label ~a:[Eliom_output.Html5.a_for name1] [pcdata "login: "];
                Eliom_output.Html5.string_input ~input_type:`Text
                                                ~name:name1 ();
                br ();
                label ~a:[Eliom_output.Html5.a_for name2] [pcdata "password: "];
                Eliom_output.Html5.string_input ~input_type:`Password
                                                ~name:name2 ();
                br ();
                Eliom_output.Html5.string_input ~input_type:`Submit
                                                ~value:"Connect" ()
               ]]) ())

... and replace the registration of the main service and the connection service by:

Eliom_output.Html5.register
    ~service:main_service
    (fun () () ->
      lwt cf = connection_box () in
      Lwt.return
        (html (head (title (pcdata "")) [])
              (body [h1 [pcdata "Hello"];
                     cf;
                     user_links ()])));

  Eliom_output.Html5.register
    ~service:connection_service
    (fun () (name, password) ->
      lwt message =
        if check_pwd name password
        then begin
          Eliom_references.set username (Some name) >>
          Lwt.return ("Hello "^name)
        end else
	  Lwt.return "Wrong name or password" in
      Lwt.return
        (html (head (title (pcdata "")) [])
              (body [h1 [pcdata message];
                     user_links ()])))

Concept: More on Lwt

Function Eliom_references.get has type 'a Eliom_references.eref -> 'a Lwt.t. The only way to use the result of such functions (ones that return values in the Lwt monad), is to use Lwt.bind.

Lwt.bind : 'a Lwt.t -> ('a -> 'b Lwt.t) -> 'b
Lwt.t

It is convenient to define an infix operator like this:

let (>>=) = Lwt.bind

Then the code

f () >>= fun x ->

has to be read as

let x = f () in

but only for functions returning a value in the Lwt monad.

For more clarity, there is a syntax extension for Lwt, defining a new keyword lwt to be used instead of let for Lwt functions:

lwt x = f () in

Lwt.return creates a terminated thread from a value (without inserting a cooperation point):

Lwt.return : 'a -> 'a Lwt.t

Use it when you must return something in the Lwt monad (for example in a service handler, or often after a Lwt.bind).

Why Lwt?

An Eliom application is a cooperative program, as the server must be able to handle several requests at the same time. Ocsigen is using cooperative threading instead of the more widely used preemptive threading paradigm. It means that no scheduler will interrupt your functions whenever it wants. Switching from one thread to another is done only when there is a cooperation point.

We will use the term cooperative functions to identify functions implemented in cooperative way, that is: if something takes (potentially a long) time to complete (for example reading a value from a database), they insert a cooperation point to let other threads run. Cooperative functions return a value in the Lwt monad (that is, a value of type 'a Lwt.t for some type 'a).

In our example, the function Eliom_state.get may introduce a cooperation point, because if your Eliom reference is persistent (see below), it is stored in a database on the hard drive. That's why it returns a value in the Lwt monad.

Using cooperative threads has a huge advantage: as you know precisely where cooperation points are, you need very few mutexes and you have very few risks of deadlocks!

Using Lwt is very easy and does not cause troubles, provided you never use blocking functions (non cooperative functions). Blocking functions can cause the entre server to hang! Remember:

Use the functions from module Lwt_unix instead of module Unix,
Use cooperative database libraries (like PG'Ocaml for Lwt),
If you want to use a non-cooperative function, detach it in another preemptive thread using Lwt_preemptive.detach,
If you want to launch a long-running computation, manually insert cooperation points using Lwt_unix.yield,
Lwt.bind does not introduce any cooperation point.

Concept: Eliom references and extended sessions

Session data is stored in what we call Eliom references. It is a type of reference whose value depend on the session the user belongs to.

Eliom is making the notion of session much more powerful by adding other scopes for Eliom references. Instead of limiting the scope to a session (that is: one browser), it is also possible to create Eliom references with scope "client-side process" (~scope:Eliom_common.client_process), or "group of sessions" (see later) (~scope:Eliom_common.session_group), or "current request" (~scope:Eliom_common.request).

Example: Say you want to implement a game, and make possible to have several instances of the game running in several tabs of the browser. Store the score on server side, as a "client side process" Eliom reference.

Example: Grouping all the sessions for one user in a group of session makes possible to share a shopping basket between several devices (your mobile phone and your laptop for example).

An Eliom reference is defined with the function Eliom_references.eref, specifying the scope of this reference and the default value. The function Eliom_references.get retrieves the value of this reference for the current scope. The default value is used for all sessions (or client process or group of sessions) for which it has not been changed using Eliom_references.set.

By default, Eliom references are kept in memory and will disappear if you shut down the server. It is possible, however, to create persistent Eliom references that will survive even a server restart. To do that, add the optional parameter persistent to the eref function, with a string value corresponding to the name of the table that will contain the values on disk.

Display the usual page after connection

As you can see, our connection service is displaying a welcome page which is different from the main page in connected mode. We would rather display the same page. One solution is to call the same handler after registering session data.

A cleaner solution is to use an action, that is: a service which will just perform a side effect. Replace the registration of the connection service by:

Eliom_output.Action.register
    ~service:connection_service
    (fun () (name, password) ->
      if check_pwd name password
      then Eliom_references.set username (Some name)
      else Lwt.return ())

Now the main page is displayed after connection.

Putting a connection form on each page

Concept: Non-attached coservices

With many Web programming frameworks, adding a connection form on each page of a site is complicated, and is approached in one of two ways:

A first solution is similar to what we did for the main service, but for all services (meaning that each page usually checks the presence of POST parameters). This is clumsy.
Another solution would be to create a special page on a separate path to handle the registration, with some way to do a redirection to the page we came from after connection. (Of course we want to stay on the same page after sending the connection form!) This is ugly.

With Eliom, this is more straightforward:

For the connection service, we use a kind of service called non-attached coservice, which means that it is not attached to any path in particular. Calling this kind of service will not change the path you see in the browser URL bar (just add parameters if you use the GET method).
Use an action to connect the user and redisplay the page corresponding to the current URL.

By default, a random identifier will be generated automatically by Eliom for the non-attached coservice. If you want this identifier to be fixed, you can specify it yourself while creating the service using the ?name optional parameter. This identifier is added automatically by Eliom in each form (as hidden field) and link.

Transform the connection service into a non-attached coservice:

let connection_service =
  Eliom_services.post_coservice'
    ~post_params:(string "name" ** string "password")
    ()

Now you can add the connection box on user pages.

let connection_service =
  Eliom_output.Html5.register
    ~service:user_service
    (fun name () ->
      connection_box () >>= fun cf ->
      Lwt.return
        (html (head (title (pcdata name)) [])
              (body [h1 [pcdata name];
                     cf;
                     p [Eliom_output.Html5.a
                          ~service:main_service [pcdata "Home"] ()]])));

Concept: Altenative: register a redirection

Usually, after sending a POST form, it is good practice to do a redirection. This avoids reposting the data if the user reloads the page.

Eliom provides the module Eliom_output.Redirection to register services doing redirections. Such services return a service without parameter.

Example:

let redir_service = Eliom_output.Redirection.register_service
    ~path:["redir"]
    ~get_params:Eliom_parameters.unit
   (fun sp () () -> Lwt.return main_service)

(If you want to give parameters to the service you return, use Eliom_services.preapply — more information in the Eliom manual .)

If you want to do a redirection towards the current page (as in our case), use the special service Eliom_services.void_coservice', which is some kind of POST non-attached coservice without parameter at all.

Disconnection

To create a logout/disconnection form, we create another non-attached coservice using POST method, and register another action. We call the function Eliom_state.discard with scope Eliom_common.session to remove all session data.

let disconnection_service =
  Eliom_services.post_coservice' ~post_params:unit ()

let disconnect_box () =
  Eliom_output.Html5.post_form disconnection_service
    (fun _ -> [p [Eliom_output.Html5.string_input
                    ~input_type:`Submit ~value:"Log out" ()]]) ()

let _ =
  Eliom_output.Action.register
    ~service:disconnection_service
    (fun () () -> Eliom_state.discard ~scope:Eliom_common.session ())

Then add this form in the connection box:

let connection_box () =
  lwt u = Eliom_references.get username in
  Lwt.return
    (match u with
      | Some s -> div [p [pcdata "You are connected as "; pcdata s; ];
                       disconnect_box () ]
      | None -> ...

Registration of users

Basic registration form

We will now add a registration form to the application. We create a new regular service, attached to the path /registration, that displays a registration form, and an action that will add the user to the "database":

let new_user_form_service =
  Eliom_services.service ~path:["create account"] ~get_params:unit ()

let create_account_service = 
  Eliom_services.post_coservice
    ~fallback:main_service
    ~post_params:(string "name" ** string "password") ()

let create_account_form () =
  Eliom_output.Html5.post_form ~service:create_account_service
    (fun (name1, name2) ->
      [fieldset
         [label ~a:[Eliom_output.Html5.a_for name1] [pcdata "login: "];
          Eliom_output.Html5.string_input ~input_type:`Text
                                          ~name:name1 ();
          br ();
          label ~a:[Eliom_output.Html5.a_for name2] [pcdata "password: "];
          Eliom_output.Html5.string_input ~input_type:`Password
                                          ~name:name2 ();
          br ();
          Eliom_output.Html5.string_input ~input_type:`Submit
                                          ~value:"Connect" ()
         ]]) ()

let _ =
  Eliom_output.Html5.register
    ~service:new_user_form_service
    (fun () () ->
      Lwt.return
        (html (head (title (pcdata "")) [])
              (body [h1 [pcdata "Create an account"];
                     create_account_form ();
                    ])));

  Eliom_output.Action.register
    ~service:create_account_service
    (fun () (name, pwd) ->
      users := (name, pwd)::!users;
      Lwt.return ())

Then add the link to this service in the connection box:

let connection_box () =
  lwt u = Eliom_references.get username in
  Lwt.return
    (match u with
      | Some s -> div [p [pcdata "You are connected as "; pcdata s; ];
                       disconnect_box () ]
      | None ->
        div [Eliom_output.Html5.post_form ~service:connection_service
                (fun (name1, name2) ->
...
                ) ();
             p [Eliom_output.Html5.a new_user_form_service
                  [pcdata "Create an account"] ()]]
            )

Registration form with confirmation

Now we want to add a confirmation page before actually creating the account. We replace the service create_account_service by a new POST attached coservice called account_confirmation_service:

let account_confirmation_service =
  Eliom_services.post_coservice
    ~fallback:new_user_form_service
    ~post_params:(string "name" ** string "password")
    ()

and we make the account creation form point at this new service.

We register an HTML handler on this service, with the confirmation page. As a side effect, this page will create the actual account creation service:

Eliom_output.Html5.register
  ~service:account_confirmation_service
  (fun () (name, pwd) ->
    let create_account_service =
      Eliom_output.Action.register_coservice
        ~fallback:main_service
        ~get_params:Eliom_parameters.unit
        ~timeout:60.
        (fun () () ->
          users := (name, pwd)::!users;
          Lwt.return ())
    in
    Lwt.return
      (html
        (head (title (pcdata "")) [])
          (body
            [h1 [pcdata "Confirm account creation for "; pcdata name];
             p [Eliom_output.Html5.a
                  ~service:create_account_service [pcdata "Yes"] ();
                pcdata " ";
                Eliom_output.Html5.a
                  ~service:main_service [pcdata "No"] ()]
            ])))

Also remove the registration of the create_account_service service and modify the user creation form to make it points towards account_confirmation_service.

Concept: Dynamic creation of services

In this example, we are dynamically creating a new service (here a coservice that does an action). This is done by the same register function as usual.

Dynamic creation of new services allows one to create services that depend on previous interaction with the user. Here the create_account_service service depends on name and pwd, that were previously sent by a form.

In this simple example, an alternative would have been to send name and pwd again to the same service as in the "basic registration form" example. But this solution is not possible when you have too much data.

Saving name and pwd as session data is a wrong solution! If the user duplicates his browser window and fills out the user creation form in both, then the confirmation link must create the right account!

A working alternative would have been to generate a random key, and associate name and pwd with that key in a database table on the server. This is the way such kind of Web interaction is usually implemented. However, Eliom's solution is much simpler.

The ability to register new services dynamically is implemented in few Web frameworks, even though it simplifies a lot the programmating involved with that type of Web interaction. This feature is a variant of what is called continuation based Web programming. Think about it when you want to create a page that depends on previous interaction with the user. Dynamic registration of services will automatically record the "history" of the interaction, and make possible to use the "back button" or to have several tabs on the same site.

Examples of uses:

displaying the results of a search
programming a "several step form" (when a form points at another one, etc., like our registration form with confirmation).

On the other hand, if you want to implement a shopping basket, you want it to be shared between all tabs of your Web site. To do that, you will use session data.

Warning: Services are kept in memory. To avoid memory leaks, you probably want to put a timeout on your dynamic coservices. Just add the optional parameter ?timeout to the service creation function.

Concept: Session services

Eliom also makes it possible to restrict the scope of services to a session, a group of sessions, or even a client side process (if you have a client side program running). It works exactly like the scope of Eliom references. To do that, just add the optional parameter ~scope to the registration function. By default, the value is Eliom_common.global (visible for everyone). Other possible values: Eliom_common.session, Eliom_common.session_group, or Eliom_common.client_process.

It is possible to register again for a session, tab or group, services that have already been registered with public (site) visibility. In such cases, Eliom will try first tab services, then session services, then group services, and finally site services. This makes possible to register specialized versions of a service for one user, for example when she logs in.

A few enhancements

Displaying a "wrong password" message

In the current version, our Web site fails silently when the password is wrong. Let's improve this behavior by displaying an error message. To do that, we need to pass information to the service occurring after the action. We record this information in an Eliom reference with scope Eliom_common.request.

Define an Eliom reference:

let wrong_pwd = Eliom_references.eref ~scope:Eliom_common.request false

Modify the connection box this way:

let connection_box () =
  lwt u = Eliom_references.get username in
  lwt wp = Eliom_references.get wrong_pwd in
  Lwt.return
    (match u with
      | Some s -> div [p [pcdata "You are connected as "; pcdata s; ];
                       disconnect_box () ]
      | None ->
        let l =
          [Eliom_output.Html5.post_form ~service:connection_service
            (fun (name1, name2) ->
              [fieldset
	         [label ~a:[Eliom_output.Html5.a_for name1] [pcdata "login: "];
                  Eliom_output.Html5.string_input ~input_type:`Text
                                                  ~name:name1 ();
                  br ();
                  label ~a:[Eliom_output.Html5.a_for name2] [pcdata "password: "];
                  Eliom_output.Html5.string_input ~input_type:`Password
                                                  ~name:name2 ();
                  br ();
                  Eliom_output.Html5.string_input ~input_type:`Submit
                                                  ~value:"Connect" ()
                 ]]) ();
             p [Eliom_output.Html5.a new_user_form_service
                  [pcdata "Create an account"] ()]]
        in
        if wp
        then div ((p [em [pcdata "Wrong user or password"]])::l)
        else div l
    )

... and modify the connection_service handler:

Eliom_output.Action.register
    ~service:connection_service
    (fun () (name, password) ->
      if check_pwd name password
      then Eliom_references.set username (Some name)
      else Eliom_references.set wrong_pwd true);

Sending 404 errors for non-existing users

Our service user_service responds to any request parameter, even if the user does not exist in the database. We want to check that the user is in the database before displaying the page, and send a 404 error if the user is not. To do that, we will replace the module My_appl by Eliom_output.Any to register the service user_service:

Eliom_output.Any.register
  ~service:user_service
  (fun name () ->
    if List.exists (fun (n, _) -> n = name) !users
    then begin
      lwt cf = connection_box () in
      Eliom_output.Html5.send
        (html (head (title (pcdata name)) [])
              (body [h1 [pcdata name];
                    cf;
                    p [Eliom_output.Html5.a
                         ~service:main_service [pcdata "Home"] ()]]))
    end else
      Eliom_output.Html5.send
        ~code:404
        (html (head (title (pcdata "404")) [])
              (body [h1 [pcdata "404"];
                     p [pcdata "That page does not exist"]]))
    );

Using customized output module to simplify getting user data

When you want to assume that you have informations available in sessions, for instance when a site is mainly available to connected users, it becomes tedious to check everywhere that a reference is not None. We can build a version of a registration module to simplify that using Eliom_output.Customize.

We first need a translation module which checks for session informations and fall back to a default page if they are not available.

module Connected_translate =
struct
  type page = string -> Eliom_output.Html5.page Lwt.t
  let translate page =
    lwt username = Eliom_references.get username in
    match username with
    | None ->
      let connection_box =
        Eliom_output.Html5.post_form ~service:connection_service
          (fun (name1, name2) ->
    	    [fieldset
	      [label ~a:[Eliom_output.Html5.a_for name1] [pcdata "login: "];
               Eliom_output.Html5.string_input ~input_type:`Text
                                               ~name:name1 ();
               br ();
               label ~a:[Eliom_output.Html5.a_for name2] [pcdata "password: "];
               Eliom_output.Html5.string_input ~input_type:`Password
                                               ~name:name2 ();
               br ();
               Eliom_output.Html5.string_input ~input_type:`Submit
                                               ~value:"Connect" ()
	     ]]) ()
      in
      Lwt.return
        (html 
	  (head (title (pcdata "")) [])
          (body [h1 [pcdata "Hello"];
	         connection_box;]))
    | Some username -> page username
end

The translate function takes a function page and apply it with the current username if available and falls back to a default login page if not.

We can now make our own registration module.

module Connected = Eliom_output.Customize(Eliom_output.Html5)
                                         (Connected_translate)

let _ = Connected.register_service 
  ~path:[""] ~get_params:unit
  (fun () () ->
    Lwt.return
     (fun username ->
        Lwt.return (html (head mytitle [])
                   (body [h1 [pcdata ("Welcome " ^ username) ]; ]))))

The type of Connected.register_service forces us to have the heavy notation: Lwt.return (fun username -> Lwt.return...). We can make it lighter using

let ( !% ) f = fun a b -> return (fun c -> f a b c)

let _ = Connected.register_service 
  ~path:[""] ~get_params:unit
  !% (fun () () username ->
    return (html (head mytitle [])
	      (body [h1 [pcdata ("Welcome " ^ username) ]; ])))