Is this nesting going to be a recommended practice Elixir-wide (so
lib/ecto/ecto.ex instead of the current
lib/ecto.ex) or is this a Phoenix-only thing?
Is this nesting going to be a recommended practice Elixir-wide (so
Hooray! I’m a huge fan of the
web consolidation and how it lets standard approaches to breaking up an app into an umbrella app work smoothly!
I am just not sure how controllers should be scoped now (and views as well). By default generators output looks like controllers/order_controller.ex. But for example if you have 2 contexts - Sales and Support - should I create 2 scopes like controllers/sales/order_controller and controllers/support/order_controller, right?
Or what is logical structure for new design?
Anyway this question is not about
--no-schema flag. It is more about scoping. Now I have about 50 schemas connected to database and about 20 embedded schemas for forms. And how I working on it:
- create schema
- generate controller for web ui in main scope:
- generate controller for admin ui:
- generate controller for API:
So I have this separation but
models/* looks messy now. And idea of per-context separations looks great for me. I am come from Django where re-usable apps is used and each have it’s own schemas, controllers (views in terms of django), templates, related code, etc.
But I am not sure how to split this code now. If I will have
Admin context with all this models - I will end with same schemas mess. Should I have nested contexts like
This looks great. I would say the only change you need is that instead of creating a schema, you will now create a context. It is likely that you want all of those controllers to consume from the same context and it is OK to add functions to the context that is needed for just one of those controllers.
The context is module and functions that are meant to satisfy the needs of your “web” context and other contexts. That’s it. There is no guideline that you need a context per controller, a context per namespace and what not. That’s exactly what we want to avoid.
Elixir does not care at all about how and where you place your files. And afaik Phoenix is only doing inside contexts to keep related files close together. Do what feels natural.
This is true from implementation perspective, but if you change the standard in Phoenix, people will start adopting it everywhere. This is how it usually works. So the right question to ask is why is that change introduced and is the idea transferable to whole ecosystem? I believe you guys have some pretty good reasons to do it this way, but since it’s new, it would be useful to talk about those reasons.
You’re doing amazing work with the framework and I believe Phoenix is kind of driving the whole ecosystem(along with other important projects, like Nerves). That means Phoenix is a poster boy of Elixir and Phoenix conventions will spread, even if you do not intend it too.
It is not new. Phoenix projects already do not follow the path conventions on entries such as
web/controllers/user_controller.ex (which would have required its module to be named
Mix itself keeps
lib/mix/tasks/escript.build.ex instead of
lib/mix/tasks/escript/build.ex. We do it so you can quickly glance into
lib/mix/tasks and see all available tasks.
Not caring about the directory structure has been an Elixir feature from before 1.0. Different projects have leveraged it to provide better code organization under circumstances they find it worth.
In this case, we find that colocating the context file with other files that belong to the same context is going to help exploration. Contrast how it works now:
+ accounts - accounts.ex - foo.ex - bar.ex + backoffice + blog + payments + sales + web
with the old way
+ accounts - foo.ex - bar.ex + backoffice + blog + payments + sales + web - accounts.ex ... - sales.ex
We find the first easier to explore if the files are all in one place. Chris even had to “cheat” in his presentation by making those files visually together while most tree viewers wouldn’t put them side by side. And yes, the idea is transferable to the whole ecosystem.
Therefore it is totally fine if you follow Phoenix conventions elsewhere, especially if you believe they lead to a better code structure. And if you want to try other approaches than the ones mentioned above, then discuss it with your team and go ahead with your changes if you are in agreement.
Thank you for that extensive explanation!
The remarks about better discovery ring true, especially as the number of contexts will probably rise quite a bit during application lifecycle. It looks like a good idea when you put it like this.
Will lib/myapp/.* be hot reloaded?
Just tried out the generators with a small project. One thing that I was confused by, was prefixing the table names with the bounded context name. I have the following migration which was created by:
mix phx.gen.html Builder Repository repositories url:string ssg:string
defmodule Staticrail.Repo.Migrations.CreateStaticrail.Builder.Repository do use Ecto.Migration def change do create table(:builder_repositories) do add :url, :string add :ssg, :string timestamps() end end end
I wasn’t expecting the table names to be prefixed as these are the concrete version of the entities. We could have different views of these entities through different bounded contexts. I am not completely sure if it is a bug or if the table was intentionally named this way. The fix for this for me was simple, I just removed the
:builder prefix in the migration. Not sure how others think about this.
Is there a way to use
phx.gen.html in umbrella projects?
(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)
It is intentionally named this way, as mentioned in
mix help phx.gen.html, to drive the point home they belong to a particular context. You can customize it from the generators with the
--table switch as well.
You need to run it from the
_web app in your umbrella. However it will put the context in the wrong place, there is an open issue to fix that.
I like the old way much more but I think I will put all new files inside
Services directory and keep old style or rename accounts.ex to service.ex, from my point of view accounts/accounts.ex should stay outside the accounts folder, you can consider folders as namespaces.
lib/my_app ├── accounts │ ├── user.ex │ └── accounts.ex ├── sales
alexandrubagu@local:~/devel$ mix phx.new micro --umbrella --database mysql alexandrubagu@local:~/devel/micro_umbrella/apps$ cd micr_umbrella/apps/micro_web/ alexandrubagu@local:~/devel/micro_umbrella/apps/micro_web$ mix phx.gen.html Accounts User users name:string
Yeah I did that, but as the contexts don’t go into the “non
_web application”, I thought there might be another way.
There’s now an issue: https://github.com/phoenixframework/phoenix/issues/2139
It looks like generating a schema with a reference should be fixed in master but I’m still getting an error. Am I being derpy?
$ mix phx.gen.schema Blog.Post blog_posts title user_id:references:blog_users * creating lib/hello_world/blog/post.ex * creating priv/repo/migrations/20170303160218_create_blog_post.exs Remember to update your repository by running migrations: $ mix ecto.migrate $ mix ecto.migrate Compiling 1 file (.ex) Generated hello_world app 08:02:23.215 [info] == Running HelloWorld.Repo.Migrations.CreateHelloWorld.Blog.Post.change/0 forward 08:02:23.215 [info] create table blog_posts 08:02:23.221 [info] create index blog_posts_user_index ** (Postgrex.Error) ERROR 42703 (undefined_column): column "user" does not exist (ecto) lib/ecto/adapters/sql.ex:195: Ecto.Adapters.SQL.query!/5 (ecto) lib/ecto/adapters/postgres.ex:86: anonymous fn/4 in Ecto.Adapters.Postgres.execute_ddl/3 (elixir) lib/enum.ex:1755: Enum."-reduce/3-lists^foldl/2-0-"/3 (ecto) lib/ecto/adapters/postgres.ex:86: Ecto.Adapters.Postgres.execute_ddl/3 (ecto) lib/ecto/migration/runner.ex:98: anonymous fn/2 in Ecto.Migration.Runner.flush/0 (elixir) lib/enum.ex:1755: Enum."-reduce/3-lists^foldl/2-0-"/3 (ecto) lib/ecto/migration/runner.ex:96: Ecto.Migration.Runner.flush/0 (stdlib) timer.erl:181: :timer.tc/2 (ecto) lib/ecto/migration/runner.ex:27: Ecto.Migration.Runner.run/6 (ecto) lib/ecto/migrator.ex:121: Ecto.Migrator.attempt/6 (ecto) lib/ecto/migrator.ex:71: anonymous fn/4 in Ecto.Migrator.do_up/4 (ecto) lib/ecto/adapters/sql.ex:615: anonymous fn/3 in Ecto.Adapters.SQL.do_transaction/3 (db_connection) lib/db_connection.ex:1274: DBConnection.transaction_run/4 (db_connection) lib/db_connection.ex:1198: DBConnection.run_begin/3 (db_connection) lib/db_connection.ex:789: DBConnection.transaction/3 (ecto) lib/ecto/migrator.ex:244: anonymous fn/4 in Ecto.Migrator.migrate/4 (elixir) lib/enum.ex:1229: Enum."-map/2-lists^map/1-0-"/2 (ecto) lib/mix/tasks/ecto.migrate.ex:84: anonymous fn/4 in Mix.Tasks.Ecto.Migrate.run/2 (elixir) lib/enum.ex:645: Enum."-each/2-lists^foreach/1-0-"/2 (elixir) lib/enum.ex:645: Enum.each/2 $
You were not. It should be fixed in master now.
Just wait until the final release