Ruby on Rails

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

--
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/538F5B7A.7010909%40gmail.com.
For more options, visit https://groups.google.com/d/optout.