Phoenix 1.7 improved the generators a lot, so it’s easier to adapt them to custom markup. But at some point I think many usecase outgrow what the generators could deliver (without customizing the generators templates).
Oh that’s good to know. I’ll take a look.
There is value in at least seeing what the latest generators do. There are a lot of good practices that they nudge you towards. That’s the beauty of it → commit your work, run the generator, look at the changes suggested and take what you want/need while disposing of what you don’t want/need. My favorite (can’t express how much this is excellent) generator nudge is Contexts — Phoenix v1.7.9, which makes you consider design right up front.
2 Likes
Speaking personally (and I’m not an Elixir wizard like some of the others in this thread), I appreciate the generators as a reference point and teaching tool, but they obviously can’t be everything to everybody, and I only used them to figure out how the process works, and then wired up my own code afterwards. Their overall style doesn’t really do it for me, although I’m glad they exist since Phoenix changes fast and the community is small so there’s not a lot of newer material out there, compared to more popular frameworks.
You can customize the Phoenix generators which I think would work for me, but I haven’t gone down that road yet.
1 Like
Well as I personally abhor creating CRUD forms, I will probably explore that route sometime in the future, if I can be bothered. I mean look at the typical forms: They are so boring to do and so similar to each other that there are programs making them (the generators) 
— kind of like Eclipse emitting gobs of Java code for getters and setters back in the early 2000s.
I am sure there are people who love to make them, but to me, these forms are plain boring to do, so a generator sounds nice in theory. Also, when I look at the code I have just gotten (after generating new forms), they really do not look all that bad.
I have loved Django back in the day because of the Django admin: you could spin up a new project and show the customer forms for data entry practically on the spot. I think generators are not that far off in that regard, even if you need to generate authentication first.
Maybe I am not understanding them well enough, and maybe there are pain points involved I will still uncover — but that is part of the fun, I guess.
Thanks for all the input, I appreciate it 
1 Like
If anyone told me they liked making forms, I would call them a liar to their face 
Though then I would apologize because that was really uncalled for of me.
1 Like
At the end of the day, generators are just a way of copying somebody else’s code into your project. That will always require that your code style/conventions/structure match theirs to work out of the box.
I would rather copy my own project’s code with its own existing style/conventions/structure, so I essentially only use generators very early on in a project, to get the latest dependencies/configuration/wiring from the excellent phoenix generators, since phoenix and especially liveview is still iterating fast (though we are due for a liveview 1.0 soon so I expect this to slow down dramatically).
By the time I have a roughly working initial project setup, I’ve modified these generated defaults and conventions to suit my needs enough that I can copy my own code as a “template”. I pretty much only use the ecto migration generator from there on out, mostly so that I don’t have to generate my own timestamps for migration names. (Even then I write most migrations in pure SQL, so completely replace the migration DSL inserted into those files.)
One reason I ditch the generators very early on is because I never actually want to use Phoenix’s namespacing/context conventions, so pretty much any initial codebase I write quickly strays from their conventions, you may get more milage if you follow them.
3 Likes
Agree, moreover I find kind of strange the crud applications and forms everybody talks about, I had to do maybe 1 or 2 of them in my entire career, maybe I am doing something wrong? 
Consider yourself lucky then; I can assure you that they exist. Usually it is some B2B thing which requires employees from one firm to enter a bunch of information — of course, manually — into a system.
Then, the application runs a few weeks, then you get some calls, oh no, the people have found a way to enter data that is wrong, how could this be, so you tell them to edit the things which went wrong — of course, manually — via the form again.
Then, the application runs another few weeks, then you get a call from upper management, the department of redundancy department has claimed that data is missing yes the application was not designed for this, but yes, you have to add it please please please; so you rework the form, add new fields, and tell them they can now fix it — of course, manually — via the new and shiny form again, thankfully only entering the missing new field data, not the whole thing again.
User-facing things like webshops, dashboards, or the like, well these do not need CRUD forms as often.
And if you are wondering who wants to do all of this entering data into forms — of course, manually — well let me tell you: they hire interns who do it for them. Of course they have excel sheets that you could parse way faster, but oh noes, we cannot trust the IT department with our data that we are going to enter into the application the IT department manages for us.
Alright I am rambling. Sorry.
2 Likes
Or something right, if you enjoy working on them as much as you indicate 
At the end of the day, though, a HUGE % of B2B companies fall into 1 of 2 buckets:
- A domain-specific, context aware, edit-history-enabled pretty replacement for an Excel spreadsheet that powers an entire industry
- A domain-specific, context aware, edit-history-enabled pretty replacement for a single python script + an Excel spreadsheet that powers an entire industry
Find an industry with such a spreadsheet-driven workflow, and:
- put the spreadsheets in a database
- access it with CRUD
- track modification history from form submissions
- use domain knowledge to empower better visualizations
and you have a successful startup! For more advanced usecases, encode the script in a background job framework and you’re good to go.
This is clearly a very common need, so I am grateful that Phoenix (+ Oban) cover these usecases thoroughly, in case I end up working on such a project again, though I do avoid them as well.
4 Likes
