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:
- 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?
-
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. -
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