View Source nova_basic_handler (nova v0.11.0)
Summary
Functions
Handler for JSON. It can take one of three 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.
Handles redirects. This will return a 302-status code with a location given by the user. Something like {redirect, "/login"} will send a 302 with location set to "/login"
Handles sendfile.
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
Functions
-spec handle_json({json, JSON :: map()} | {json, StatusCode :: integer(), Headers :: map(), JSON :: map()} | {json, StatusCode :: integer(), Headers :: map(), JSON :: map(), Req0 :: cowboy_req:req()}, Callback :: function(), Req :: cowboy_req:req()) -> {ok, State :: cowboy_req:req()}.
Handler for JSON. It can take one of three 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.
{json, StatusCode :: integer(), Headers :: map(), Req0 :: cowboy_req:req(), JSON :: map()} This is the same as the above but you can also return the request object. This is particularly useful if you want to set cookies or other headers that are not supported by the handler.-spec handle_ok({ok, Variables :: erlydtl_vars()} | {ok, Variables :: erlydtl_vars(), Options :: map()}, Callback :: function(), 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'
The tuple can have three different forms:
{ok, Variables} - This will render the default view with the given variables
{ok, Variables, Options} - This will render the default view with the given variables and options Options can be specified as follows:
- view - Specifies if another view should be rendered instead of default one
- headers - Custom headers
{ok, Variables, Options, Req0} - This will render the default view with the given variables and options but also takes a request object. This is useful if you want to set cookies or other headers that are not supported by the handler.-spec handle_redirect({redirect, Route :: list() | binary()}, Callback :: function(), Req :: cowboy_req:req()) -> {ok, Req :: cowboy_req:req()}.
Handles redirects. This will return a 302-status code with a location given by the user. Something like {redirect, "/login"} will send a 302 with location set to "/login"
Optionally you can attach the request object as the third argument. This is useful if you want to set cookies or other headers that are not supported by the handler.-spec handle_sendfile({sendfile, StatusCode :: integer(), Headers :: map(), {Offset :: integer(), Length :: integer(), Path :: list()}, Mime :: binary()}, Callback :: function(), Req) -> {ok, Req} when Req :: cowboy_req:req().
Handles sendfile.
The tuple have the following structure: {sendfile, StatusCode, Headers, {Offset, Length, Path}, Mime}
- sendfile is the atom that tells the handler to send a file.
- StatusCode is the HTTP status code that should be returned.
- Headers is a map with headers that should be sent along with the file.
- Offset is the offset in the file where the sending should start.
- Length is the length of the file that should be sent.
- Path is the path to the file that should be sent.
- Mime is the mime-type of the file.
Optionally a sixth element can be added to the tuple. This is the request object. This is useful if you want to set cookies or other headers that are not supported by the handler.-spec handle_status({status, StatusCode :: integer()} | {status, StatusCode :: integer(), ExtraHeaders :: map()} | {status, StatusCode :: integer(), ExtraHeaders :: map(), Body :: binary() | map()}, Callback :: function(), 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.
And if you want to modulate the request object you can send it in as the fifth argument.-spec handle_websocket({websocket, ControllerData :: any()}, Callback :: function(), 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}