I know that if you listen to DHH and similar REST evangelists that they would have you believe that all methods can be reduced to the seven that fit the REST conventions (create, show, update, destroy, index, new, and edit). I am not yet convinced. For example can anybody think what model I would use for forgot_password and reset_password. I have a user model that has a password as a field. I do not really want to have a password model since I guess this is supposed to map to a password table in the database. What does everybody think. As you can see this is more of a philosophical than a technical question. Looking forward to some interesting replies. Anthony --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Would this not be an update to the user model? That is, changing a password would be as simple as updating the user model. However, lost password recovery is something else. From my understanding, REST is not only a way to design web sites that are then easier to use as an API, but to allow others to put their web front-end on top of your RESTful database back-end. If this is the case, wouldn''t lost password recovery be something that the front-end might do, given the basic primitives you provide? To be honest, REST not something I am following closely, but I do understand the need for a unique operation at a unique address. No more index.php-does-everything for me :) --Michael --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Oct 18, 2007, at 12:29 , Ant wrote:> For example can anybody think what model I would use for > forgot_password and reset_password. I have a user model that has a > password as a field. I do not really want to have a password model > since I guess this is supposed to map to a password table in the > database.There''s no reason to have a one-to-one correspondence between controllers and models, nor between models and database tables. I''ve used a separate AuthenticationsController (with new, create, and destroy actions) to handle logins. Works well. Forgotten/reset password, depending on what you''re doing, you might have a ForgottenPasswordNotificationController with new and create actions to send out notifications, and a separate PasswordsController (perhaps nested under your UsersController?) that has edit and update actions? Or perhaps PasswordsController#new posts to #create which in turn sends the notification? Just ideas here, and I haven''t really thought through them too far, but it''s a start. The thing to keep in mind is the resource that you''re acting on. Hope this helps. There''s no reason you have to map everything to REST, but many times you can if you want. Michael Glaesemann grzm seespotcode net --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
In my experience, I''ve found that you either create a custom method (blahblahblahdon''tdothatblahblah) or another controller. In this situation, it would depend on the scale of the application and how much the remote API was going to be used. Little to no remote API usage? Custom method it is. A _lot_ of API usage...I might consider another controller. I don''t think either way is the absolute correct way, but I think you have to formulate your answer based on the application itself and how it will be used. --Jeremy On 10/18/07, Ant <email2ants-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > I know that if you listen to DHH and similar REST evangelists that > they would have you believe that all methods can be reduced to the > seven that fit the REST conventions (create, show, update, destroy, > index, new, and edit). I am not yet convinced. > > For example can anybody think what model I would use for > forgot_password and reset_password. I have a user model that has a > password as a field. I do not really want to have a password model > since I guess this is supposed to map to a password table in the > database. > > > What does everybody think. As you can see this is more of a > philosophical than a technical question. > Looking forward to some interesting replies. > > Anthony > > > > >-- http://www.jeremymcanally.com/ My books: Ruby in Practice http://www.manning.com/mcanally/ My free Ruby e-book http://www.humblelittlerubybook.com/ My blogs: http://www.mrneighborly.com/ http://www.rubyinpractice.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 -~----------~----~----~----~------~----~------~--~---
On Oct 18, 12:29 pm, Ant <email2a...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> For example can anybody think what model I would use for > forgot_password and reset_password. I have a user model that has a > password as a field. I do not really want to have a password model > since I guess this is supposed to map to a password table in the > database.Putting on my "Everything can be restfully modeled" hat, what about this? map.resources :forgotten_passwords The new form would have a field for email address. Create would call logic in User to do the reset. The link would be sent to the user, using the reset code as the ID for forgotten_passwords http://app.com/forgotten_passwords/123456asswqdwqj1221312321 The show on the forgotten password would have a form to put to the user resource and change the pass. Actually, now that I say all that, it doesn''t seem nearly as crazy as I thought it would. That''s pretty clean. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Ant wrote:> I know that if you listen to DHH and similar REST evangelists that > they would have you believe that all methods can be reduced to the > seven that fit the REST conventions (create, show, update, destroy, > index, new, and edit). I am not yet convinced. > > For example can anybody think what model I would use for > forgot_password and reset_password. I have a user model that has a > password as a field. I do not really want to have a password model > since I guess this is supposed to map to a password table in the > database. > > > What does everybody think. As you can see this is more of a > philosophical than a technical question. > Looking forward to some interesting replies. > > Anthony > >I would create a PasswordRemindersController. * ''new'' action provides a form for the user to enter their username and/or email, or something. * ''create'' action sends them an email with a reset password and redirects to ''show'' action. * ''show'' action simply gives a message that the email has been sent and that they should check for it. The ''show'' action could be eliminated if you wanted the ''create'' to just show the message, but convention dictates that POST and PUTS redirect on success, otherwise if someone started reloading that page, it would keep resetting their password to something else and sending another email. As Michael pointed out, there is absolutely no need for a 1 to 1 correlation between controllers -> models -> tables. This is a classic example of a RESTful controller with no need for a corresponding model. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Thank you all for your replies. All very helpful and have got me to reassess both MVC and REST again. I think that taken together there will be some stuff I can implement, particularly not having to have a model for every controller. Thanks again, Anthony --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---