<erl> out(A) -> {ssi, "TAB.inc", "%%",[{"embed", "choosen"}]}. </erl>

# Running yaws embedded in another application

Yaws is ideal for embedding within another larger erlang application. Many typical erlang applications are control applications in need of a webgui specific to the actual application.

In order to run Yaws inside another application, we need to perform the following steps.

1. Either integrate Yaws into the build system of the larger application, or specifically provide the `ebin` path to Yaws for the larger application.

2. Provide the application environment `{embedded, true}` to Yaws.

Since the containing application typically has its configuration data fed from internal databases or other sources, it's usually not feasible to let Yaws read its configuration data from `/etc/yaws/yaws.conf` when it's running in embedded mode.

To solve this, when Yaws is started in embedded mode, it doesn't read its configuration from `/etc/yaws/yaws.conf`, but rather it expects the larger application to feed its configuration through the function call `yaws_api:setconf(GC, Groups)`. The two arguments to this function are:

- `GC`, which is a `#gconf{}` record

- `Groups`, which is a list of lists of `#sconf` records

The details of these records are unimportant, and we'll talk more about the `yaws_api:setconf` function later. First, let's discuss two ways applications can start Yaws in embedded mode.

## Starting under your own supervisor

When not embedded, Yaws starts and runs as a regular application, but typically an application embedding Yaws wants to control it under its own supervisor(s). This means that an embedding application requires access to the Yaws supervisor child specifications. The exact list of Yaws child specifications depends on how the application intends to configure Yaws.

The `yaws_api:embedded_start_conf/1,2,3,4` functions return the information an application needs to configure Yaws and start it under application supervisors. There are four variants of this function:

1. `yaws_api:embedded_start_conf/1` takes a single argument, which is the document root path for the web server. This variant uses default values for the `#gconf{}` and `#sconf{}` records.

2. `yaws_api:embedded_start_conf/2` takes a document root, same as the first variant above, and also a server configuration list. Such a list is either a list of properties for a single web server, or a list of property lists for multiple servers. We'll explain more about server configuration lists later, but for now note that they're used to create suitable `#sconf{}` record values. This variant uses a default value of the `#gconf{}` record.

3. `yaws_api:embedded_start_conf/3` takes a document root and a server configuration list, same as the second variant above, and also a global configuration list. Such a list is a property list that provides global configuration settings for the embedded Yaws instance, and is used to create a suitable `#gconf{}` record value. We'll explain more about global configuration lists later.

4. `yaws_api:embedded_start_conf/4`, the final variant, takes the same 3 arguments as the previous variant and also takes a string to identify the embedded Yaws instance.

The values returned from these functions are described later.

### Global configuration list

A global configuration list is a property list that provides global configuration settings for an embedded Yaws instance. Each property is a tuple consisting of property name and value. Allowed property names are those of the field names of the `#gconf{}` record type; see `yaws.hrl` for more details. An example global configuration list is shown below:

          [{logdir, "/var/log/my_server"},
           {ebin_dir, ["/example1/ebin", "/example2/ebin"]},
           {id, "my_server"}].

### Server configuration list

A server configuration list is a property list that provides configuration settings for a given web server instance. Because Yaws supports multiple servers simultaneously listening for requests, it's possible to supply a list of server configuration lists so that multiple servers can be configured in a single `yaws_api:setconf` function call. Each element in a server configuration list is a tuple consisting of property name and value. Allowed property names are those of the field names of the `#sconf{}` record type; see `yaws.hrl` for more details. An example server configuration list is shown below:

          [{docroot, "/var/yaws/www"},
           {port, 8080},
           {listen, {127,0,0,1}},
           {appmods, [{"/", my_appmod}]}].

You can often determine the correct embedded server configuration by first creating a `yaws.conf` file specifying the desired configuration, running a stand-alone Yaws using it, and then dumping the server's configuration by executing the command `yaws --running-config`. Still, some elements of the embedded server configuration list are non-obvious. For example, to enable basic auth, you need to specify an `auth` proplist for each target directory. For example, to enable basic auth on "/":

          Docroot = "/var/yaws/www",
          Realm = "testrealm",
          SConfList = [{docroot, Docroot},
                       {port, 8080},
                       {listen, {0,0,0,0}},
                       {auth, [{docroot, Docroot},
                               {dir, "/"},
                               {realm, Realm},
                               {type, "Basic"},
                               {headers, ["WWW-Authenticate: Basic realm=\"", Realm,
                                          ["\"\r\n"]]},
                               {users, [{"foo","bar"}]}]}],

If you want to enable auth on multiple directories, specify a `{auth, AuthProplist}` element for each one.

Other elements, such as `dir_listings`, `access_log`, and `deflate`, are also non-obvious for embedded configuration because they're specified as part of the `#sconf.flags` element. You can find the server configuration flags, along with preprocessor macros for setting them on an `#sconf{}` record, in the `yaws.hrl` include file.

### Using embedded_start_conf

The `yaws_api:embedded_start_conf/1,2,3,4` functions return `{ok, SCList, GC, ChildSpecs}`. The latter three elements of this tuple are described below.

- `SCList` is a list of `#sconf{}` records created using the values from the passed-in server configuration lists

- `GC` is a `#gconf{}` record created using the values from the passed-in global configuration list

- `ChildSpecs` is a list of supervisor child specifications for the components of Yaws the application wants to start

Below is an example of using the `yaws_api:embedded_start_conf/1,2,3,4` functions. It follows the steps of obtaining the embedded configuration and child specifications, starting the Yaws children under its own supervisor, and then setting the Yaws configuration.

    Id = "my_server",
    GconfList = [{logdir, "/var/log/my_server"},
                 {ebin_dir, ["/example1/ebin", "/example2/ebin"]},
                 {id, Id}],
    Docroot = "/var/yaws/www",
    SconfList = [{docroot, Docroot},
                 {port, 8080},
                 {listen, {127,0,0,1}},
                 {appmods, [{"/", my_appmod}]}],
    {ok, SCList, GC, ChildSpecs} =
        yaws_api:embedded_start_conf(Docroot, SconfList, GconfList, Id),

    %% assume our supervisor is registered as my_sup
    [supervisor:start_child(my_sup, Ch) || Ch <- ChildSpecs],

    %% now configure Yaws
    yaws_api:setconf(GC, SCList),

## Starting yaws as an embedded application

The four functions `yaws:start_embedded/1,2,3,4` start Yaws in embedded mode using `application:start`. This approach differs from the one above in that the embedding application need not start any Yaws components under its own supervisors, nor does it need to explicitly call `yaws:setconf` to set the Yaws configuration. This approach is slightly simpler but also gives the embedding application less control over Yaws.

The arguments for these four functions are identical to those for the `yaws_api:embedded_start_conf/1,2,3,4` functions described earlier.

See the example below:

    %%
    %% Check with inet:i(). that you are listening to port 8000!
    %%
    1> yaws:start_embedded("/home/tobbe/docroot").

    %%
    %% Alternative ways
    %%
    1> yaws:start_embedded("/home/tobbe/docroot",
                           [{servername, "sej"}, {listen, {0,0,0,0}}]).

    1> yaws:start_embedded("/home/tobbe/docroot",
                           [{servername, "sej"}, {auth_log, false},
                            {listen, {0,0,0,0}}],
                           [{copy_errlog, false}]).

If you need more control on how to setup Yaws in embedded mode, use the `yaws_api:embedded_start_conf` functions instead.

## A very small example

We provide a minimal example that embeds Yaws in a small Erlang function.

The `ybed` module is very small and is named `ybed.erl`. It has an accompanying simple supervisor named `ybed_sup.erl`.

If you compile both modules, you can run them as shown below:

<verbatim> 1> {ok, Sup} = ybed_sup:start_link(). {ok,<0.40.0>} 2> =INFO REPORT==== 12-Apr-2010::02:42:09 === Yaws: Listening to 0.0.0.0:8888 for <1> virtual servers: - http://foobar:8888 under /tmp

2> </verbatim>

The actual web server runs inside the larger application. The configuration of the web server was programmatically fed into Yaws from the surrounding application, in this case, the `ybed.erl` module. Note also how the Yaws children are started under the same `ybed_sup.erl` supervisor as the code in the `ybed` module itself. The `ybed` serves only to start the Yaws children that need to be run under its supervisor, after which it exits normally. For this reason, its child specification uses the `temporary` restart strategy, since it need run only once in the lifetime of its supervisor.

## The opaque field in the sconf structure

The `#sconf{}` record, which is constructed by the program that starts and configures Yaws, contains a field, `SC#sconf.opaque`.

This field is passed into the `#arg{}` record, so that any application specific configuration data which is needed by the `.yaws` pages that make up the web GUI application, is easily available there.

In essence, if we construct the `#sconf` as

<verbatim> SC#sconf{opaque = {mystruct, foobar}, ..... </verbatim>

A `.yaws` web page can then do:

<verbatim> out(Arg) -> MyStruct = Arg#arg.opaque .....

</verbatim>

thus passing data from the surrounding applications configuration routines down to each `.yaws` web page.

Another important fact to consider when choosing whether to run your Yaws application as an embedded yaws app or not is that all the Yaws control functions are disabled when we use Yaws as an embedded web server, including capabilities such as `yaws --ls` and `yaws --stop`. Embedding thusassumes that you already have support for this type of functionality in your application.

Finally, an interesting appmod definition that may apply to many embedded yaws installations is the `/` appmod with a set of exclude dirs. Here is an example server configuration list:

<verbatim> [... {appmods, [{"/", myapp, [["js"], ["top", "static"], ["icons"]]}]}, ...]. </verbatim>

or in `#sconf{}` record terms:

<verbatim> SC#sconf{..... appmods = {"/", myapp, [["js"], ["top", "static"], ["icons"]]}, .... </verbatim>
<erl> out(A) -> {ssi, "END2",[],[]}. </erl>