On Mon, Jun 15, 2009 at 1:16 AM, Matt Jones<[email protected]> wrote: > > > On Jun 14, 2009, at 11:42 PM, Rick DeNatale wrote: >> Now in googling about, I discover that there's a railsdav plugin whose >> usage I don't entirely understand. >> >> One thing it does is to patch ActionController::AbstractRequest (or >> ActionController::Request in Rails 2.3) to add the webdav methods to >> the HTTP_METHODS constant. It's not clear whether this is enough to >> allow routes to use the new methods as condititions or not. >> > > Unless something has changed since 2.2.2, adding to HTTP_METHODS is > pretty much all that you need - see this article for an example: > > http://rails.learnhub.com/lesson/2318-dealing-with-microsoft-office-protocol-discovery-in-rails > > I used this after about the tenth exception notifier message showed up > in my mailbox on a Rails 2.2.2 app.
Actually that example is monkey-patching ActionController::Routing::HTTP_METHODS, while the railsdav plugin monkey originally monkey patched ActionController::AbstractRequest::HTTP_METHODS, and was patched by someone in a github fork to monkey patch ActionController::Request::HTTP_METHODS because of a change in the class name. So looking at Rails 2.2.2 there are two constants named HTTP_METHODS. The one in ActionController::Routing is used to determine whether a method is valid when either setting up or recognizing routes. The one in ActionController::AbstractRequest is used to validate the method in ActionController::AbstractRequest.request_method In Rails 2.3 there are still those two HTTP_METHODS constants, although as I noted ActionController::AbstractRequest is now ActionController::Request, and there is now a THIRD Rack::MethodsOverride::HTTP_METHODS constant which is used in the rack middleware which Rails now uses to turn a post with a method override to another type of request to validate the overriding method. That's the kind of thing which makes me think that there should be one place where the valid methods are defined consolidating the two/three which are current, and a defined api for adding additional methods, perhaps in environment.rb I'd love to hear what the guys deep into the Rails 3 effort have to say about this, since as I understand it, the goal is to define stable APIs for extensions. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
