Framework Internals

Request processing workflow

1. Request is catched by webserver. It handles static resources.
2. If not processed, request is passed to web server interface (currently there is only s_platform_inets for inets server. This interface extracts GET and POST parameters and executes s_dispatcher:dispatch()
3. s_dispatcher routes request (using s_route.parse_request)
   1. If requested controller doesn’t exists, 404 page rendered
4. Requested controller is executed
   1. If controller fails, error page rendered
5. View requested by controller is rendered
   1. 404 page is rendered if view not found
   2. Error page is rendered if rendering fails
6. Response is converted to web server specific form and is rendered.

Routing

Routing file is a set of records, that describes routes. Following routes are supported:

{Path, [Params]} % Page route

{Method, Path, [Params]} % RESTful page route

- Difference between {Path, [Params]} is the same as {any, Path, [Params]}.

- Path can be atom ‘root’. In this case it matches root route.

- Path in routes may have wildcard components:For example route
“test/:id” will match to “test/123” path (and request will be routed
with parameter id equal to “123”)

Directory structure

  app
    \controllers
    \views
  bin
  config
  lib
  logs
  public
  tmp

• app/controllers directory contains controllers. Currently controllers have no namespaces
• app/views directory contains views. Template engine is identified by view extension.
• app/ebin used internally for compiled controllers/views
• bin directory contains useful scripts (currently only for start up server)
• config directory contains:
  • application.conf is main configuration file.
  • routes.conf is file with routing configuration.
• lib directory with Erlang OTP applications (such steroids framework, erlydtl templating engine, etc)
• logs directory contains application logs
• public directory contains static files (images, stylesheets, etc)
• tmp directory contains temporary stuff like uploaded files

Reloader

This subsystem is used to reload different kind of files:

1. Controllers
2. Views

It automatically tracks if file was changed and executes compile function when reload required. It utilizes callback module with following interface:

compile_and_load(RealPath, TargetModule)

get_real_path(Path)

get_module_name(Path)

• get_module_name returns module name, for specific (virtual) path. F.e. it generates module name for path to template.
• get_real_path returns file system path to specified virtual path. F.e. real file path for template.
• compile_and_load compiles file on specified real path to Module.

Template engine integration

You can easily integrate your template engine:

Step 1. Adapter creating

You should create adapter with following interface:

compile(Path, Module)

• compile function compiles template with absolute path Path to Module

Also you should add your template to config file:

config/application.conf
{template_engines, [
                    {s_erlydtl_adapter, ["dtl"]}
                   ]}.

It’s list of pairs: template engine module name with list of extensions for this template engine.