On Wednesday, June 4, 2014 1:47:05 PM UTC-4, jess wrote:
This method would conglomerate the two into 1: A login.
I thought that when my login logic gets more sophisticated (with
trouble.
this. Instead I would have somewhere a “Dict factory”, which just
creates, initializes (and returns) the new Dict object.
In that case I would have the field and submit button and the form
points to the dict controller but it functions as ajax and the form
passes a v attribute that tells it that this create does not need a
render return and display a success growl instead
I have to disagree. First of all, I think it’s trouble to combine the
login and dictionary create/select existing logic in the same controller
or
controller actions. It is true that a redirect involves a round trip to
the browser, but I think the performance hit (since it should only
happen
once in a session) is minor compared to the cost in terms of programming
which I’ll illustrate below.
Login is usually not part of the User model nor any another model, it is
associated with the session resource which typically has its own session
(or UserSession) controller and does not have an associated model
(although
it can). The session is its own resource with its own new, create, and
destroy actions. To the extent anything is stored in a session, it’s
stored to the session store which, by default, is in a cookie.
Personally,
I don’t think it belongs in the User model ever. It does access the
User
model, of course, as part of the authentication process, but any actions
associated with a user (such as creating, changing password, etc.) are
not
part of login, they’re part of the user resource.
Dict, in this case, is its own resource and, IMO, should have its own,
separate controller with the full set of controller actions (new,
create,
etc) and that’s where the logic belongs.
To demonstrate this, let’s walk through once scenario and assume that
you
have both login and create/select existing dictionary in one controller.
The user enters the login information, and in this scenario, the name
of
an existing dictionary and clicks on the button to submit to use an
existing dictionary. The login authentication passes but,
unfortunately,
the user entered the name of a dictionary that, in fact, does not exist.
What do you do now? Do you assume that the user meant to create a new
dictionary? Or do you assume the user made a typo? The normal response
would be to display the entry form with the data entered and with an
error
message asking the user to correct it. In this case, are you going to
make
the user login again? If not, are you now going to need two new actions
to
present a different form for the user to correct their mistake and
another
action to process that once it’s submitted (since there would be no
login
with this)? If you do all of this you will now have the logic to create
and select a dictionary in two different actions and that is far worse,
IMO, than the performance hit of a redirect.
I would also consider that a user may want to use an existing dictionary
and then later in their training session, may want to create a new
dictionary. Are they going to now have to login again? Or will there
now
be another set of forms & actions?
Please note that the structure of your controllers and actions do not
dictate your presentation to the user. You can still have a login page
and
have the user designate a dictionary or create a dictionary at the same
time. However, in this case, I would reconsider as the above posts
recommend. I would think it’s a lot more user friendly to present a drop
down list of existing dictionaries to select, or an option to create a
new
dictionary after login. Necessarily, that has to occur after login
because
in order to make the drop down list, you need to know who the user is.
I do think that ajax is a good recommendation. Selecting, creating, or
changing a dictionary could be accessed from any page making it much
more
user friendly and a success growl is fine, but again, you should be
prepared to handle the case where a user tries to create a dictionary
that
already exists (which could be a simple error message instead of a
success
growl).
When you talk about helper classes being called from anywhere, it sounds
like you are referring to view helpers and you should never have
controller
logic in a view helper. You could make a controller helper, but those
are
intended to be called by a controller action, not from within a view.
I’m
not sure exactly where you were headed with that, but, again, if you use
ajax, you would then submit directly to the dict resource create action.