Where the default layout of views "app.html.eex" is defined?

Phoenix Forum Questions / Help
, ,
1

Hello everybody,
I’m trying to figure out where the default “app.html.eex” file is defined in all the pipeline.
The better I managed to find is the following explanation on the Phoenix Controller part of the documentation:

defmodule MyAppWeb.UserController do
 use Phoenix.Controller
 def show(conn, _params) do
   render(conn, "show.html", message: "Hello")
 end
end

will render the “show.html” template inside an “app.html” template specified in MyAppWeb.LayoutView .

However I wasn’t able to find the exact part in the source code where this is happening.
I tried by renaming the file (for example ap.html.eex which it gives me an error) to follow the stack trace to find where the default layout is applied.

I also tried to figure out where the app.html.eex template is injected by putting many IO.inpsect(template) all over the source code of Phoenix around the renders functions where things seem to happen… But without success…

I also read in Chris’ book (Programming Phoenix) the following (on page 57):

When you call render in your controller, you’re actu-
ally rendering with the :layout option set by default. This allows you to render
the view and template for your controller action in the layout with a plain
render function call. No magic is happening here.

To be honest it is like magic for me…

Any details will be appreciated!
Thank you…

2

I found this in deps/phoenix/lib/phoenix/controller.ex __using__ macro definition:

      plug :put_new_layout, {Phoenix.Controller.__layout__(__MODULE__, opts), :app}
      plug :put_new_view, Phoenix.Controller.__view__(__MODULE__)

And in the same file (there is LayoutView at the last line ):

 @doc false
  def __layout__(controller_module, opts) do
    namespace =
      if given = Keyword.get(opts, :namespace) do
        given
      else
        controller_module
        |> Atom.to_string()
        |> String.split(".")
        |> Enum.drop(-1)
        |> Enum.take(2)
        |> Module.concat()
      end
    Module.concat(namespace, "LayoutView")
  end
8 Likes
3

Thanks I didn’t think to look at __using__ and also didn’t think to look for the atom :app…

Btw, does anyone know the reason behind the double underscore formatting for __layout__ and __view__?
I got that for __MODULE__it’s a language construct for identifying the current module, but what about using this format for defined functions?

1 Like
4

This is in Elixir naming convention:

Underscore ( _foo )

(…)

Function names may also start with an underscore. Such functions are never imported by default:

iex> defmodule Example do
...>   def _wont_be_imported do
...>     :oops
...>   end
...> end

iex> import Example
iex> _wont_be_imported()
** (CompileError) iex:1: undefined function _wont_be_imported/0

Due to this property, Elixir relies on functions starting with underscore to attach compile-time metadata to modules. Such functions are most often in the __foo__ format. For example, every module in Elixir has an __info__/1 function:

iex> String.__info__(:functions)
[at: 2, capitalize: 1, chunk: 2, ...]

Elixir also includes five special forms that follow the double underscore format: __CALLER__/0 , __DIR__/0 , __ENV__/0 and __MODULE__/0 retrieve compile-time information about the current environment, while __STACKTRACE__/0 retrieves the stacktrace for the current exception.

3 Likes