*cough*oop*cough* Don’t use this ^.^
There definitely is!
I use a ton of snippets in my editor and can fill out entire, say, GenServers or Controllers with but 2 keystrokes, including filling in default values and other things, but those are definitely more useful in an IDE then a command prompt I do think. 
This is, for the lack of a better word… Amazing, I guess? xD If you base these things on an Agent or a GenServer you can get mutable class attributes, python style, right? xD I can’t wait to reimplement Flask, Django or Pyramid in Elixir based on this oop library!
The ergonomics of using these generators on a command prompt are not very good. Once I made a typo and spent the next 10 minutes chasing places where I had to change the code. I’ve been thinking on writing a mix task to run the generators based on a yaml file, as yaml files are very lightweight and allow you to use a decent text editor and proofread your template before generating actual code.
Alternatively, something like a GUI “context builder” could be useful. This could be done as a local phoenix app for maximum portability. IDE plugins would be cool too, but they’re less portable.
I believe you have described the feelings of many very very well. Thank you for posting.
Part of the issue here is that many still make contexts more than they are, they are just modules and directories.
But it is also part of how we introduced those modules as hard boundaries, which makes you feel you need to get them right from the beginning, and that’s not necessarily the case. We will work on some improvements for the next RC which hopefully will take some of the burden from developers.
That’s exactly how I use generators too, including Phoenix. The learning tools focus to me means that we won’t shy away from adding comments and that we won’t generate a bunch of unnecessary files on the odd chance you may need to do something with them.
Naming is hard.
I also think “services” are even more loaded than “context”. Concern feels like a subset rather than superset. For example, a user has many concerns. While “context” expresses the idea of groups / ownership.
A “business module” is not bad but I am afraid calling it “business” will make it even harder for people to come up with names, as they may want to name it directly to an aspect of the business or the organization and that’s not always the case.
@Qqwy’s description, summarized by @AstonJ, is really good: contexts are just dedicated modules for functionality that can easily be classified as a group.
Thanks for confirming that José, I have added it to the learning resources thread:
(I’m sure we can expand on it a little, but for now I think it’s fine to give people a very quick overview.)
Context is just like a scope for the modules, is not more than this, i advice who have negative positions about it to start an 1.3 phoenix project and start coding, you will see that did not change almost anything, just the structure of modules…i recently started an 1.3 project myself and like it. Before start using context was sound more complex than really are. Is a good move to have code more organized. I like it.
Ah, seems like this is a quite general issue because I see people in Elm community struggling with composing application written in FP structure too although they also have architecture constraint (TEA).
I brought Phoenix context thinking into Elm files structure, and it turns out ok-ish because there is only single source of truth while elixir/phoenix can use Repo to update several tables independently. I generalize context mindset as a place where functionalities requires different data structures to be working with
Like Chemical Formula is a context where different Elements live together to form certain characteristic and functions. A bunch of elements can form different chemical formulas .. (H2O)!
OGod that sounds horrifying! I look forward to it! ^.^
Yeah this is exactly it, people assume Contexts are more than what they are when they are just normal separation of concerns.
Understatement of the century. ^.^;
/me often gets hobbled and frozen by just figuring out how to ‘name’ something, so usually ends up just giving things very generic names (look at overminddl1’s github for project names as an example)
I think that well sums up my feelings on why I did not like Concern yeah.
Hmm, Scope feels a lot better to me, would have to play with it to be sure or not, feels ‘incomplete’ still…
I’d argue Rails became popular despite it’s complexity. It became popular because of strong community patient teachers showing a better way, not because of any sort of magic the generators provided. It became a go-to tool because we had the ability to point new developers to _Why, Ryan Bates, Saint Joe, José, Sandi Metz, and Avdi. (normally in that order).
It’s worth pointing out that my team was organizing code around things that looked a lot like contexts after a couple weeks working in Phoenix. It felt natural… especially once we started reading more on FP. Really that’s what I think is missing… we need our (non-pro-parts) RailsCasts and our POODR. I want the ability to point juniors to something that isn’t written in F#, Scala, or Scheme to learn FP concepts and architecture.
But nah - I reject the idea that contexts would be a stumbling block to learning the framework.