Hi Erik, In my experience, creating a new controller is the best way to go. If you EVER want to tweak the /users or /master_gardeners views or logic at some point later in time, even the littlest thing, a new controller will make your life sooooo much easier. It really becomes problematic when you start mixing different workflows through the same controller, utilizing the new/create actions over here, maybe the destroy action over there, doing custom redirects... not very fun. Keep it simple: a basic, scaffolded controller is very easy to maintain and understand.
Regards, Adam _ Adam Grant Applications Integration Engineer Global Platform Application Development Sony Computer Entertainment America 10075 Barnes Canyon Road San Diego, CA 92121 [email protected] (858) 824-4939 On Tue, Jun 15, 2010 at 3:30 PM, Erik Pukinskis <[email protected]>wrote: > Hi y'all, > > I've often got multiple views on my site to the same models, and I get > confused about how to handle it RESTfully. For example, for my User > mode, I have one sign up form for regular users and one for master > gardeners. It seems like both should end up in the users table. > > If both forms post to /users then when the validations fail, they need > to go to different views, depending on which form they came from. But > there's no way to know which form they came from in the controller, > unless I track it with hidden variables, which seems messy. > > I also considered just throwing extra actions in my User controller... > /users/create_master_gardener, /users/24/update_master_gardener, > etc... but that doesn't seem very RESTful, and requires lots of > workarounds with paths and such because it's not very RAILsy either. > > Another alternative is to make a separate model (class MasterGardener > < User) with its own controller and views, but using the same table. > I'm leaning towards that, but I'm wondering if other people have best > practices for this kind of thing. It seems like it would be reasonbly > common. > > Best, > Erik > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby > -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
