Clarity needed on Phoenix 1.3 contexts and schema in controllers

Phoenix Forum Questions / Help
1

The following code present in my controller file generated by phx.gen.html call for clarity on the intended usage of context and schema.

  def index(conn, _params) do
    invoices = Billing.list_invoices()
    render(conn, "index.html", invoices: invoices)
  end

  def new(conn, _params) do
    changeset = Billing.change_invoice(%InvoiceApplication.Billing.Invoice{})
    render(conn, "new.html", changeset: changeset)
  end

Except for the new action, where the schema %InvoiceApplication.Billing.Invoice{} is used, no part of the controller directly calls the schema. If the intention of context module is to provide public apis and hide the implementation details such as the schema name, phx.gen.html should generate a controller without specifying schema names such as Billing.new_invoice/0 or Billing.build_invoice/0.

So the clarity needed is do we expose schema outside the context or not? If we do expose them, then clearly context file is not the only public api of a context.

2 Likes
2

We do expose them outside the context. After all, Billing.list_invoice/0 returns a list of invoice structs!

3 Likes
3

There are a few related concerns with the current change_invoice/2 code used in new action of controller.

  1. change_invoice/2 doesn’t say my intention clearly. I am not changing an existing invoice, rather trying to build a new one. So a function name like build_invoice/1 or new_invoice/1 is more clearly giving the intention. The arity in this new function is attrs of the current change_invoice/2 and defaults to %{}.

  2. You mentioned that Billing.list_invoice/0 returns invoice structs so it’s ok to use invoice struct directly in the new action. However, is it not an unnecessary input to provide? Because, I am in the new action, calling an invoice related function on my billing context and I expect an invoice struct, without having me to say that again? I have already been explicit in conveying my intention. For eg., Billing.get_invoice!(id) doesn’t require me to input %Invoice{}.

Thanks for your time and input.

1 Like
4

Afaik: Contexts are layer of abstractions that helps you group your business logic code. It’s just additional middleware that controller should ask for your data, not directly repo, but still you receive data- structs related to certain schema modules.
Another benefit of using contexts is that they group your schemas visually- this is the point which was mentioned by a Chris- you see which contexts refer to which schemas.
From now on: controller shouldn’t talk with repo, but with contexts.

2 Likes
5

Do you have the code for this app or an example of what commands you ran to generate it? I’m keen to look at it and read through it.

1 Like
6

I just ran the Phoenix 1.3 generator code like this

  mix phx.gen.html Billing Invoice invoices due_date:date ...

These concepts are clear @PatNowak. My question is should we pass the struct explicitly to the context function in new action of the generated controller.

1 Like
7

I wouldn’t. All you need to edit existing one is id, for new struct you only pass params and context should internally call function with empty struct for repo insert.

1 Like
8

That’s exactly what I am proposing here. mix phx.gen.html produces the below code in the new action of controller.

changeset = Billing.change_invoice(%InvoiceApplication.Billing.Invoice{})

I am proposing that it should be

 changeset = Billing.new_invoice  # or build_invoice and optionally pass attrs to it.
4 Likes
9

It’s looks nice. I assume that context is keeps proper level of isolation between controller and repo & schemas. It would be logicall to hide informations about structures inside context function calls:

changeset = Billing.change_invoice(id, params)
# and it would call
Invoice.changeset(invoice_struct, params)
# where invoice_struct is
Repo.get!(Invoice, id)

Keeping this information about Invoice is redundant for controller - I already wants to change invoice, so I only wants to deal with these kind of structures.

3 Likes