Ruby on Rails

On Jun 4, 2014, at 9:22 AM, Ronald Fischer wrote:

> My application should behave like this:
>
> - My application manages (among others) a resource called "Dicts", i.e.
> there is a dicts_controller, and my routes.rb contains a "resources
> :dicts".
>
> - I have a home page (starting page), which will eventually contain some
> user authentification (not implemente yet), and then allow the user to
> manage the Dicts objects. I have a home_controller and my routes.rb
> contains
> match '/login', to: 'home#login', via: 'get'
> root 'home#init'
> and init.html.erb contains the login form.
>
> So far it's quite conventional. Now to the perhaps unusual part:
>
> - For convenience to the user, the login form contains not only fields
> for entering the user data (userid, password), but also an entry field
> for a Dicts object, and *two* submit buttons, one with the meaning of
> "login and create a new dictionary", and the other one with the meaning
> "login and open a existing dictionary":
>
> <%= form_tag("/login",method:"get", enforce_utf8:true) do %>
> ....
> <%= submit_tag(value="Create New Dictionary", class:
> 'kanren_button', name: 'create') %>
> <%= submit_tag(value="Open/Pick Existing Dictionary", class:
> 'kanren_button', name: 'open') %>
> <% end %>
>
> Now the problem:
>
> My HomeController.login method checks, whether the user is authorized,
> and if he is, needs to go to the Dict controller and either :create a
> new Dict object or :show an existing one.
>
> My problem is that to :create a Dict, would require a POST action (if I
> want to stick with the REST model), but a
>
> redirect_to url_for(:controller => dicts,...)
>
> will always create a GET request.
>
> I was thinking of the workaround to use
>
> redirect_to url_for(:controller => :dicts, :action => :new)
>
> and inside Dicts#new use the parameters passed, to create a new Dicts
> object, and (if successful) redirect to Dicts#show or whatever, but this
> doesn't seem to be an elegant solution.
>
> Another possibility is to invoke Dicts.create from my Home.login method,
> but this doesn't seem to be good style either.
>
> Any suggestions on how to proceed?

When you start implementing your authentication and authorization solution, you may find that you need/want to refactor this initial approach that you've sketched. Most authentication systems (Devise, auth_logic) use a SessionsController and the notion of a session as the repository of who the user is at the moment. Authorization engines, like CanCan, hook on to that session to determine what the current_user can do at the moment to whatever object is in play.

With those two things in mind, you may want to structure this application differently. Let's say you have a link to your new_dict_path somewhere. Your user (logged in or not) clicks that link and should be directed to the form where a new dict can be made. If your authorization framework has determined that creating a dict is something that only a logged-in user can do, then you would be redirected to the login form, and then upon a successful login, redirected back to that form, already populated with the user_id of the current_user. If the user was already logged in, then they would skip that intermediate step.

I would definitely not mix the login logic with the "show the home page" logic as you seem to have done here -- think about your controllers as mediating a particular resource between the system and the user -- your home page is not the session, nor vice-versa.

Walter

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

--
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/AF1EE439-0C83-485E-9D50-12B11B0DBAC3%40wdstudio.com.
For more options, visit https://groups.google.com/d/optout.