{"project":"54348ec95b10711400c6c445","_id":"5583393181672a3900bb510c","user":{"_id":"5435b410495d5d0800f3a603","username":"","name":"Lance Halvorsen"},"initVersion":{"_id":"5558c642eb56ae2f00f714fc","version":"0.13.1"},"tags":[],"__v":0,"createdAt":"2015-06-18T21:33:37.558Z","changelog":[],"body":"## Asset Digests (optional)\n\nA new `phoenix.digest` task is now included which digests and compress static files and can be used during deploy. It also integrates with the `static_path` helper to render the proper asset paths from the manifest.\n\nA new configuration called `cache_static_manifest` was added which should be set to \"priv/static/manifest.json\" in production which will preload the manifest file generated by the mix task in order to point to the digested files when generating static paths, ie:\n    \n    # config/prod.exs\n    config :my_app, MyApp.Endpoint,\n      ...\n      cache_static_manifest: \"priv/static/manifest.json\"\n\n\nUsage:\n\n      mix phoenix.digest\n      mix phoenix.digest priv/static -o /www/public\n\nThe first argument is the path where the static files are located. The\n`-o` option indicates the path that will be used to save the digested and\ncompressed files.\n\nIf no path is given, it will use `priv/static` as the input and output path.\n\nThe output folder will contain:\n\n  * the original file\n  * a compressed file with gzip\n  * a file containing the original file name and its digest\n  * a compressed file containing the file name and its digest\n  * a manifest file\n\nExample of generated files:\n\n  * application.js.erb\n  * application.js.erb.gz\n  * application.js-eb0a5b9302e8d32828d8a73f137cc8f0.erb\n  * application.js-eb0a5b9302e8d32828d8a73f137cc8f0.erb.gz\n  * manifest.json\n\n\n## Live-reload\nLive reload has been updated to reload css changes without refreshing the browser. We also fixed a few bugs for windows users. Simply run `mix deps.update phoenix_live_reload` or bump the version in your `mix.exs`:\n\n```elixir\n...\n{:phoenix_live_reload, \"~> 0.3.2\"},\n```\n\n## Test Helpers\nPhoenix includes new test helpers for easily testing your endpoints, routers, controllers.\nSee the [test docs](https://github.com/phoenixframework/phoenix/blob/fd14385e4138ebd0b0fb6994681bdb86ffc74f9a/lib/phoenix/conn_test.ex) for example usage.\n\nCode that used to require multiple assertions and manually wiring up the `%Conn{}` structs can now simply call into the endpoint stack. Phoenix generates tests files for these features for new projects. Existing projects can get up to speed by the following steps:\n\n1) `$ mkdir test/support`\n\n2) Save the following listing as `test/support/conn_case.ex` and replace `MyApp` with your app module. *Note*: the Ecto bits of this step can be excluded if not using Ecto.\n\n```elixir\ndefmodule MyApp.ConnCase do\n  @moduledoc \"\"\"\n  This module defines the test case to be used by\n  tests that require setting up a connection.\n\n  Such tests rely on `Phoenix.ConnTest` and also\n  imports other functionality to make it easier\n  to build and query models.\n\n  Finally, if the test case interacts with the database,\n  it cannot be async. For this reason, every test runs\n  inside a transaction which is reset at the beginning\n  of the test unless the test case is marked as async.\n  \"\"\"\n\n  use ExUnit.CaseTemplate\n\n  using do\n    quote do\n      # Import conveniences for testing with connections\n      use Phoenix.ConnTest\n\n      # Alias the data repository and import query/model functions\n      alias MyApp.Repo\n      import Ecto.Model\n      import Ecto.Query, only: [from: 2]\n\n      # Import URL helpers from the router\n      import MyApp.Router.Helpers\n\n      # The default endpoint for testing\n      @endpoint MyApp.Endpoint\n    end\n  end\n\n  setup tags do\n    unless tags[:async] do\n      Ecto.Adapters.SQL.restart_test_transaction(MyApp.Repo, [])\n    end\n\n    :ok\n  end\nend\n```\n\n3) Save the following listing as `test/support/model_case.ex` and replace `MyApp` with your app module. *Note*: this step can be skipped/modified if not using Ecto.\n\n```elixir\ndefmodule MyApp.ModelCase do\n  @moduledoc \"\"\"\n  This module defines the test case to be used by\n  model tests.\n\n  Finally, if the test case interacts with the database,\n  it cannot be async. For this reason, every test runs\n  inside a transaction which is reset at the beginning\n  of the test unless the test case is marked as async.\n  \"\"\"\n\n  use ExUnit.CaseTemplate\n\n  using do\n    quote do\n      # Alias the data repository and import query/model functions\n      alias MyApp.Repo\n      import Ecto.Model\n      import Ecto.Query, only: [from: 2]\n    end\n  end\n\n  setup tags do\n    unless tags[:async] do\n      Ecto.Adapters.SQL.restart_test_transaction(MyApp.Repo, [])\n    end\n\n    :ok\n  end\nend\n```\n\n## Channels\n`terminate/2` in your channels is now always called when the channel server shuts down. Leaving the channel or closing the client will now trigger terminate on the channel, regardless of traping exits, with reasons `{:shutdown, :left}` and `{:shutdown, :closed}` respectively.\n\n\n### Views\n\nNew functions `render_many/4` and `render_one/4` have been added to make it easier to render collection and optional data. See the [docs for example usage](https://github.com/phoenixframework/phoenix/blob/fd14385e4138ebd0b0fb6994681bdb86ffc74f9a/lib/phoenix/view.ex#L284-L317)\n\n\n`render_existing/3` has been added to allow dynamic rendering of templates that may or may not exist. From the docs:\n\nConsider the case where the application layout allows views to dynamically\nrender a section of script tags in the head of the document. Some views\nmay wish to inject certain scripts, while others will not.\n\n    <head>\n      <%= render_existing view_module(@conn), \"scripts.html\", assigns %>\n    </head>\n\nThen the module for the `@inner` view can decide to provide scripts with\neither a precompiled template, or by implementing the function directly, ie:\n\n    def render(\"scripts.html\", _assigns) do\n      \"<script src=\\\"...\\\">\"\n    end\n\n\n### Rendering based on controller template\n\nIn some cases, you might need render based on the template from the controller.\nFor these cases, `Phoenix.Controller.controller_template/1` can pair with\n`render_existing/3` for per-template based content, ie:\n\n    <head>\n      <%= render_existing view_module(@conn), \"scripts.\" <> controller_template(conn), assigns %>\n    </head>\n\n    def render(\"scripts.show.html\", _assigns) do\n      \"<script src=\\\"...\\\">\"\n    end\n    def render(\"scripts.index.html\", _assigns) do\n      \"<script src=\\\"...\\\">\"\n    end","slug":"upgrading-from-v0110-to-v0120","title":"Upgrading from v0.11.0 to v0.12.0"}

Upgrading from v0.11.0 to v0.12.0


## Asset Digests (optional) A new `phoenix.digest` task is now included which digests and compress static files and can be used during deploy. It also integrates with the `static_path` helper to render the proper asset paths from the manifest. A new configuration called `cache_static_manifest` was added which should be set to "priv/static/manifest.json" in production which will preload the manifest file generated by the mix task in order to point to the digested files when generating static paths, ie: # config/prod.exs config :my_app, MyApp.Endpoint, ... cache_static_manifest: "priv/static/manifest.json" Usage: mix phoenix.digest mix phoenix.digest priv/static -o /www/public The first argument is the path where the static files are located. The `-o` option indicates the path that will be used to save the digested and compressed files. If no path is given, it will use `priv/static` as the input and output path. The output folder will contain: * the original file * a compressed file with gzip * a file containing the original file name and its digest * a compressed file containing the file name and its digest * a manifest file Example of generated files: * application.js.erb * application.js.erb.gz * application.js-eb0a5b9302e8d32828d8a73f137cc8f0.erb * application.js-eb0a5b9302e8d32828d8a73f137cc8f0.erb.gz * manifest.json ## Live-reload Live reload has been updated to reload css changes without refreshing the browser. We also fixed a few bugs for windows users. Simply run `mix deps.update phoenix_live_reload` or bump the version in your `mix.exs`: ```elixir ... {:phoenix_live_reload, "~> 0.3.2"}, ``` ## Test Helpers Phoenix includes new test helpers for easily testing your endpoints, routers, controllers. See the [test docs](https://github.com/phoenixframework/phoenix/blob/fd14385e4138ebd0b0fb6994681bdb86ffc74f9a/lib/phoenix/conn_test.ex) for example usage. Code that used to require multiple assertions and manually wiring up the `%Conn{}` structs can now simply call into the endpoint stack. Phoenix generates tests files for these features for new projects. Existing projects can get up to speed by the following steps: 1) `$ mkdir test/support` 2) Save the following listing as `test/support/conn_case.ex` and replace `MyApp` with your app module. *Note*: the Ecto bits of this step can be excluded if not using Ecto. ```elixir defmodule MyApp.ConnCase do @moduledoc """ This module defines the test case to be used by tests that require setting up a connection. Such tests rely on `Phoenix.ConnTest` and also imports other functionality to make it easier to build and query models. Finally, if the test case interacts with the database, it cannot be async. For this reason, every test runs inside a transaction which is reset at the beginning of the test unless the test case is marked as async. """ use ExUnit.CaseTemplate using do quote do # Import conveniences for testing with connections use Phoenix.ConnTest # Alias the data repository and import query/model functions alias MyApp.Repo import Ecto.Model import Ecto.Query, only: [from: 2] # Import URL helpers from the router import MyApp.Router.Helpers # The default endpoint for testing @endpoint MyApp.Endpoint end end setup tags do unless tags[:async] do Ecto.Adapters.SQL.restart_test_transaction(MyApp.Repo, []) end :ok end end ``` 3) Save the following listing as `test/support/model_case.ex` and replace `MyApp` with your app module. *Note*: this step can be skipped/modified if not using Ecto. ```elixir defmodule MyApp.ModelCase do @moduledoc """ This module defines the test case to be used by model tests. Finally, if the test case interacts with the database, it cannot be async. For this reason, every test runs inside a transaction which is reset at the beginning of the test unless the test case is marked as async. """ use ExUnit.CaseTemplate using do quote do # Alias the data repository and import query/model functions alias MyApp.Repo import Ecto.Model import Ecto.Query, only: [from: 2] end end setup tags do unless tags[:async] do Ecto.Adapters.SQL.restart_test_transaction(MyApp.Repo, []) end :ok end end ``` ## Channels `terminate/2` in your channels is now always called when the channel server shuts down. Leaving the channel or closing the client will now trigger terminate on the channel, regardless of traping exits, with reasons `{:shutdown, :left}` and `{:shutdown, :closed}` respectively. ### Views New functions `render_many/4` and `render_one/4` have been added to make it easier to render collection and optional data. See the [docs for example usage](https://github.com/phoenixframework/phoenix/blob/fd14385e4138ebd0b0fb6994681bdb86ffc74f9a/lib/phoenix/view.ex#L284-L317) `render_existing/3` has been added to allow dynamic rendering of templates that may or may not exist. From the docs: Consider the case where the application layout allows views to dynamically render a section of script tags in the head of the document. Some views may wish to inject certain scripts, while others will not. <head> <%= render_existing view_module(@conn), "scripts.html", assigns %> </head> Then the module for the `@inner` view can decide to provide scripts with either a precompiled template, or by implementing the function directly, ie: def render("scripts.html", _assigns) do "<script src=\"...\">" end ### Rendering based on controller template In some cases, you might need render based on the template from the controller. For these cases, `Phoenix.Controller.controller_template/1` can pair with `render_existing/3` for per-template based content, ie: <head> <%= render_existing view_module(@conn), "scripts." <> controller_template(conn), assigns %> </head> def render("scripts.show.html", _assigns) do "<script src=\"...\">" end def render("scripts.index.html", _assigns) do "<script src=\"...\">" end