Phoenixに関する資料は限られているので断片的なものを収集している．
人に見せるものではない．メインに参考にしている資料は下のリンク
http://www.phoenixframework.org/
phoenixをインストールした後にmy_appというプロジェクトを~/Projects/に作る
$ mix local.hex
$ mix archive.install https://github.com/phoenixframework/phoenix/releases/download/v0.13.1/phoenix_new-0.13.1.ez
$ mix phoenix.new ~/Projects/my_app --no-brunch
$ cd ~/Projects/my_app
$ iex -S mix phoenix.server
Running Elixir.HelloPhoenix.Router with Cowboy on port 4000
Let's say we have a read-only posts resource. We could define it like this.
resources "posts", PostController, only: [:index, :show]
Running $ mix phoenix.routes shows that we now only have the routes to the index and show actions defined.
post_path GET /posts HelloPhoenix.PostsController.index/2
post_path GET /posts/:id HelloPhoenix.PostsController.show/2
Similarly, if we have a comments resource, and we don't want to provide a route to delete one, we could define a route like this.
resources "comments", CommentController, except: [:delete]
Running $ mix phoenix.routes now shows that we have all the routes except the DELETE request to the delete action.
どのディレクトリからでも $ mix phoenix.new ../projectXが使えるように下のコマンドでphoenix 0.13バージョンをインストール
$ mix archive.install https://github.com/phoenixframework/phoenix/releases/download/v0.13.1/phoenix_new-0.13.1.ez
下のコマンドの結果の中にpage_pathとかpost_pathとかはControllerの名前に基づいて自動的生成されたものです。
Phoenix.Routerページにこれについて書いています。
Phoenix automatically generates a module Helpers inside your router which contains named helpers to help developers generate and keep their routes up to date.
Helpers are automatically generated based on the controller name.
$ mix phoenix.routes
page_path GET / ElixirFriends.PageController.index/2
post_path GET /posts ElixirFriends.PostController.index/2
post_path GET /posts/:id/edit ElixirFriends.PostController.edit/2
post_path GET /posts/new ElixirFriends.PostController.new/2
post_path GET /posts/:id ElixirFriends.PostController.show/2
post_path POST /posts ElixirFriends.PostController.create/2
post_path PATCH /posts/:id ElixirFriends.PostController.update/2
PUT /posts/:id ElixirFriends.PostController.update/2
post_path DELETE /posts/:id ElixirFriends.PostController.delete/2
phoenixのジェネレーターでデータモデルを作ります。
$ mix phoenix.gen.html Post posts image_url:string content:string source_url:string
* creating priv/repo/migrations/20150606011714_create_post.exs
* creating web/models/post.ex
* creating test/models/post_test.exs
* creating web/controllers/post_controller.ex
* creating web/templates/post/edit.html.eex
* creating web/templates/post/form.html.eex
* creating web/templates/post/index.html.eex
* creating web/templates/post/new.html.eex
* creating web/templates/post/show.html.eex
* creating web/views/post_view.ex
* creating test/controllers/post_controller_test.exs
Add the resource to the proper scope in web/router.ex:
resources "/posts", PostController
and then update your repository by running migrations:
$ mix ecto.migrate
priv/repo/migrations/ディレクトリ下にテーブル作成するためのモジュールが作成されます。
web/models/post.exファイルにPostモジュールが生成され、postsスキーマが定義されます。
$ mix ecto.createコマンド実行するとelixir_friends_devデータベースが作成されます。elixir_friends_devはconfig/config.exsに定義されています。
$ mix ecto.migrateコマンドを実行するとpriv/repo/migrations/ディレクトリ下のファイルを利用して、下のようなテーブル（posts)が作成されます。
You are now connected to database "elixir_friends_dev" as user "wang".
elixir_friends_dev=# \d
No relations found.
elixir_friends_dev=# \d
List of relations
Schema | Name | Type | Owner
--------+-------------------+----------+----------
public | posts | table | postgres
public | posts_id_seq | sequence | postgres
public | schema_migrations | table | postgres
(3 rows)
Phoenix views have several important jobs. They render templates.
In order to render any templates for our HelloController, we need a HelloView.
We can define functions in any individual view in web/views. Functions defined in an individual view will only be available to templates which that view renders. For example, functions defined in the PageView will only be available to templates in web/templates/page.
Phoenix generates a main application view at web/view.ex. Functions we define there are visible to every view module and every template in our application.
The Phoenix PubSub layer consists of the Phoenix.PubSub module and a variety of modules for different adapters and their Genservers. These modules contain functions which are the nuts and bolts of organizing Channel communication - subscribing to topics, unsubscribing from topics, and broadcasting messages on a topic.
Channels use them under the hood to do much of their work. As end users, we shouldn't have any need to use them directly in our applications.
Topics are string identifiers - names that the various layers use in order to make sure messages end up in the right place. As we saw above, topics can use wildcards. This allows for a useful "topic:subtopic" convention. Often, you'll compose topics using record IDs from your model layer, such as "users:123".
Every keyword passed to render in the controller is available as an assign within the template, so you can use <%= @message %> in the eex template that is rendered in the controller example.
All controller actions take two arguments. The first is conn, a struct which holds a ton of data about the request. The second is params, which are the request parameters.
defmodule App.PageController do
use Phoenix.Controller
plug :action
def index(conn, _params) do
render conn, "index", message: "hello"
end
end
By default, eex is supported. To add haml support, simply include the following in your mix.exs deps:
{:phoenix_haml, "~> 0.1.0"}
and add the PhoenixHaml.Engine to your config/config.exs
config :phoenix, :template_engines,
haml: PhoenixHaml.Engine
We can implement a channel by creating a module in the channels directory and by using Phoenix.Channel:
defmodule App.MyChannel do
use Phoenix.Channel
end
The first thing to do is to implement the join function to authorize sockets on this Channel's topic:
defmodule App.MyChannel do
use Phoenix.Channel
def join(socket, "topic", message) do
{:ok, socket}
end
def join(socket, _no, _message) do
{:error, socket, :unauthorized}
end
end
join events are specially treated. When {:ok, socket} is returned from the Channel, the socket is subscribed to the channel and authorized to pubsub on the channel/topic pair. When {:error, socket, reason} is returned, the socket is denied pubsub access.
You can use plug in your projects in two steps:
Add plug and your webserver of choice (currently cowboy) to your mix.exs dependencies:
def deps do
[{:cowboy, "~> 1.0.0"},
{:plug, "~> 0.8.0"}]
end
List both :cowboy and :plug as your application dependencies:
def application do
[applications: [:cowboy, :plug]]
end
A plug takes two shapes. It is a function that receives a connection and a set of options as arguments and returns the connection or it is a module that provides an init/1 function to initialize options and implement the call/2 function, receiving the connection and the initialized options, and returning the connection.
As per the specification above, a connection is represented by the Plug.Conn struct:
%Plug.Conn{host: "www.example.com",
path_info: ["bar", "baz"],
...}
Plug.Static - serves static files;
Channels are based on a simple idea - sending and receiving messages. Senders broadcast messages about topics. Receivers subscribe to topics so that they can get those messages. Senders and receivers can switch roles on the same topic at any time.
A channel will use a socket underneath to send responses and receive events. As said, sockets are bidirectional, which mean you can receive events (similar to requests in your controller). You handle events with pattern matching directly on the event name and message map.
Prints all routes for the default or a given router.
$ mix phoenix.routes
Compiled web/views/page_view.ex
Generated chatty.app
page_path GET / Chatty.PageController.index/2
Controllers are used to group common functionality in the same (pluggable) module.
For example, the route:
get "/users/:id", UserController, :show
will invoke the show/2 action in the UserController:
defmodule UserController do
use Phoenix.Controller
plug :action
def show(conn, %{"id" => id}) do
user = Repo.get(User, id)
render conn, "show.html", user: user
end
end
An action is just a regular function that receives the connection and the request parameters as arguments. The connection is a Plug.Conn struct, as specified by the Plug library.
Connection
A controller by default provides many convenience functions for manipulating the connection, rendering templates, and more.
Those functions are imported from two modules:
Plug.Conn - a bunch of low-level functions to work with the connection
Phoenix.Controller - functions provided by Phoenix to support rendering, and other Phoenix specific behaviour
broadcast(socket, event, message) (function)
broadcast(channel, topic, event, message) (function)
Broadcast event, serializable as JSON to topic namedspaced by channel
Examples
iex> Channel.broadcast "rooms", "global", "new:message", %{id: 1, content: "hello"}
:ok
iex> Channel.broadcast socket, "new:message", %{id: 1, content: "hello"}
:ok
plug/2 support guards, allowing a developer to configure a plug to only run in some particular action:
plug :log_message, "before action" when action in [:show, :edit]
plug :action
plug :log_message, "after action" when not action in [:index]
The first plug will run only when action is show and edit, while the second will always run except for the index action.
Those guards work like regular Elixir guards and the only variables accessible in the guard are conn, the action as an atom and the controller as an alias.
Like routers, controllers are plugs, but they are wired to dispatch to a particular function which is called an action.
For example, the route:
get "/users/:id", UserController, :show
will invoke UserController as a plug:
UserController.call(conn, :show)
which will trigger the plug pipeline and which will eventually invoke the inner action plug that dispatches to the show/2 function in the UserController.
As controllers are plugs, they implement both init/1 and call/2, and it also provides a function named action/2 which is responsible for dispatching the appropriate action in the middle of the plug stack (and is also overridable).
web/controllers/page_controller.exにあるmsgは
web/templates/page/index.html.eexの中に呼び出すことができる
def index(conn, _params) do
render conn, "index.html", msg: "user-input-message"
end
end
下のコードみたいなやり方で
<input type="text" id="<%= @msg %>" />
info.html画面一つ追加したいときに，まず web/router.exを開いて，ルートを追加する
そしてweb/controllers/page_controller.exにinfo関数一つ追加
これらにあわせてweb/templates/pageの下に
information.html.eexを追加するといい
Put this line into your router.ex file inside the scope "/" do block: resources "users", Chatty.UserController.
Then go to the root of your project, and run
$ mix phoenix.routes
Generated chatty.app
page_path GET / Chatty.PageController.index/2
hello_path GET /hello Chatty.HelloController.index/2
hello_path GET /hello/:messenger Chatty.HelloController.show/2
user_path GET /users Chatty.UserController.index/2
user_path GET /users/:id/edit Chatty.UserController.edit/2
user_path GET /users/new Chatty.UserController.new/2
user_path GET /users/:id Chatty.UserController.show/2
user_path POST /users Chatty.UserController.create/2
user_path PATCH /users/:id Chatty.UserController.update/2
PUT /users/:id Chatty.UserController.update/2
user_path DELETE /users/:id Chatty.UserController.destroy/2
iex(9)> Chatty.Router.Helpers.user_path(:show, 17, admin: true, active: false)
"/users/17?admin=true&active=false"