Jesse Knutsen wrote in post #1148818: > On 6/4/14, 10:30 AM, Colin Law wrote: >> > You are 100% correct, but he was going to redirect to Dicts#new.
Only as a work-around, but as I said, I was not so happy with this either. > DictController > ... > new > if params[:new_dict] > create logic > else > new logic > > This would get very convoluted and inelegant. Yes, absolutely! > Hence why I feel a Class of login that will do both the login logic and > the create Dict logic in one place This would be what I called HomeController, isn't it? Or do you mean a separate helper class, which is *not* a controller? I thought about doing the Dict creation in HomeController.login, but then I have the logic of dealing with Dict objects twice: The larger part will be in the DictController, and the creation logic will be in HomeController. In addition, I expect in a later version HomeController *also* to be able to create Dict objects. > Its similar to > _http://railscasts.com/episodes/416-form-objects?view=asciicast_ I will have a look at this. Meanwhile I was thinking whether the main problem comes from a different place: A form can issue a GET or a POST, right? But the method must be specified inside the form; in my case, I have it set to GET. However, the form has two buttons, and one is (from the viewpoint of logic) doing a GET and the other one should do a POST. Of course I can't have both. Maybe it is the form which needs to be modified? If I could attach the method (GET/POST) to the submit button instead of the form itself, this would solve my problem. Maybe you could have a look at my form and let me know whether I could do this better? One other issue is that I am using the 'form_tag' method, but Rails also offer form_for. Would I get some benefit of using form_for (maybe based on a Dict object?). -- Posted via http://www.ruby-forum.com/. -- 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+unsubscr...@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/b6032cb5651ecc76c9c5041e25d34022%40ruby-forum.com. For more options, visit https://groups.google.com/d/optout.
