Ruby on Rails

On 6/4/14, 1:19 PM, Ronald Fischer wrote:
> 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.
This would not be the HomeController. That would just be a dashboard. My
idea is a whole MVC component that is an object called login that has
not database backing in and of itself. Rather than being a true object
you could think of it as a functional object that can be validated. When
valid it /converts/ its virtual attributes into the attributes of the
objects that it is concerned with managing, in this case a user session
(the credentials) and a dict (or even multiple dicts) and instantiates them.
>
>> Its similar to
>> _http://railscasts.com/episodes/416-form-objects?view=asciicast_
> I will have a look at this.
Yes please do. I think that this will give you a better idea of what I
mean by a functional object and will show you the basic technique needed
to make this happen.
>
> 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?
A form can do a get or a post, but not both at the same time. You would
need to change the form action though JS. also you would have to have
your routes set up accordingly.
>
> 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?).
>

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