Hi Daniel, I've been waiting for an appropriate time to drop a shameless plug for StateFu (http://www.github.com/davidlee/state-fu/), and now seems like as good a time as any.
I'm interested in the idea of using it to drive (part of the) controller / session logic, but as I haven't had the need myself since I wrote it, I haven't made any attempts to tackle it. I'm happy to throw a few ideas around though, and if a sensible use case / design emerges, I'd be happy to make any accommodations required of the library to support it (e.g., providing the option to use rails' session store for persistence). As Ben pointed out though, there's no sense duplicating Rails' routes / validations, and there are numerous plugins which extend both of those which may better serve your requirements. As an aside, it's worth noting that, unlike validation rules (unfortunately - please correct me if the recent refactoring of validations has changed this), it's possible to introspect the routing table at runtime. That would make more sense to me than duplicating stuff that's already in the routes. Best case scenario, of course, is that you can find a design which aligns as closely as possible with Rails' intended use, and which makes writing complex extensions unnecessary ;) and a nice little state machine or two can often help there ... best regards, David On Sun, Sep 27, 2009 at 5:33 PM, Daniel Bush <[email protected]> wrote: > > > 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 > > > > > -- cheers, David Lee --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
