View Source nova_basic_handler (nova v0.9.22)
Summary
Functions
Handler for JSON. It takes two different return objects
Handler for regular views. This will render a template with given variables. If not another view is specified in options a view that corresponds to the controller will be rendered. The first element of the returned tuple could be either ok or view - they are identical in their functionality.
Handler for returning http status codes. There's three different ways one can return status code. The most basic case is {status, Status} where Status is the code that should be returned.
Handles basic websocket operations. This is a special handler in regards to arguments. Handlers for websocket only takes two arguments; What the controller returned and the state. And the handler should return what cowboy expects.
Types
-type erlydtl_vars() :: map() | [{Key :: atom() | binary() | string(), Value :: any()}].
-type mod_fun() :: {Module :: atom(), Function :: atom()} | undefined.
Functions
-spec handle_json({json, JSON :: map()} | {json, StatusCode :: integer(), Headers :: map(), JSON :: map()}, ModFun :: mod_fun(), Req :: cowboy_req:req()) -> {ok, State :: cowboy_req:req()} | {Module :: atom(), Req :: cowboy_req:req()}.
Handler for JSON. It takes two different return objects:
{json, JSON :: map()} returns the JSON encoded to the user. If the operation was a POST the HTTP-status code will be 201, otherwise 200.
{json, StatusCode :: integer(), Headers :: map(), JSON :: map()} Same operation as the above except you can set custom status code and custom headers.-spec handle_ok({ok, Variables :: erlydtl_vars()} | {ok, Variables :: erlydtl_vars(), Options :: map()}, ModFun :: mod_fun(), Req :: cowboy_req:req()) -> {ok, cowboy_req:req()}.
Handler for regular views. This will render a template with given variables. If not another view is specified in options a view that corresponds to the controller will be rendered. The first element of the returned tuple could be either ok or view - they are identical in their functionality.
-module(my_first_controller). -compile(export_all).
my_function(_Req) -> {ok, []}.
The example above will then render the view named 'app_main.dtl'
Options can be specified as follows:
- view - Specifies if another view should be rendered instead of default one
- headers - Custom headers-spec handle_redirect({redirect, Route :: list() | binary()}, ModFun :: mod_fun(), Req :: cowboy_req:req()) -> {ok, Req :: cowboy_req:req()}.
-spec handle_sendfile({sendfile, StatusCode :: integer(), Headers :: map(), {Offset :: integer(), Length :: integer(), Path :: list()}, Mime :: binary()}, ModFun :: mod_fun(), Req) -> {ok, Req} when Req :: cowboy_req:req().
-spec handle_status({status, StatusCode :: integer()} | {status, StatusCode :: integer(), ExtraHeaders :: map()} | {status, StatusCode :: integer(), ExtraHeaders :: map(), Body :: binary() | map()}, ModFun :: mod_fun(), Req :: cowboy_req:req()) -> {ok, Req :: cowboy_req:req()}.
Handler for returning http status codes. There's three different ways one can return status code. The most basic case is {status, Status} where Status is the code that should be returned.
If there's a need for additional headers to be sent along with the http code one can specify a third argument that is a map with header-fields.
One can also send in a body as a fourth argument in the tuple. It can either be a binary or a map. If it's a map it will be considered a JSON-structure and encoded.-spec handle_websocket({websocket, ControllerData :: any()}, ModFun :: mod_fun(), Req :: cowboy_req:req()) -> {ok, Req :: cowboy_req:req()}.
Handles basic websocket operations. This is a special handler in regards to arguments. Handlers for websocket only takes two arguments; What the controller returned and the state. And the handler should return what cowboy expects.
Example of a valid return value is {reply, Frame, State}