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.