#action is the basic record for all actions. It means that each action has #action as its ancestor.

#action { ancestor, target, module, actions, source=[] }.

target specifies an element where this action will arise.

JavaScript DSL #jq

JavaScript query selector action mimics JavaScript calls and assignments. Specific action may be performed depending on fillingproperty or method fields.

-record(jq, {?ACTION_BASE(action_jq), property, method, args=[], right }).

Here is an example of method calls:


unfolded to calls:

document.querySelector('#n2ostatus').show(); document.querySelector('#n2ostatus').select();

And here is example of property chained assignments:

wf:wire(#jq{target=history,property=scrollTop, right=#jq{target=history,property=scrollHeight}}).

which transforms to:

document.querySelector('#history').scrollTop = document.querySelector('#history').scrollHeight;

Part of N2O API is implemented using #jq actions (updates and redirect). This action is introduced as transitional in order to move from Nitrogen DSL to using pure JavaScript transformations.

Event Actions

Objects passed over WebSockets channel from server to client are called actions. Objects passed over the same channel from client to server are called events. However events themselves are bound to HTML elements with addEventListener and in order to perform these bindings, actions should be sent first. Such actions are called event actions. There are three types of event actions.

Page Events #event

Page events are regular events routed to the calling module. Postback field is used as the main routing argument for event module function. By providing source elements list you specify HTML controls values sent to the server and accessed with wf:q accessor from the page context. Page events are normally generated by active elements like #button, #link, #textbox, #dropdown, #select, #radio and others elements contain postback field.

Control events are used to solve the need of element writers. When you develop your own control elements, you usually want events to be routed not to page but to element module. Control events were introduced for this purpose.

API Events #api

When you need to call Erlang function from JavaScript directly you should use API events. API events are routed to page module with api_event/3 function. API events were used in AVZ authorization library. Here is an example of how JSON login could be implemented using api_event:

api_event(appLogin, Args, Term) -> Struct = n2o_json:decode(Args), wf:info(?MODULE, "Granted Access"), wf:redirect("/account").

And from JavaScript you call it like this:


All API events are bound to root of the HTML document.

Message Box #alert

Message box alert is a very simple dialog that could be used for client debugging. You can use console.log along with alerts.

event({debug,Var}) -> wf:wire(#alert{text="Debug: " ++ wf:to_list(Var)}),

Confirmation Box #confirm

You can use confirmation boxes for simple approval with JavaScript confirm dialogs. You should extend this action in order to build custom dialogs. Confirmation box is just an example of how to organize this type of logic.

event(confirm) -> wf:wire(#confirm{text="Are you happy?",postback=continue}), event(continue) -> wf:info(?MODULE, "Yes, you're right!", []);


Events | Privacy Policy | Feedback | Brandbook
Copyright © 2005–2018 Synrc Research Center s.r.o.