Ben Johnson
2007-Jun-19 15:33 UTC
What is the role of the controllers? (Advanced question)
I am not a noob, and this is actually I pretty "deep" question and it''s been really kicking my ass. I wanted to get some feedback from other experienced rails developers. Any help would be greatly appreciated. I would even pay for some feedback to this. So here it goes... I have noticed a lot of people making a controller for each model. The point of this is to keep all controller code related to that model in that controller. This allows me to set up routes as follows: map.my_account ''my_account/:action'', :controller => "users" map.register ''register'', :controller => "users", :action => "new" map.checkout ''checkout/:action'', :controller => "orders", :action => "new" So far this seems great and clean, but I ran into a problem doing this. When I was doing the checkout I needed to have a user login or register right there, I should not have to redirect them to the login or registration page. So I made a partial with the user registration form and included it in both areas. The million dollar question is where does that registration form action point? Does it point to /register or does it point to checkout/register? If it goes to checkout/register I have violated the rule of keeping all user code in the users controller, because now I am registering a user in the orders controller (my checkout route points there). Another problem is that the my_account/register action simply redirects me to the home page after registering. The checkout/register sends back javascript to update HTML on the page. So now I have 2 areas on my site wanting to do the same thing but expecting 2 different responses. So I could do one of 2 things: 1. I could set up another route: map. checkout_register ''checkout/register'', :controller => "users", :action => "new" Then in the users controller I could see if they are registering from /register or checkout/register and render the appropriate response based on that. 2. I could make a method in my application_controller called register_user and then just use that method in both the users/new method and the checkout/register method. Now each controller can render whatever response it wants. #2 seems to be the best in my opinion. This situation has defeated the whole idea of making controllers to handle all code for that model though. Here is the ultimate question: Does a controller represent a set of methods that perform actions on a similar piece of data (ex: a user object)? Or does a controller represent a set of methods that help prepare data for views that are related (as in my example above, you could actually be registering a user in more than one controller)? Sorry for the long question, thanks for your help. -- 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 post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
This may not answer your bigger question, but to the specific example, you could stash the referrer url in the session, go to the registration and login, and then redirect back to the saved location rather than the home page. In restful_authentication plugin this is what the store_location and redirect_back_or_default method do. Then your controller actions stay separate. linoj On Jun 19, 11:33 am, Ben Johnson <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> I am not a noob, and this is actually I pretty "deep" question and it''s > been really kicking my ass. I wanted to get some feedback from other > experienced rails developers. Any help would be greatly appreciated. I > would even pay for some feedback to this. So here it goes... > > I have noticed a lot of people making a controller for each model. The > point of this is to keep all controller code related to that model in > that controller. This allows me to set up routes as follows: > > map.my_account ''my_account/:action'', :controller => "users" > map.register ''register'', :controller => "users", :action => "new" > map.checkout ''checkout/:action'', :controller => "orders", :action => > "new" > > So far this seems great and clean, but I ran into a problem doing this. > When I was doing the checkout I needed to have a user login or register > right there, I should not have to redirect them to the login or > registration page. So I made a partial with the user registration form > and included it in both areas. The million dollar question is where does > that registration form action point? Does it point to /register or does > it point to checkout/register? If it goes to checkout/register I have > violated the rule of keeping all user code in the users controller, > because now I am registering a user in the orders controller (my > checkout route points there). Another problem is that the > my_account/register action simply redirects me to the home page after > registering. The checkout/register sends back javascript to update HTML > on the page. So now I have 2 areas on my site wanting to do the same > thing but expecting 2 different responses. So I could do one of 2 > things: > > 1. I could set up another route: > map. checkout_register ''checkout/register'', :controller => "users", > :action => "new" > Then in the users controller I could see if they are registering from > /register or checkout/register and render the appropriate response based > on that. > > 2. I could make a method in my application_controller called > register_user and then just use that method in both the users/new method > and the checkout/register method. Now each controller can render > whatever response it wants. > > #2 seems to be the best in my opinion. This situation has defeated the > whole idea of making controllers to handle all code for that model > though. Here is the ultimate question: > > Does a controller represent a set of methods that perform actions on a > similar piece of data (ex: a user object)? Or does a controller > represent a set of methods that help prepare data for views that are > related (as in my example above, you could actually be registering a > user in more than one controller)? > > Sorry for the long question, thanks for your help. > > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Jacob Atzen
2007-Jun-19 17:52 UTC
Re: What is the role of the controllers? (Advanced question)
Ben Johnson wrote:> I have noticed a lot of people making a controller for each model. The > point of this is to keep all controller code related to that model in > that controller. This allows me to set up routes as follows:This basic assumption is where you go wrong IMHO. There is no rule saying anything about the relationship between models and controllers. Actually one point of having models and controllers separated is that the model should be easily accessible from more than one location. Stop worrying about it and use your models where you need them.> Does a controller represent a set of methods that perform actions on a > similar piece of data (ex: a user object)? Or does a controller > represent a set of methods that help prepare data for views that are > related (as in my example above, you could actually be registering a > user in more than one controller)?You can create controllers for manipulating similar data or for related views. Do whatever feels most natural and pain free. On a related note, check out some of the blogposts on skinny controller and fat models floating around the blogosphere, they might give you a solid perspective on things. -- Cheers, - Jacob Atzen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Note also that if you define a login method in application.rb, it is accessible to any controller in your app. Again, store_location, or any similar means or remembering the intended destination will work fine to move the user along to the right page after they log in. On Jun 19, 2007, at 8:33 AM, Ben Johnson wrote:> > I am not a noob, and this is actually I pretty "deep" question and > it''s > been really kicking my ass. I wanted to get some feedback from other > experienced rails developers. Any help would be greatly appreciated. I > would even pay for some feedback to this. So here it goes... > > I have noticed a lot of people making a controller for each model. The > point of this is to keep all controller code related to that model in > that controller. This allows me to set up routes as follows: > > map.my_account ''my_account/:action'', :controller => "users" > map.register ''register'', :controller => "users", :action => "new" > map.checkout ''checkout/:action'', :controller => "orders", :action => > "new" > > So far this seems great and clean, but I ran into a problem doing > this. > When I was doing the checkout I needed to have a user login or > register > right there, I should not have to redirect them to the login or > registration page. So I made a partial with the user registration form > and included it in both areas. The million dollar question is where > does > that registration form action point? Does it point to /register or > does > it point to checkout/register? If it goes to checkout/register I have > violated the rule of keeping all user code in the users controller, > because now I am registering a user in the orders controller (my > checkout route points there). Another problem is that the > my_account/register action simply redirects me to the home page after > registering. The checkout/register sends back javascript to update > HTML > on the page. So now I have 2 areas on my site wanting to do the same > thing but expecting 2 different responses. So I could do one of 2 > things: > > > 1. I could set up another route: > map. checkout_register ''checkout/register'', :controller => "users", > :action => "new" > Then in the users controller I could see if they are registering from > /register or checkout/register and render the appropriate response > based > on that. > > > 2. I could make a method in my application_controller called > register_user and then just use that method in both the users/new > method > and the checkout/register method. Now each controller can render > whatever response it wants. > > > #2 seems to be the best in my opinion. This situation has defeated the > whole idea of making controllers to handle all code for that model > though. Here is the ultimate question: > > Does a controller represent a set of methods that perform actions on a > similar piece of data (ex: a user object)? Or does a controller > represent a set of methods that help prepare data for views that are > related (as in my example above, you could actually be registering a > user in more than one controller)? > > Sorry for the long question, thanks for your help. > > -- > Posted via http://www.ruby-forum.com/. > > >Steve Ross sross-ju+vs0qJmyeQKKlA4PA9hA@public.gmane.org http://www.calicowebdev.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---