Closed wle8300 closed 9 years ago
Whoa. I realized I said a lot of erroneous things (both wiki articles) now that I've had some time to look at frame more.
Fix coming soon. Within one week's time max.
Maybe it's best to remove the content until you correct it. Having incorrect information published may be worse than none.
Will do. I'll do it right now.
On Fri, Jun 26, 2015 at 1:20 PM, Reza Akhavan notifications@github.com wrote:
Maybe it's best to remove the content until you correct it. Having incorrect information published may be worse than none.
Reply to this email directly or view it on GitHub: https://github.com/jedireza/frame/issues/88#issuecomment-115867636
Thanks so much BTW, you're doing a great job!
No prob. I reverted it back to your edits.
I figure things out by writing and making graphics, but I didn't really have a proper idea of how all the roles work together before I updated the wikis. I'll update the wikis when I wrap my mind around all the roles, and what not. I keep encountering surprises as I create and cast roles to users.
For example, Why don't new Admins become Users too? I thought User was a superclass that encapsulates both Accounts and Admins...? That was a weird one for me that I discovered today, that I'm still trying understand your rationale. Any help appreciated.
I quickly skimmed the content before and it seemed like you where on the right path. But I haven't had time to review it thoroughly.
Why don't new Admins become Users too? I thought User was a superclass that encapsulates both Accounts and Admins...?
Admins and accounts are the roles a user can play. You could create account/admin records and not link them to a user, but they wouldn't be able to login. You could also create a user record without connecting it to a role, but again, not useful on it's own.
Oh ok, that was the puzzle piece I needed to wrap my mind around things. I didn't pay attention to POST /api/users.
I thought that creating Users was exclusively through POST /api/signup, but it seems that you designed it to be a convenience endpoint (for creating a User and Account in a single request).
That seems a little strange to me. I can't seem to think of a real-world situation where you would want to create an Admin/Account, but not allow that user to login. Do you have rationale for this?
I can't seem to think of a real-world situation where you would want to create an Admin/Account, but not allow that user to login.
:wink: You'll also find PUT
and DELETE
verbs for the /accounts/{id}/user
and /admins/{id}/user
routes which contain the logic for linking and unlinking a user to the role. So yes, usually you don't have accounts or admins without linking them, but keeping the logic separate is easier to reason about.
Also in practice people do unexpected things (like creating multiple accounts) and if you want to help repair things like this, having the ability to control these steps gives you flexibility.
If you haven't yet, take a look at Aqua (which was built on Frame), you'll see UI for these features.
Ohh... ok I didn't think of the situation where a user would create multiple accounts. Good planning.
I feel like a more robust collection of how-to wiki articles with real-world cases & code examples would be helpful for people like me who are spending a lot of time wading through the API, and making heads and tails of the boilerplate.
It's been a little dizzying figuring out how all the models "click" together. I get it now, but the wiki articles didn't help much for that.
Aqua is great, but people who already know (like myself) that they just need a backend for their new mobile app won't consider Aqua, and so, they won't use the front-end you made: they just looking at the lout docs! Which is a bad way to impress people I think.
If you have the time, and can stub a collection of meaningful wiki articles for frame/aqua I can work with you to develop them more.
Aqua is great, but people who already know (like myself) that they just need a backend for their new mobile app won't consider Aqua, and so, they won't use the front-end you made: they just looking at the lout docs! Which is a bad way to impress people I think.
I suggested to look at Aqua as a possible way to further your understanding of the API. I should've been more clear by saying "checkout Aqua's demo site (not necessarily the code)." :smile:
If you have the time, and can stub a collection of meaningful wiki articles for frame/aqua I can work with you to develop them more.
There is an issue in Aqua to convert some of the Drywall wiki pages. These one's specifically:
The ideas are the same but there are differences (like with the models) between Drywall and Frame.
Thanks for offering to help out. The challenge for me now is allocating time.
Thanks for the support @jedireza. As I figure things out, I can try to weave some wiki articles together.
I think frame is great because you're sticking with Hapi's style guide, and their ecosystem of tools. Also, you're not making any assumptions about front-end code. I think that's a really great decision because it lets people have freedom of choice for the remainder of their stack. Very empowering!
https://github.com/jedireza/frame/wiki/Users,-Roles-&-Groups
I reorganized it, added a graphic, and made stylistic changes. I'm not sure if you get notifications for this, so just putting this here.
Let me know if I was wrong about something, and I'll fix it!