hyperbuffs v0.1.0 HyperBuffs.Controller
Link to this section Summary
Functions
Wraps the action/2
method for your controller so that your action methods
can accept and respond on speaking in Proto objects
This function will call the appropriate action in mod
based
on the request configuration in conn.private[:req]
Helper function to render a protobuf, since the proto itself specifies the template in its definition
Link to this section Functions
Wraps the action/2
method for your controller so that your action methods
can accept and respond on speaking in Proto objects.
Once you set private :req and :resp in your routes, HyperBuffs will change
the way we call your controller actions. See call_action/3
below
for details.
call_action(Plug.Conn.t, atom, atom) :: Plug.Conn.t | struct | {Plug.Conn.t, struct}
This function will call the appropriate action in mod
based
on the request configuration in conn.private[:req]
.
For HyperBuffs, instead of taking [conn, params] as input to our actions, we base the action definitions off of our route definitions.
This function is responsible calling the action with the following params:
- If
conn.private[:req]
is nil, callaction(conn, params)
like normal - If
conn.private[:req]
is :none, callaction(conn)
with no params - If
conn.private[:req]
is a struct, callaction(conn, proto)
with proto from params
Note: If params[“_protobuf”] is set from PlugProtobufs, we will use that. Otherwise, we will create a new proto from the params themselves.
Helper function to render a protobuf, since the proto itself specifies the template in its definition.
For a protobuf named “Defs.MyProtobuf”, this is the equivalent
of calling render(conn, Defs.MyProtobuf, MyProtobuf)
.
It’s expected that you then define in your view matching calls,
such as: render("Elixir.Defs.MyProtobuf.proto", proto)
and
render("Elixir.Defs.MyProtobuf.json", proto)
. See HyperBuffs.View
for helpers generating these view functions.