Root appmod

An example of a use-case where there is only one appmod. The universal controller.

yaws.conf:

   # ...
   appmod = </,myappmod exclude_paths images>
   # ...

myappmod.erl:

    -module(myappmod).
    -compile(export_all).

    out(_) ->
        {yssi,"myhtml.yaws"}.

    shout(Word) ->
        {ehtml, {em,[],Word}}.

myhtml.yaws:

    <h1>say hello</h1>

    <erl>
        out(A) ->
            myappmod:shout("Tell me a tale").
    </erl>

    <img src="/images/logo.png" />

If the exclude_paths directive is missing from the appmod declaration then the <img> tag is going to try to load the logo.png file using myappmod, essentially recursing the flow. Both / and /image/logo.png return the output of out/1.

NOTE:
I tried to experiment with <a href="http://yaws.hyber.org/yman.yaws?page=yaws_api">{page, Page}</a> instead of using exclude_paths directive but images are not displayed, although the response’s Content Length is correct. (Try it with shoppingcart/junk.png.) It also returns anything else in the docroot just fine.

myhtml.yaws:

    <h1>say hello</h1>

    <erl>
    out(A = #arg{pathinfo = Path}) ->
        {page, A#arg.pathinfo}.
    </erl>

    <img src="/images/logo.png" />

On the other hand, converting the shopping cart example into an appmod, images in the shoppingcart directory are returned and displayed.

yaws.conf:

	
…

    appmods =  <shoppingcart, shopcart>
	
…

shoppingcart/shopcart.erl:

out(A=#arg{pathinfo = “/loginpost.yaws”}) →

    loginpost(A);

out(A = #arg{pathinfo = P}) →

    Page = case P of

               “/index.yaws”         → index;

               “/buy.yaws”           → buy;

               “/logout.yaws”        → logout;

               “/shopcart_form.yaws” → formupdate;

               Path → {page, “/shoppingcart” ++ Path}

           end,

    case is_atom(Page) of

        true  →

            login_check(A, Page);

        false →

            Page

    end.

The previous entry for this wiki page:

Yaws should serve all static files in docroot, THEN appmods. Here’s why…

As I made my way through all of the DOC and all that Google had to offer…. and then a few postings on Erlyweb. I became apparent to me that root-appmod is a bad thing. In fact, with the exception of ONE edge use-case there is no real use. But first some background:

When it comes to Appmod, yaws provides three options. None, one or many. Skipping the none. The one will only function in the barest of implementations. Where this page is the ONLY page/resource to be retrieved and all external resources are external.

Here is an example of a use-case where there is only one appmod. The universal controller.

yaws.conf:
   ...
   appmod = </,myappmod>

myappmod.erl:

   ...
   out(A) ->
        {yssi,"myhtml.yaws"}.

   say(Word) ->
      Word.

   shout(Word) ->
      {em,[],Word}.

myhtml.yaws:
…

   < h1 >say hello< /h1 >

   < erl >

      out(A) ->  shout("my name").

   < /erl >

   < img src="/images/logo.png" >

the problem with the code above is that the IMG tag is going to load the logo.png file using myappmod. Essentially recursing the flow. Even if you had an instance of apache or lighttpd in front of the yaws deployment to capture the static files it would never be able to catch all of the additional edge cases. Most of my browsers try to load /favicon.ico with every page load. So we’d have yet another rule for gateway.

Keep in mind, using a gateway http server may actually hinder yaws performance. (See the docs on apache vs yaws.) To my knowledge there have been no tests on apache vs apache+yaws; etc…

I do not need to go into examples of the MANY, except to say that since you would not be defining . And everything else should work as expected.

PS: it would be nice if there were some real doc on the yaws.conf:

PPS: it would be nice if there were some real doc on the yaws.conf:mod_rewrite

PPPS: it would be nice if there were a {yssi,“file.yaws”, Bindings}

FWIW: no_appmod + mod_rewrite + binding = root_appmod