Skip to content

Instantly share code, notes, and snippets.

@cromwellryan
Last active August 29, 2015 13:58
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save cromwellryan/10013564 to your computer and use it in GitHub Desktop.
Save cromwellryan/10013564 to your computer and use it in GitHub Desktop.
Proposal for Phoenix render pipeline

This is a working proposal for a view rendering pipeline and registration point for view engines in the [phoeonix web framework][phoenix].

Goals

Implicit View Rendering

defmodule Controllers.Pages do
  use Phoenix.Controller

  def show(conn) do
  end # renders "show" view
end

Decouple view format from controllers

...
  def show(conn) do
    render "some_view" # uses view resultion to discover appropriate view and renderer
  end
...

Rendering Engine as an OTP tree

Each rendering engine should exist as a unique OTP tree making it resilient and distributable by default. [phoenix]: https://github.com/phoenixframework/phoenix

Registration might look something like:

send :view_registrar, %{ '.haml', :calliope_view_engine, ... }

.haml represents the view extension that would also be dispatched to the view locator for inclusion in view resolution.
:calliope_view_engine represents the globally registered name of the genserver which provides .haml rendering.

Internal view rendering might look like:

{ view_engine_atom, binary_content } = ViewLocator.resolve view_name
:gen_server.call {:global, view_engine_atom}, { binary_content, conn }

ViewLocator (a GenServer in it's own right) would provide binary_content so that the often finicky IO patterns can be constrained to Phoenix. I suspect raw, precompiled views will also be cached in some way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment