This seems like the cleanest approach. It maps really nicely to the Rails support. Thanks!
On Wed, Jun 16, 2010 at 10:53 PM, Josh <[email protected]> wrote: > Why not create a new resource for master gardeners? The actions would > be: > > GET /master_gardeners/new > POST /master_gardeners > > The controller would pretty much look the same as your users > controller, but you could have all of your custom master gardener > views in app/views/master_gardeners. > > Josh > > On Jun 15, 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
