Skip to content
This repository
Fetching contributors…

Cannot retrieve contributors at this time

file 331 lines (258 sloc) 11.516 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 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331
<erl>
out(A) ->
       {ssi, "TAB.inc", "%%",[{"embed", "choosen"}]}.
</erl>


<div id="entry">


  <h1>Running yaws embedded in another application</h1>
  <p>
    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.
  </p>

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

  <ol>
    <li> <p>Either integrate Yaws into the build system of the larger
    application, or specifically provide the <code>ebin</code> path to Yaws
    for the larger application. </p>
    </li>

    <li><p> Provide the application environment <code>{embedded,
    true}</code> to Yaws.</p>
    </li>
  </ol>

  <p>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
  <code>/etc/yaws/yaws.conf</code> when it's running in embedded mode.</p>

  <p>To solve this, when Yaws is started in embedded mode, it doesn't read
  its configuration from <code>/etc/yaws/yaws.conf</code>, but rather it
  expects the larger application to feed its configuration through the
  function call <code>yaws_api:setconf(GC, Groups)</code>. The two
  arguments to this function are:</p>
  <ul>
    <li><p><code>GC</code>, which is a <code>#gconf{}</code> record</p></li>
    <li><p><code>Groups</code>, which is a list of lists of <code>#sconf</code>
    records</p></li>
  </ul>

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

  <h2>Starting under your own supervisor</h2>

  <p>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.</p>

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

  <ol>

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

    <li><p><code>yaws_api:embedded_start_conf/2</code> 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 <code>#sconf{}</code> record
    values. This variant uses a default value of the <code>#gconf{}</code>
    record.</p></li>

    <li><p><code>yaws_api:embedded_start_conf/3</code> 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 <code>#gconf{}</code> record
    value. We'll explain more about global configuration lists
    later.</p></li>

    <li><p><code>yaws_api:embedded_start_conf/4</code>, the final variant,
    takes the same 3 arguments as the previous variant and also takes a
    string to identify the embedded Yaws instance.</p>
  </ol>

  <p>The values returned from these functions are described later.</p>

  <h3>Global configuration list</h3>

  <p>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 <code>#gconf{}</code> record type; see
  <code>yaws.hrl</code> for more details. An example global configuration
  list is shown below:</p>

  <div class="box">
    <pre>
      [{logdir, "/var/log/my_server"},
       {ebin_dir, ["/example1/ebin", "/example2/ebin"]},
       {id, "my_server"}].
    </pre>
  </div>
  <br/>

  <h3>Server configuration list</h3>

  <p>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 <code>yaws_api:setconf</code>
  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 <code>#sconf{}</code> record type; see
  <code>yaws.hrl</code> for more details. An example server configuration
  list is shown below:</p>

  <div class="box">
    <pre>
      [{docroot, "/var/yaws/www"},
       {port, 8080},
       {listen, {127,0,0,1}},
       {appmods, [{"/", my_appmod}]}].
    </pre>
  </div>
  <br/>

  <h3>Using embedded_start_conf</h3>

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

  <ul>

    <li><p><code>SCList</code> is a list of <code>#sconf{}</code> records
    created using the values from the passed-in server configuration
    lists</p></li>

    <li><p><code>GC</code> is a <code>#gconf{}</code> record created using
    the values from the passed-in global configuration list</p></li>

    <li><p><code>ChildSpecs</code> is a list of supervisor child
    specifications for the components of Yaws the application wants to
    start</p></li>

  </ul>

  <p>Below is an example of using the
  <code>yaws_api:embedded_start_conf/1,2,3,4</code> 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.</p>

  <div class="box">
    <pre>
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),
    </pre>
  </div>

  <h2>Starting yaws as an embedded application</h2>

  <p>The four functions <code>yaws:start_embedded/1,2,3,4</code> start Yaws
  in embedded mode using <code>application:start</code>. 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 <code>yaws:setconf</code> to set the Yaws
  configuration. This approach is slightly simpler but also gives the
  embedding application less control over Yaws.</p>

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

  <p>See the example below:</p>

<div class="box">
  <pre>
%%
%% 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}]).

  </pre>
</div>

  <p>If you need more control on how to setup Yaws in embedded mode, use
  the <code>yaws_api:embedded_start_conf</code> functions instead.


  <h2>A very small example</h2>

  <p>We provide a minimal example that embeds Yaws in a small Erlang
  function.</p>

  <p>The <code>ybed</code> module is very small and is named <a
  href="code.yaws?file=/ybed.erl"><code>ybed.erl</code></a>. It has an
  accompanying simple supervisor named <a
  href="code.yaws?file=/ybed_sup.erl"><code>ybed_sup.erl</code></a>.</p>

  <p>If you compile both modules, you can run them as shown below:</p>

<div class="box">
  <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>
</div>

<p>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 <a
href="code.yaws?file=/ybed.erl"><code>ybed.erl</code></a> module. Note also
how the Yaws children are started under the same <a
href="code.yaws?file=/ybed_sup.erl"><code>ybed_sup.erl</code></a>
supervisor as the code in the <code>ybed</code> module itself.

<h2>The opaque field in the sconf structure </h2>

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

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


<p>In essence, if we construct the <code>#sconf</code> as</p>

<div class="box">
  <verbatim>
SC#sconf{opaque = {mystruct, foobar},
         .....
  </verbatim>
</div>


<p>A <code>.yaws</code> web page can then do:</p>

<div class="box">
  <verbatim>
out(Arg) ->
   MyStruct = Arg#arg.opaque
   .....

  </verbatim>
</div>

<p>thus passing data from the surrounding applications configuration
routines down to each <code>.yaws</code> web page.</p>

<p>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 <code>yaws --ls</code> and <code>yaws
--stop</code>. Embedding thusassumes that you already have support for this
type of functionality in your application.</p>

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

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

<p>or in <code>#sconf{}</code> record terms:</p>

<div class="box">
  <verbatim>
SC#sconf{.....
         appmods = {"/", myapp, [["js"], ["top", "static"], ["icons"]]},
         ....
  </verbatim>
</div>


</div>


<erl>
out(A) -> {ssi, "END2",[],[]}.
</erl>
Something went wrong with that request. Please try again.