7rans
I find myself increasingly confused by the conventional Phoenix project organization.
The documentation on views states:
Phoenix assumes a strong naming convention from controllers to views to the templates they render.
PageControllerrequires aPageViewto render templates in thelib/hello_web/templates/page/directory.
So what exactly is a “Page”? Am I expected to have ALL my routes go through “PageController” regardless of my application’s different “modules/contexts/concerns/domains”. And I am to have only the one View module for all my templates?
Certainly that’s not suitable for anything but the smallest of projects. So then, how am I to split things up for a large project? That is to say what am I replacing “Page” with?
When analyzing this problem with my application it seems to me there are three cross-cutting concerns: Context, Format, and Function. Context is the abstract “modular” divisions of my applications, e.g. admin, sales, inventory, accounts, etc. Format is just the type of file/data being generated and delivered, such as HTML for web pages, Latex or Postscript (converted to PDFs) for reports, and JSON APIs. Function are more or less REST endpoints, like show, list, or edit.
I find that when generating a template my view often has to accommodate all thee of these is some fashion. But I feel like I only have one variable to differentiate on, namely “Page”. So what should “Page” be? … By Context (e.g. “SalesView”), by Format (e.g, “LatexView”) or by Function (e.g. “ListView”)? And how to best accommodate the two concerns not subdivided, to keep the code clean and manageable?
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #security
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
benwilson512
I think this is a relatively simple confusion. To answer your question: no, not at all.
PageControlleris a simple boilerplate controller that exists to show a “static” page when you first boot your app. Sometimes people keep it around to show an/aboutpage on their site, or/privacy, or similar other non domain oriented pages.Actual routes / views / etc related to your domain would be broken up in the normal way. If you have
/productsyou’ll have aProductControllerand so forth.w0rd-driven
I can understand this by going through the docs alone. For me the best way to really understand these concepts is to use the generators to create live (
mix phx.gen.live) or normal views (mix phx.gen.html). I’m sure you could step outside of what gets created but the generators provide some useful boilerplate and guard rails.7rans
Thanks @benwilson512. That’s what I assumed, but I ran into a wall with this “strong connection” between Controller ↔ View. And it totally through me off. Controllers tie closely to the router, so divvying up controllers to different files is a pretty abstract choice – no real issues (other than a large file) even if it’s all one module.
But Views… they are more concrete in that they tie very strongly to templates, and different templates have different needs – function names might clash, and, in general, why make a function available to a template that it doesn’t belong in? So I started second guessing if I actually understood Phoenix’s organizational design.
It seems crazy to me to create a controller for every view. (Why even have separate modules for them if that’s the case?). So my plan now is to use
put_view()rather liberally, to compensate.benwilson512
Just so we are clear on what Phoenix’s traditional structure is: You have a controller, and it is associated with a view by default. That view then is used as the foundation for all of the templates related to the controller, but only that controller. So concretely if you had a ProductController you’d have a ProductView, and then
index.html,show.html,edit.htmlandnew.htmltemplates. The reason that you have a single view for those templates is that there is usually a lot of shared functions given that the same%Product{}entity is used throughout.christhekeele
Right! These docs do read a little confusingly, but are correct. Parse it as:
PageControllerconventionally requires…But not, Phoenix requires you route everything through only the
PageController.christhekeele
Honestly, that “for example” might be a welcome OSS contribution to the docs, if you’re so inclined!