BINETIX NETWORK

The MVC web engine is fully integrated within the AGE's Web Server. Once the server is loaded as SaaS by Node's Agent, the Web engine is activated and ready for use.

Your Web applications are automatically handled by the Web controller - the core-system module of this engine where all HTTP requests and responses are processed.

Each AGE Web Apps is a software package of compiled modules and files that consist of:

•One Web application controller.

•One Web application resource file (optional).

•Multiple model controllers where the business logic is organized and implemented.

•Multiple view controllers where any representation of information is prepared and returned back to the client as a compiled Web-page.

•Multiple language controllers for resource localization invoked by the model and view controllers.

•Other JavaScript and resources files used by the controllers.

Note: All MVC controllers are compiled to byte-code compatible with the BEAM virtual machine.

Note: To deploy and use your Web Apps it is essential to configure your Web-site correctly, otherwise the application controllers shall not be invoked.

The AGE Web App could be developed, compiled, and deployed without any application-specific configurations, however, the following naming conventions should be considered:

1)All identifiers and module names should be maintained in lower-case ASCII characters. This is highly recommended especially when you are making cross-platform deployments where the file systems are case-sensitive, like deployments between Windows and Linux, for example.

2)Each web-application has to have an unique identifier. This identifier is defined within the application controller, or externally, within the application resource file.

3)The software package of the Web App must be deployed under one directory config/web/apps/<webapp_identifier> with two mandatory sub-directories:

a.bin - to deploy the compiled modules

b.src - to store the source code with all resource files of your web-solution

4)The application controller must be named as <webapp_identifier>_web.erl (when implemented on Erlang programming language)

5)The model controller must be named as <webapp_identifier>_web_<model_id>.erl (when implemented on Erlang programming language)

6)The view controller must be named as <webapp_identifier>_web_<model_id>.dtl (when Django templates are used)

7)The language controller must be named as <webapp_identifier>_web_<model_id>.lang (includes UTF-8 text-based terms of #age_web_lang{} record)

The Web-application controller is an Erlang module that inherits the age_web_app behavior. The following call-back functions are required by this behavior:

•on_web_config() - invoked when:

oThe application is loaded/reloaded by AGE Web controller;

oThe application is get compiled, or

oOn demand by calling age_web_app:get_config/0.

•on_web_model(Controller, Request) - invoked before requesting a business-model controller. Two formal parameters are provided by this call-back:

oController is an atom that refer to particular business model;

oRequest contains detailed information about the HTTP request within #age_web_request{} record.

The business logic inside your web application can be grouped, implemented and invoked by multiple business-model controllers.

The model controller is an Erlang module that inherits the age_web_model behavior. The following call-back functions are required by this behavior:

•on_web_settings() - invoked on demand by calling age_web_model:get_settings/1 or age_web_model:get_settings/2.

•on_web_request(Request, WebApp, Session) - invoked by AGE Web controller on routing the HTTP request to the right business-model controller. This call-back provides the following formal parameters:

oRequest contains detailed information about the HTTP request within #age_web_request{} record.

oWebApp contains information about your Web App stored within #age_web_app{} record.

oSession contains contextual information about the current web session of the HTTP request stored within #age_web_session{} record.

Each business-model controller of AGE Web App could have one associated view controller. By design, the view controller is preparing and rendering information provided by the model controller using templates. The current implementation of the Web engine supports Django 1.6 templates.

The source code of the web templates is stored in external DTL file in accordance with the specified AGE Web App naming conventions.

The web templates are compiled together with all Web App components and are deployed on site as BEAM byte-code.

The localization of web content or other string resources is handled by the language controllers.

The source code of language controller is described as UTF-8 text-based terms of #age_web_lang{} record saved in external files in accordance with the specified AGE Web App naming conventions. The language controllers can be invoked on demand by identifier, or invoked automatically by the view controllers as follows:

•Each view controller could have one associated language controller with the same identifier as the view controller. In this case the language controller is loaded and invoked automatically by the view controller when the page is rendered and the HTTP response is prepared.

•The language controllers could be named as stand-alone controllers with unique identifiers. In this case the language controller can be invoked only on demand.

The language definitions are compiled together with all Web App components and are deployed on site as BEAM byte-code.

The Web sessions are special kind of parameters management facility  for creating, updating and deleting temporary data, associated with particular HTTP requests. These sessions are managed by AGE's Web controller, and can be accessed via age_web_session API.

In fact, the AGE Web sessions are fully controlled by your solution. Furthermore, you can choose how to store your data. By default, the Web controller is offering a simple file storage system into your config directory. However, you can create your own storage handler by inheriting the age_web_session behavior. For example, you could centralize your Web sessions into external database using ADBC or other DB controller.

Usually the AGE Web Apps are developed, compiled and deployed in a package with an AGE/Erlang application when you want to extend your applications with Web API and/or GUI. However, as explained already, the Web Apps could be developed and deployed also as stand-alone solutions. Therefore, depending on your particular needs, you could extend your existing solution with new Web project (see make_app.config template for Erlang Apps), or you could create an independent one.

Your Web solution has to have make_app.config aligned with the following instructions:

a)The Erlang extension should be activated.

b)The libs section of solution configuration element should refer as minimum to the latest AGE node distribution package. The ErlyDTL application is required in case you want to develop your own view controllers with support of Django 1.6 templates.

c)The spec section of solution configuration element is not required unless you are extending an existing AGE/Erlang application.

d)The solution configuration element has to have as minimum one software project dedicated for web development. Here you could add more then own projects when you are developing multiple Web Apps into one solution.

e)The Web App must be constructed in accordance with the directory tree prerequisites for AGE Web solutions.

f)To perform compilation and deployment activities you have to define tasks discussed at AGE/Erlang "Erlang Apps" page.

The resource files is an optional asset for your Web App. Take into consideration that the application configuration can be returned by on_web_config() call-back.

The advantage to keep the configuration file outside of the compiled Application Controller is that you can change at run-time the Web App settings. For example, you could enable or disable the Web App just by changing the state field of the #age_web_app{} record.

{
  age_web_app, my_solution, #{
    title   => "My Web Solution",
    state   => enabled,
    version => #{major => 1, minor => 0, release => 0, build => 1},
    models  => [my_solution],
    context => []
  }
}.

The configuration attributes of AGE's Web Server are discussed in details at "Configuration" page.

Here the assumption is that you are already aware about the terms and the structure of the Web-site configuration. Therefore, we shall focus your attention only at these attributes related to the Web App initialization, invocation and accessibility. In case of necessity, please go back to "Configuration" page to get more clarifications and details.

Now, let's open the age_web.config file stored into your config directory. A fragment of such configuration file is shown below.

Your Web App needs to be declared by its identifier in order to be accessible in the context of particular web-site.

In the sample below, the web-site "MY WEB SOLUTIONS" at port 8070 has two Web Apps declared by their identifiers in the apps field - "my_solution" and "syslog". Furthermore, the web-site has a special prefix applied before invocation of any of those apps, named "web".

Consequently, the simplest invocation of our Web App from web-browser could be: http://localhost:8070/web/my_solution/

This will produce an HTTP request from your web-browser to the Application controller of your Web App.

Take a closer look of these global configuration elements:

•web_locale - selects the default or particular language ID used for page localizations. This parameter can be set on web-site level too.

•web_config_root - specifies the root directory of your Web configuration. By default, this directory is stored under your application's config directory.

•web_app_root - specifies the root directory of your Web Apps.

{age_web, [
  {web_locale,                    default},
  {web_config_root,               "${config_path}web/"},
  {web_app_root,                  "${config_path}web/apps/"},
 
  {web_sites, [
    {8070, httpd, [
      {name,                      "MY WEB SOLUTIONS"},
      {apps,                      [my_solution, syslog]},
      {app_prefix,                "web"},
%      {maintenance,              false},
%      {maintenance_action,       undefined},
      {locale,                    default},
...

The application and model controllers can be compiled with MAKE_APP or other tool-sets and development environment.

The compiled modules should be generated and stored in ebin directory of the Web App. See the template of make_app.config for more details.

You can compile and recompile view and language controllers of Web App at run-time using age_web_app API:

•Use  to compile/1 to compile all view and language controllers;

•Use  to compile_view/1 to compile all view controllers;

•Use  to compile_context/1 to compile all language controllers.

The age_web_app API generates BEAM byte-code files, and stores these files into ebin directory of your Web App as follows:

➢The view controllers are named with suffix "_view", like <controller>_view.beam

➢The view language are named with suffix "_lang", like <controller>_lang.beam

The Web App files are stored into ebin directory.

You can release your web solution by providing only this directory under the same directory structure without any server-site source code.

This includes all your Django templates, the JavaScript code associated with the templates, and all your localization definitions. The software package can be redeployed from one operating system to another just by copying the directory structure of your solution. Please take into consideration the file names case-sensitivity of the file systems when your are performing such OS migrations.