Ruby on Rails

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+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/b6032cb5651ecc76c9c5041e25d34022%40ruby-forum.com.
For more options, visit https://groups.google.com/d/optout.