Why some Phoenix modules (ex. Controllers) doesn't reflect its file path


I was wondering, why Phoenix doesn’t follow the “unwritten rule” that your module path should be identical to the file path in the system (ex: MyApp.Bla.Ble would be in lib/my_app/bla/ble.ex) for some of its framework files?

That may sound dumb, but one of the things that I like most about Elixir is the well-defined patterns that everyone uses, variables, atoms and files should use underscore, modules should be camel case, etc. This, IMO, makes the code well organized, easy to read, and easy to find. And in my experience, most of the Elixir libraries follow these patterns (except Google ones, ofc).

At the same time, you have some parts of the Phoenix Framework which seem to ignore this. For example, instead of having MyAppWeb.Controllers.Page which would be stored in lib/my_app_web/controllers/page.ex, we have MyAppWeb.PageController which is stored in lib/my_app_web/controllers/page_controller.ex. The same thing happens with views, components, etc.

I know I’m exaggerating, but this for some reason makes me remember java class names like AbstractSingletonProxyFactoryBean :sweat_smile:

I’m not saying that this is wrong or anything, it mostly depends on the user’s opinion in the end… But at the same time, having the module reflect the file path makes things easy to find and makes, IMO, the language not dependent on IDEs, so this made me wonder why Phoenix does this, I’m pretty sure there is a good reason.

Essentially all parts of my_app_web ignore this.

The reason being is to prevent you having three (or more) page.ex files/….Page modules in your codebase (schema/controller/view/…) which makes it hard to search by filename or module. Given this overlap of names is common place and not a rare occurance it makes sense to break with a convention, given it’s only a convention and not enforced by anything.

1 Like

Thanks for the explanation @LostKobrakai , that makes sense even though I still prefer having multiple page.ex files tbh.

Probably because I never search for a file in the project but go manually to the file directory, so I never had this problem.

But I guess most people would search for the file, so the current approach would work better for them.