I''ve been working with authentication systems lately and I''m
basically
seeing actions composed in two different ways.
_Model A_
In Model A, a form posts back to the action that rendered it, and if
the form post is successful then the action redirects elsewhere. For
example, account creation in Acts As Authenticated is like this:
View Action: account/signup
View: views/account/signup.rhtml
HTML Form Action: account/signup
Psuedo Controller Code:
def signup
if not form post
render template
else
create new user
if success
redirect somewhere
else
re-render template with error message
end
end
end
As you can see, this action is very similar to what a Controller#new/
Controller#create pair typically do, however the overall composition
is using more of a "post back" technique.
Additionally, other methods in AAA--login, change_password, etc.--
follow this model as well.
_Model B_
In Model B, the flow of things is more RESTful.
View Action: users/new
View: views/users/new.rhtml
HTML Form Action: users/create
Psuedo Controller Code:
def create
create new user
if success
redirect somewhere
else
re-render action with error message
end
end
As you see, is the more traditional Controller#new/Controller#create
pair model. In my view, this is the evolving best practice because
it''s more RESTful.
All that said, a few questions as I''m trying to get my head around
authentication, but the thoughts are broadly applicable:
1) In authentication systems such as AAA, there is both an Account
and User controller. But, there is no account model--both the User
Controller and Account Controller act upon the User Model. This is
what I am trying to get my head around: what is the philosophy or
theory behind having two Controllers?
In Account, the actions are typically formulated using Model A whereas
in User the actions are formulated using Model B. Again, why?
2) Where do actions like login, logout, forgot_password,
change_password belong. Those would seemingly be actions that "act
on" a User, but they''re not RESTful (i.e. C, R, U or D). Perhaps
this
is why there is an Account Controller--it contains User actions that
are not RESTful.
3) If the last sentence of #2 is true, then why does Account#signup
exist? It seems to be a duplicate of the User#new/User#create pair
(i.e. the C in CRUD). (In fact, this is what got me thinking about
this whole topic: why does AAA implement both Account#signup and
User#new/User#create?)
Bottom line: I''m trying to get my head around the role of the Account
Controller, and the relationship between the Account Controller and
User Controller. Underlying that question is a) I can''t make up my
mind if I should have both Account and User, or just User, b) if I
have both, then which actions belong in each, and c) which composition
model from above is the appropriate best practice.
I hope I''ve expressed all that clearly...thoughts??
Scott
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
On 10/5/07, Scott <scottporad-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > I''ve been working with authentication systems lately and I''m basically > seeing actions composed in two different ways. > > _Model A_ > > In Model A, a form posts back to the action that rendered it, and if > the form post is successful then the action redirects elsewhere. For > example, account creation in Acts As Authenticated is like this: > > View Action: account/signup > View: views/account/signup.rhtml > HTML Form Action: account/signup > Psuedo Controller Code: > > def signup > if not form post > render template > else > create new user > if success > redirect somewhere > else > re-render template with error message > end > end > end > > As you can see, this action is very similar to what a Controller#new/ > Controller#create pair typically do, however the overall composition > is using more of a "post back" technique. > > Additionally, other methods in AAA--login, change_password, etc.-- > follow this model as well. > > _Model B_ > > In Model B, the flow of things is more RESTful. > > View Action: users/new > View: views/users/new.rhtml > HTML Form Action: users/create > Psuedo Controller Code: > > def create > create new user > if success > redirect somewhere > else > re-render action with error message > end > end > > As you see, is the more traditional Controller#new/Controller#create > pair model. In my view, this is the evolving best practice because > it''s more RESTful. > > All that said, a few questions as I''m trying to get my head around > authentication, but the thoughts are broadly applicable: > > 1) In authentication systems such as AAA, there is both an Account > and User controller. But, there is no account model--both the User > Controller and Account Controller act upon the User Model. This is > what I am trying to get my head around: what is the philosophy or > theory behind having two Controllers? > > In Account, the actions are typically formulated using Model A whereas > in User the actions are formulated using Model B. Again, why? > > 2) Where do actions like login, logout, forgot_password, > change_password belong. Those would seemingly be actions that "act > on" a User, but they''re not RESTful (i.e. C, R, U or D). Perhaps this > is why there is an Account Controller--it contains User actions that > are not RESTful. > > 3) If the last sentence of #2 is true, then why does Account#signup > exist? It seems to be a duplicate of the User#new/User#create pair > (i.e. the C in CRUD). (In fact, this is what got me thinking about > this whole topic: why does AAA implement both Account#signup and > User#new/User#create?) > > Bottom line: I''m trying to get my head around the role of the Account > Controller, and the relationship between the Account Controller and > User Controller. Underlying that question is a) I can''t make up my > mind if I should have both Account and User, or just User, b) if I > have both, then which actions belong in each, and c) which composition > model from above is the appropriate best practice. > > I hope I''ve expressed all that clearly...thoughts??I''d argue that the second method was LESS restful. Rest is not about having actions named create read update and delete, it''s about using the http methods post, get, update, and delete to act on resources represented by uris. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 5, 6:06 am, "Rick DeNatale" <rick.denat...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > I''d argue that the second method was LESS restful. > > Rest is not about having actions named create read update and delete, > it''s about using the http methods post, get, update, and delete to act > on resources represented by uris. >Ya know what, you''re exactly right...it is less RESTful. A few semi- disconnected questions: 1) My original confusion still stands, though: what is the purpose of the Accounts controller? Should I be using Accounts#signup or Users#new? 2) If we''re being truly RESTful then then answer is Users: if you POST to /users then we''re calling Users#new. (I guess that''s not a question.) 3) With that in mind, where do actions such as #login, #logout belong? I''d say they belong on User and that the Accounts controller is a complication, but I''m not sure. Also, where do these types of actions fit in with REST? Scott http://progress-vs-perfection.blogspot.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---