2009/9/27 Ben Hoskings <[email protected]> > > On 27/09/2009, at 12:59 PM, Daniel Bush wrote: > > > My thought was this: wouldn't it be nice not to have to create X > > number of controller files with Y number of actions in each with > > bespoke code doing pretty much the same sorts of things each time. > > Yep, standard controllers in Rails are extremely repetitive. There are > plugins around that will help with that though, e.g. > resources_controller and hammock (that one's mine, shameless plug. :) ) > > > > Instead, wouldn't it be nice to be able to specify up front which > > urls you want to expose (/path/to/action) along with their http > > method(s) and then against each such resource, define what > > parameters (name/value pairs) are required and what actions will get > > performed once those requirements are met (as well as what to do if > > they're not). > > ActionController::Routing::Routes.map already supports most of what > you're after here - i.e. specifying the accepted HTTP methods and > required parameters for a given route. >
I wasn't aware of the required parameters part. I was (obviously) aware of pretty urls which need to be mapped back to parameters and this would have to be done before being fed into the machine. The only reason I need the resources specified was to build the state machine - it would be hard to build it without this. I guess I'm trying to kill rails controllers and taking out some of the routing stuff in the process. Probably crazy. I don't even know if what I'm saying makes sense :) > > I think it's much more important to control the parameters you're > interested in than the ones you're not. That's a two-level thing - > firstly, only allowing certain attributes to be changed by the user; > secondly, sanitising the values of those changes. You can achieve the > first with attr_accessible, and the second by having sufficiently > strict validations and well-formed queries. > > Yes I can see that. After I wrote this post it occurred to me that the params machine would be encroaching on the job of validations (validates_presence_of etc). There are situations where in my controller code I'll test for a param, and if it's not there I'll redirect or respond accordingly. It's this type of logic - the sort you might get in a multi-stage form - that I wanted to nail down in a specification that gets put into a machine rather than writing more of the same code with the additional burden of testing it. Also at the back of my mind are situations where users, malicious or not, find ways to elicit unexpected behaviour from your application because, well, they do the darndest things sometimes. I guess I want to turn my app into one big state machine - not just the parameters, but encompassing the persistence/model layer as well - deranged as that may sound. There's an example that's often used of a softdrink vending machine with a state diagram - can't find the url for it now. I'm kind of picturing my app like that; users randomly come up to it and throw coins at it and madly punch buttons; and because everything is specified formally up front you can be sure it will do what you expect. You don't have to read or write more of the same code with more of the same tests each time you do this; instead you learn to write up a formal upfront specification that gets loaded into the machine - which to me seems a lot less taxing. (And I should add I have no idea how feasible that would be - I'm just running this idea up the flagpole with no real experience of using ragel) If all you're doing is updating one active record and a simple form_for it's probably overkill. My desire for this type of thing might also be a reflection on the less than optimal design choices I've made when building something in a hurry :) Appreciate your response and suggestions. Cheers, -- Daniel Bush --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~----------~----~----~----~------~----~------~--~---
