Hi Josh,

Hope things are going well.  The thing in Rails is there are about a half dozen 
ways to handle anything. Perhaps it should be built into an authorisation gem 
with group permissions considered while redirecting validation failures - but 
my rails is getting very rusting. 

Very deep into Eneterprise MDM / Data Architecting  and Project management 
right now using SQL2008 SSIS , TestComplete, and a spattering of other ,net 
tools - no Ruby unfortunately.  Later will be into SOAP SOA type application 
integrations with a SONIC derived ESB tool. 

Best,
 Carl



---- 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

Reply via email to