Developing web apps using Erlang-Web

  • Published on
    16-Apr-2017

  • View
    5.142

  • Download
    3

Embed Size (px)

Transcript

Server-side web developmentUsing ErlangWeb

Stefan Comanescu

A brief history of Erlang

Initially developed by Joe Armstrong in 1986, as a proprietary language within Ericsson for usage in telephony applications

Named after the Danish mathematician Agner Krarup Erlang

First versions were running on a Prolog interpreter, a C emulator and a compiler were later written, for reasons concerning performance

In 1997 bit syntax and binaries were added (for protocol programming) and in the same year work started on OTP

Released as open source in 1998

SMP support was added in 2006

Why Erlang ?

ConcurrencyActor model (no threads, no locks, no shared memory, only asynchronous message passing)

Fault ToleranceProcess linking, supervising trees, distribution and event managers help in keeping the system going when processes crash.

DistributionAbstracts the difference between local and distributed message passing

Runs on Yaws or Inets web server

MVC (Model-View-Controller) paradigmModel data (stored in mnesia/dets tables) manipulation

Templates XHTML files and templating engine

Controller Erlang functions called on dispatching rules

Dispatcher Request routing based on regexp

Request dictionary

Reusable components (ecomponent)

Caching system

Annotations

Directory structure

For creating the directory tree of a new application, ./bin/add is executed which generates the directories:

config dispatch.conf, errors.conf, projects.conf, server specific .conf

docroot static files and folders (except html templates), e.g : js, css, img

lib framework applications and applications created by the user

log logs created while running in embedded mode and server specific log

pipes OS pipes for cummunicating with the shell while in embeded mode

priv project specific data (usually static html)

release separated subdirectories for each release version

templates all the template filestemplates/cache cached files

Generator script(bin/generate.erl)

Module responsible for generating the boilerplate code

General format: ./bin/generate.erl TYPE -argument_name -argument_value

Generating a controller:./bin/generate.erl controller --app app_name --name name_of_the_generated_model --functions (fun1, fun2)

./bin/generate.erl model --app app_name --name name_of_the_generated_model --hrl name_of_the_header_file Generates a file named wtype_name where 'name' is the given arg

Generates basic CRUD functionality for the given header

DispatcherDispatching types

Static dispatching: serving static content, like xml pages, media or javascript. The controller is not accessed. The server first searches for the file in the templates dir, afterward in the docroot dir. For faster retrieval of static content, they should be placed in the docroot dir and enoent should be placed instead of File {static, Regexp, File} | {static, Regexp, enoent}

Dynamic dispatching: the controller will handle the URL requests allowing specific content to be created or retrieved on demand{dynamic, Regexp, {Module, Function}}

Alias dispatching: if the URL matches the Regexp, the rule of NewURL will be triggered{alias, Regexp, NewURL}

Delegates: passing the URL to another dispatch config file, only helps in structuring the application{dynamic, delegate, Regexp, File}

Dispatcher evaluation order

Docroot content is served (files that point to 'enoent')

Dynamic entries are matched with their URLs

Static routes are matched

If no patterns are matched, a 404 error page is displayed

Request dictionary

Temporary storage created for each HTTP request, lives as long as the request lives

Provides an easy to use API for setting and getting values from the dictionary

Used for retrieving GET/POST request data from the query string and also used by the expanding templates

API:wpart:fget(post:user_address).

wpart:fget(get:page_number).

wpart:fset(user,[[{name,bogdan},{age,21}],[{name,marian},{age,18}]]).

Request dictionarySample browser request

{,[ {"get",[]}, {"post",[ {"action_type","add"},{"id",[]},{"type","user"},{"user_password","nuitizic"}, {"user_phone","07273447823"},{"user_cnp","1901231231723"}, {"user_lastname","alex"},{"user_firstname","popescu"} ] }, {"__https",false}, {"__cookies",[{"eptic_cookie","nonode@nohost-7985065742948673537"}]}, {"session",[{"user_id","1111111111111"}, {"groups",["admin"]}]}, {"__path","admin/add"}, {"__cookie_key","nonode@nohost-7985065742948673537"},{"__ip",{127,0,0,1}}, {"__controller",controller} ] }

Controller

Responsible for handling the user's requests

Has the arity 1, getting a proplist (list of key-value pairs)

Handles user input, model manipulation, etc.

Must return a tuple, which tells the template what to do:{redirect, URL} | {content,html,Data} | {content,text,Data} | {json,Data} | {template,Template} | {error,Code} | {headers, Headers, RetVal} where : Headers is a list of headers, of the form {cookie, CookieName, CookieValue, CookiePath, CookieExpDate}

Retval is one of the previous touples

Templating Engine

The view is represented by a regular XHTML file with a few namespaces defined.

The most commonly used namespace, wpart, is always expanded by the framework . When the parser meets for example, it will call the function wpart_lookup:handle_call/1, with the whole xmerl parsed tag as an argument.

Templating EngineWpart tags

wpart:choose provides if functionality; it contains the tags:

Something else

The test is an expression of the form test=1 + 1 eq 2, where the operators can be:eq, neq, lt, le, gt, ge (for =:=, =/=, , ==)

Templating EngineWpart tags

wpart:list provides for functionality; it contain the attributes:select, specified what part of the list we want, attributes:map renders every element in the list

head renders only the first element

tail renders the last element of the list

filter has an attribute named pred for filtering the list

find the first element of the list where pred is evaled to true

sort sorts according to the pred attribute

as, every element of the list from inside the wpart:list will be known as the value of this attribute

Templating EngineWpart tags

list, specifies the list from the request dictionary that we want to traverse

pred, predicate used for some of the select tags, it's optional

e.g. :

Templating EngineWpart tags

wpart:lookup provides access to a value from inside the request dictionary, it contains the attributes:key, the key from the dictionary that we are looking for

format, optional formatters

type, can have the values text (default) or html, setting html turns off html-escaping and can be dangerous

e.g :

Templating Engine (wtpl)

Tool for faster building of html pages, by expanding or replacing content from other template files

Allows building of websites from small chunks of html

It helps with :Code re-usage

Not writing the same thing multiple times

Updating the common part of the pages only one time

Templating Engine (wtpl)Wtpl tags

- the location where the wtpl:content with the corresponding name will be placed

- specifies which template will be filled with the content provided by the wtpl:content content

- content that will fill the wtpl:include tag which has the same name as the tag 'name' attribute, in the file specified by wtpl:parent

Templating Engine wpart_gen

Enables building of HTML code directly from within Erlang modules.

wpart_gen:load_tpl(Namespace, Name, Path) loads the html snippet specified by Path, and saves it in the memory under the key {Namespace,Name}

Tpl = wpart_gen:tpl_get(Namespace,Name) gets the snippet from memory

wpart_gen:build_html(Tpl,Values) builds the template file with the values from the list Values

Templating Engine wpart_gen Template Format

Anonymous slots:

Named slots:

Templating Engine wpart_gen Passed Values

Anonymous slots: [Value | ] All fields must be filled.

Named slots: [{ slot_name, Value} | ] The unfilled slots will remain empty.

Controlling cache

persistent data cached this way is not removed until the server is restarted or the cache is invalidated

timeout every T minutes the cache is traversed and expired content is removed, each URL can have a different timeout.

no_cache

Controlling cache

The caching configuration is made directly from the dispatch configuration file. E.g. : {dynamic, ^/index/?$,{main,home},[{cache,persistent}]}.

{static, ^/faq$,doc/faq.html,[{cache,normal}]}.

{dynamic, ^/posts/?$,[{cache,{timeout,30}}]}.

{dynamic, ^/the_time/?$,[{cache,no_cache}]}.

Controlling cache

For controlling cache based on aspects other than URL, the tuple {is_cachable_mod, my_mod} should be placed in the configuration(config/project.conf) file.

Before processing any request, the function my_mod:is_cachable() will be called

The function is_cachable() should return true if the request should be cached under the URL key

{true,NewId} , if the request should be cached under NewId

false , if we don't want to check the cache

Annotations

Available since version 1.3

Allows separation of the target function from different types of functions, non-domain specific wrappers.

e.g.: before making a post to a blog you should be logged in and your message should be checked for bad words maybe; after posting the message the cache should be invalidated and your post-count could be modified.

Usual dataflow mechanisms can be used but it could make the code harder to read and repetitive.

Annotations Controller Syntax

% keeps the stored macros-include_lib(blog/include/utils_annotations.hrl). % before posting?AUTHENTICATE([administrator]).?CHECK(blog_post). % after posting?INVALIDATE(posts).?UPDATE(user).post(_Args) -> ...

Annotations Annotation Module Syntax

?BEFORE. %% ?AFTER.annotation_name(AnnotationArg, TargetModule, TargetFunction, TargetFunctionArgs | TargetFunctionResult) -> ResultResult :: {proceed, NewFunctionArgs | NewResult} | {skip, NewResult} | {error, {ErrorMod, ErrorFun, ErrorArgs}}

Annotations Annotation Module Example

?AFTER.check (blog_post, _Mod, _Fun, _Args) case is_bad(wpart:fget(post:msg)) of true-> {skip, {redirect, http://correctiveschool.org}}; _-> {proceed, _Args} end.

e_components

e_components is a mechanism for extending the capabilities of the framework

Erlang-Web comes with e_components for authentication, mnesia backup and for generating rss feeds

To search for an e_component we can run ./bin/e_componentsearch component_name, command that will list all available components matching the name and their description

To install an e_component we run ./bin/e_component install component_name, the e_component is now copied in the lib folder of our application. ./bin/compile is now required, in order to compile the component's source files.

e_components

One more thing is required in order to use the component in our project: inserting a new tuple in the configuration file:{ecomponents, [{e_auth, []}, {e_auth_dets, []} ]}.

After restarting the server we can verify that the components are running, by executing the function that lists all running applications : application:which_applications()

e_components

e_components is a mechanism for extending the capabilities of the framework

Erlang-Web comes with e_components for authentication, mnesia backup and for generating rss feeds

To search for an e_component we can run ./bin/e_componentsearch component_name, command that will list all available components matching the name and their description

To install an e_component we run ./bin/e_component install component_name, the e_component is now copied in the lib folder of our application. ./bin/compile is now required, in order to compile the component's source files.

Click to edit the outline text formatSecond Outline LevelThird Outline LevelFourth Outline LevelFifth Outline LevelSixth Outline LevelSeventh Outline LevelEighth Outline LevelNinth Outline Level