Have you seen this thread:
Try this post first.
There are a number of threads about built in auth.
yes I did and I purposefully didnât want to mention it because I felt some might take offense but some of those explanations are exactly why Phoenix is now coming across as not newbie friendly. its kind of what I meant when I wrote
âhigh minded conceptualizations sentences without much specified meaningâ
D o not wish to offend but sentences like these have no concrete meaning -
the last one isnât that bad except whats being referred to as a web layer is quite ambiguous. you could use that language of a view.
There are a few posts in that thread that did in fact shed some light when I first read it but also quite a few that would scare the beejeezuz out of a newbie as reading some Microsoft docs would.
No, itâs much simpler than that. Contexts donât actually exist in the same way that schemas do xD A schema is a real âobjectâ (I think itâs a struct or something, I actually donât know much about ecto yet) defined using a specific macro. A context is simply a module where you dump some functions related to schemas In this way to gather related schemas.
Is it clearer now?
Haha yes, some are much more in-depth that I imagined would be posted. However, for a total nube, I think the initial description should put their mind at rest:
Phoenix Contexts are just dedicated modules for functionality that can easily be classified as a group.
I am sure that once the Phoenix book and guides are updated it will make much more sense (and if it doesnât, I am certain the team and the rest of the community will work to make it so).
not even remotelyâŠperhaps if someone could show what kind of functions you are talking thats in relation to a schema the light bulb may come on. What I thought was the best examples talked about accounts , users etc in a way that you would break up a traditional model so like I said if thats not even close then Iâd have to start all over again.
again though if there was some real code to look at it would help tremendously⊠I don;t think many people will be coming to phoenix and elixir as their very first programming experience so unless this is something entirely new to the programming world comparing it to some pattern or approach out there would be most beneficial as well. Perhaps I am dense but its only in regard to phoenix. I have had no such problems picking up any other frameworkâs concepts (but of course almost all of them are replete with code examples).
âŠbut but⊠I was including that line. It might not be confusing but its entirely meaningless. No newbie reading it is going to say aha âŠafter reading that I get what it is and why they should use it. Frankly I am sure it doesnât say anything practical even to a seasoned programmer in another language and framework
hopefully but (and I see this a lot with phoenix subjects) if you have to buy one book to begin to understand a modern web framework its not a modern web framework. People expect in todayâs language market that they can make sense of it through online resources. Always should have good books and if you are serious about a framework one written by the author of a framework SHOULD be on your shelf or tablet but the often given answer - get the book - is not something anyone is going to do that is not already committed to learning it. When that happens you are essentially asking people to literally buy into what they havenât bought into.
and thats fine if as the OP said you want the framework to be niche focused to non-newbie developers.
I think this is the main point. People donât want to be âbehindâ so they hop on the latest version no matter if itâs stable or not. The fact that there are no 1.3 tutorials is more-or-less the same as if there were not tutorials at all. Iâm pretty sure itâs not the word âcontextâ that is scaring - coming to Elixir/Phoenix you hear a lot of new words - processes, supervisors, pure functions, and more - what is scaring is that this particular new word is not mentioned in the docs or guides. I feel like for the last half a year Phoenix was in this kind of limbo of everybody waiting for the next thing, not exactly sure what to do.
This is not to assign blame or anything - I know how it is and thatâs not the point. I would be glad to help if I knew how.
Iâm reserving full and proper judgement for now as I am yet to learn Phoenix myself. (Tho the basic description seems to make sense to me.)
I think guides are great to get people going and to refer to when youâre building stuff, but if you want to properly learn something, I feel you should learn it via dedicated learning material - such as books and other professionally prepared and edited courses/material - I canât stress this enough - Iâve seen so many people (in Ruby and Rails) just hobble along and get stuck on simple things, when just reading one book would advance their knowledge immeasurably. I feel this way about all tech/languages - but thatâs just me and my preferred way of learning.
If you prefer to learn using guides, Iâm sure the Elixir/Phoenix guides are just as good as if not better than most out there
Then just use Ueberauth. It has no reliance on Guardian at all as they are two entirely distinct libraries that do two entirely different functions and you can use Phoenix Tokens just fine (I do). ^.^
By default, the generators add CRUD functions like create
, delete
, list
, etc. IMO they donât come with huge benefits (they are thin wrappers on top of the Repo functions). The idea is that you would add higher level functions there yourself like list_all_documents_for_user
, which contains a complex Ecto query. This takes away the query from your controller, which keeps the controller smaller and more focused on the web stuff.
The oyher advantage of the contexts is to only deal with the DB columns you really need. You can have a Subscription.User (which contains only a billing address, a username and a reference to a payment in the ledger) and a Document.User (that contains only the user name, a reference to documents and no billing address because that part of the app doesnât need it.
If youâre still confused about contexts, maybe you already know what they are (just modules!) and just donât see the point of having them. Thatâs ok they are overkill for very simple apps, and add some non-trivial boilerplate. My advice is to just put everything in the same context untill you think you should do it differently.
The importance of online guides is to show some code so that the user can get interested in learning further. They do not necessarily replace books. But personally I would never buy a book without looking at some high level online description with code examples - it kind of feels like a scam if the aithor of the book canât convince me that the content of the book is worth it.
Phoenixâs website is very good (perfect even): it has a high level video, an tutorial in which you build an example app and pointers for other resources. Iâm of course very interested, and will eventually buy a book by one of the authors. Still havenât decided which one to buy first though
Obviously, it doesnât contain the docs for the release candidate (with contexts), but thatâs why itâs a release candidate, and not a proper releaseâŠ
I wonât belabor the point any further but thats not what I said - Both have their place and is not a matter of me preferring one over the other. Most people who buy a book are already committed to the subject not deciding if they want to be. In todayâs world they come to that point by reading and watching online first.
Youâre in the ecto core team, so there is at least one thing you can do: either confirm that a visual editor for contexts is a good idea or dash my hopes ahaha
I know itâs probably not a good idea because contexts are not a declarative enough concept (they include functions, and editing those with a visual editor is visual programming and therefore will fail as history has shown again and again), but an interactive schema editor that maps schemas to table columns and migrations to full tables would be feasible (through introspection of the relevant ecto structs). Am I right?
Also, you might start working on a demo open source app that uses 2 or more contexts. I canât do it right now due to time constraints, but I might do it in the future
Coherence is stable and quite feature rich. Iâm using it right now. There should be a release coming soon with support for the new Phoenix folder structure. The only thing missing is an official way to integrate with Phoenix contexts. Weâre discussing ideas.
I certainly donât think that Phoenix fails here. I think that online guides on the official Elixir and Phoenix site are a pretty good start. In fact, even as a book author, I tell people to first start with the online guides for a quick start, and then move on to some book(s) if they decide to pursue the tech more seriously. The guides will give you a quick way to try out the tech in practice, and can even allow you to be productive very quickly. But for anything more involved, youâre going to need to research more material.
AHâŠLight BulB on! Best practical explanation I have read so far.
No even more so now I just found the name confusing and the general explanations I had read had not given a concrete example. Those who are experienced working with elixir and phoenix need to understand - It gives the newbie the impression that there is something going on waaay above their heads to even grasp or understand when there are multiple threads and articles with no code that are apparently intended for newbies and they donât get it or its practicality. 10 lines of code can go a long way more than a page of high view nomenclature (nothing wrong with that euther). You havenât even given code which would cement it more but at least you hinted more about what that code would look like and its practical application. THANKS MUCH!!
There are some code examples floating around (and I can give you a trivial example if you want, just wait 30mins or so). The problem is that there are no examples of apps with more than two contexts having a single conrext doesnât show all the advantages you get by using contexts.
Phoenix devs actually say that contexts arenât anything deep all the time, itâs just that people learn in different ways and up until now no one had found an explanation tailored to you specificially. I hope my stupid explanation helps others in the future.
Iâve corrected how I wrote that. My point was not toward the actual developers of Phoenix or Elixir but developers as in those who are experienced using them. I just put that in a clumsy way. I donât think seeing code is just my specific way of learning though. Its pretty universal. I now think all the talk about context without those concrete examples is whats really confusing and a barrier. Most likely once those code examples are out there it wonât be as confusing and perhaps trying to explain it without a solid example of multiple contexts in code is the real detriment.
Here is a (quite stupid) example app with two contexts, and in which two user schemas share a DB table but expose different columns according to the âneedsâ of the context. The app does nothing except defining the contexts.
See the README of the repo for more information. Link to GitHub.
If someone wants to turn this into a real app that does stuff, feel free.
Well having seen that I donât think I was far off with my understanding of discrete modelling. That bears striking resemblance to Django models except that you are separating out concerns a bit more (hence why I said more discrete). You can even add additional custom functionality to django models. I realize conceptually there are some other things going on but it does not appear to be that way off.
I was wrong about one thing though. Even seeing the code newbies are going to have issues and it presents a barrier. As a modified way to view a model I could see less of a disconnect but I gather from the name and some other responses in other threads theres a desire to force a paradigm in thinking (not just code or structure) maybe even as part of the âphoenix is not your appâ mantra that to me has a bit too high decibel.
Is it possible the reason why there is a delay in anyone showing a practical application of two contexts being necessary is really because most of the apps we use and love on the web have done perfectly fine with one âcontextâ?
That said I see why people like it and the potential power of not having one model , one table and one schema but lol I could also see myself mucking it up with too much context bloat so I donât know that that forces me to be a better Elixir programmer.
too each his own though. Iâve said enough and asked enough in this thread and I do thank you kindly for the example in code. Appreciated.