Question

I have got a basic server-side Erlang app (not fully OTP’d yet) which I start on a command-line. I want to turn it into an interactive system using a browser as GUI with Nitrogen (version 2.0.4). The general plan is to

• turn the current module into a gen_server as the MODEL part; it analyses data and generates events from it which reflect certain properties of the data I am interested in.
• add a CONTROLLER module which is both gen_event (to pick up events generated by the model) and gen_server (to allow queries from the GUI frontend)
• use Nitrogen as the VIEW, updating the relevant pages with the Ajax facilities through calls to the controller module (which in turn queries the model)

As far as I can see I would want a general application supervisor with three children: the model, view, and controller. Then they would talk to each other via the APIs mapped to the OTP communication modes.

And this is where I am stuck: should I put all of this into the Nitrogen directory tree? Should I set up a new app dir structure and have the three components (including Nitrogen) under there? What exactly do I need to do to start up the Nitrogen server as a child of my app supervisor (the Nitrogen start script looks rather more complex than I expected)? I have started going through Erlang and OTP in Action, but haven’t quite finished it yet. And I need to demo the system the day after tomorrow 😉

What I want is to type “start.sh” on the command-line, and then use the browser to connect to the app via Nitrogen.

Answer 1

Because of the way the Nitrogen App is built, you should not build your application tightly coupled to it. Rather, you build your application, provide APIs to Nitrogen (APIs you will call from your Nitrogen events e.t.c).

Then you would package your app as an OTP filesystem, put it into the apps folder of nitrogen. When nitrogen makes or starts it will add the ebin paths of your apps as long as they are in its apps directory.

For example: the model and controller will be implemented within your application. Then in your application you expose function calls in your module (which could be gen_server behaving) which you would call right from your nitrogen page. The beauty is all these would be in the same code path.

What to do: you look at the Nitrogen quickstart.sh script, at the point where it starts erlang VM.

echo "Starting Nitrogen on Inets (http://localhost:8000)..."
erl \
    -name YOUR_NODE_NAME_HERE \
    -pa ./ebin ../apps/*/ebin ../apps/*/include \
    -env ERL_FULLSWEEP_AFTER 10 \
    -eval "application:start(nprocreg)" \
    -eval "application:start(quickstart)" \
    -eval "application:start(YOUR_APPLICATION)"

if your application is not OTP like, then create a folder called “ebin” in which you will put the beam files you have.The create a folder called: “my_app-1.0” and paste this ebin folder in that folder

  Nitrogen--|--/apps --|--/my_app-1.0 --|--/ebin
            |--/doc
            |--/rel
            |--/support
            |--/Quickstart

The full path to your beam files should be

"$NITROGEN/apps/my_app-1.0/ebin"

.
Whenever Nitrogen starts it will add to the code path all your beam files. Then, if in your code you have the function that starts your stuff say: main_server:start().
You will change the quickstart.sh found in $NITROGEN/Quickstart/quickstart.sh to appear this way.

echo "Starting Nitrogen on Inets (http://localhost:8000)..."
erl \
    -name YOUR_NODE_NAME_HERE \
    -pa ./ebin ../apps/*/ebin ../apps/*/include \
    -setcookie YOUR_FUNNY_COOKIE_HERE \
    -mnesia dir '"PATH/TO/MNESIA/DIRECTORY"' \
    -env ERL_FULLSWEEP_AFTER 10 \
    -eval "application:start(nprocreg)" \
    -eval "application:start(quickstart)" \
    -eval "main_server:start()"

The advantage of this is that if you happen to change your view to say erlyweb, erlang web, you will not need to make changes to your model or controller but rather you exposed APIs that can be called from any view type library.