Messing with the framework today, I remembered that controller actions currently only respond to GET. Which is not a terribly complex problem to solve from a framework perspective - I can simply add a Sinatra handler for the other verbs that routes to the controller actions the same way that GET does.
The question is, should I?
If I do this, then all controller actions will respond to all HTTP verbs. Which is not the typical way of working with one of these frameworks. Rails routing makes each routing action very specific to a given verb. In MVC.net you annotate the controller methods with the particular verb.
We're really talking about a filter here. What I don't want is the framework user to have to build in boilerplate code for each controller that filters out verbs that they don't want to deal with for a given method.
There's probably some nifty Ruby language feature I could use to filter these methods. But that would be adding configuration, I think. Also, the ways I can think of do build this filter would be a little bit fragile.
What I'm actually thinking about is building the filter into the name. If the action function starts with "get_", then it's a get method. If it starts with "post_" then it's a post method. If it doesn't start with a verb, then it would handle any verb. The url for the action would not include the verb, of course.
Interestingly, that would actually allow overloads of a given action - you could easily have a put version and a get version, which would normally not be allowed in Ruby.
The only real downside I can think of is that now you could not have an action that began with a verb. There's probably a way around it (explicit routing would be one option) but I have trouble thinking of a reason why you'd need to start an action with a verb.
I think I like this plan.
I also need to remember ... the thing that I forgot. crap.
No comments:
Post a Comment