Wednesday, June 4, 2014
On Wednesday, June 4, 2014 1:47:05 PM UTC-4, jess wrote:
On 6/4/14, 1:38 PM, Ronald Fischer wrote:
> Jesse Knutsen wrote in post #1148812:
>> On 6/4/14, 10:08 AM, Ronald Fischer wrote:
>> Essentially you are calling two different actions right now (in your
>> design) where the first leads to the second through a redirect. This
>> redirect will actually redirect the user on the browser level, its not
>> just a render. While you can do that, its not efficient.
>>
>> This method would conglomerate the two into 1: A login.
>>
>> If valid (valid being defined as a valid set of user credentials and
>> valid entries for the new Dicts) it would trigger a session creation and
>> the appropriate Dict creation, based on the button that is clicked.
> So, basically, my current "login" method would go into the Dict object?
> This indeed would make it easier.
yes it would handle both login and dict creation/update
>
> The reason why I had a separate controller for the login stuff was, that
> I thought that when my login logic gets more sophisticated (with
> password, authentification and all that thing), it would make more sense
> to have a separate controller for this.
The actual authentication and login should be business logic of the
UserSession model or the User model (you can justify either way), which
should be able to accessed from elsewhere (skinny controller)
>
> I now start to realize that I want to have the cake AND eat it. Either I
> should completely separate the login from the rest of the program, as
> for instance Walter Davies suggested above, or I want to have it
> together in one form, but then it means that two controllers cause
> trouble.
I would agree on this. Its kind of strange to try to both at the same
time. What I would suggest for ease is just do a /normal/ flow with each
model having its separate views and take it from there. See what the
flow you want is and figure out what makes the best sense for your users.
> Actually, I feel that I am putting too much logic into a controller. It
> would be cleaner to factor these things out to "helper classes" which
> can be called from everywhere. Just a thought experiment: Imagine that
> my design would have in the footer of every page an entry field and a
> button saying "create a Dict", I don't think I would have to redirect to
> the Dict controller and then going back to the original place just for
> 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.
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/201e2326-5b24-4d27-85f0-b97b31d252a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment