Re: routes request

[Ben Bangert]

On Apr 2, 2006, at 11:31 AM, Kendall Clark wrote: Yeah, I'd prefer that. Method name hacks are just irreducibly ugly   IMO. But YMMV. :> I probably should have noted in my RESTController code, that it only deviates from the current BaseController __call__ by 2 lines of code. Well, yr proposal requires that many methods on some number of   classes. I don't see how that's any better; in fact, declaring a   method on a class is *more* heavyweight than calling one method   that's already defined (map.connect) a bunch of times. It's less typing because in either of our cases, we'd have all those methods. In my case there's one route, and in yours, there's a route for every method. Sure. And that's a fine approach, I just don't like method naming   conventions. Too implicit for me, and too brittle if yr trying to do   metaprogramming. I'd usually consider a convention something thats more reliable during metaprogramming, than a totally ad-hoc system with no consistence for naming. Personally, maybe I'm just greedy, but I want both options. :) I want a convention that meets the common cases, AND a way for people to not follow it if they want. I'm not saying that it doesn't make sense; I'm saying that   dispatching based on a method name hack is ugly. ;> When designing dispatch systems, its typically one of the more graceful approaches. I can't really think of any dispatch system in any framework that doesn't do something similar, while it may be ugly to you there's good reasons its the primary approach used for dispatching. But I see now that what you really dislike is introducing this   asymmetry between URL recognition and generation; and I assimilated   URL recognition to URL dispatch (mainly because that's how it seems   to a casual Pylons user who's read the docs! :>) Yes, very true. :) Can you think of another way to have a RestController, other than   foo_POST and foo_BAR? Because explicit is better than implicit; and having a naming   convention for methods that determines which one gets called is very   implicit. Yes, though naming conventions have great strengths. Surely you wouldn't want fellow developers not using the same style guide as you? Or having them all name their methods using totally different naming schemes? Conventions have great power when it comes to making systems predictable, usable, and more maintainable in the long run. I don't agree that it's similar to the convention whereby the value   in the action keyword (or default) is the exact name of the method   that's called in that controller. That's very *explicit*. Having a consistent convention for supporting HTTP verbs in actions also seems quite explicit to me. As you noted, its definitely doing some method name munging and attempting to locate one action first. I don't see how that would make anyone "ready to jump ship"? I meant that a system requiring a ton of effort to use, vs a system requiring significantly less effort to use; people would jump to the easiest system that took the least effort to get the results they wanted. Hundres of additional routes is a bit of an overstatement; in my   application, it resulted in two extra routes. That's not too bad.   There are degenerate cases, but there always are. I wasn't assuming for a degenerate case. I was assuming for the case where someone wants to implement REST web services using this technique. In which case its very common depending on how large of an API is being supported, to have dozens of actions, with various HTTP verb support each. This easily results in dozens or hundreds of methods, and would require all those corresponding Routes. I think your use-case is for lighter-weight REST stuff mainly, the subset of HTTP verbs supported by browsers (I think this was coined low-REST or something?). In your use-case, the decorator approach for the few cases you want HTTP verb toggles is probably a better solution. Well, the only thing I've claimed was ugly was having to name methods   like foo_POST. I didn't say anything else was ugly, so, you know,   relax. :> Will do. :) I didn't see any discussion of why the decorator approach isn't useful? I prefer it to renaming the methods. Then let's discuss that. :) To continue that line of though, here's the sample implementation: controller TestController(BaseController):     [EMAIL PROTECTED]rest.restrict(method='POST')      def save(self):          # do something that should only be done on POST      [EMAIL PROTECTED]rest.dispatch_on(method='POST', action='')      def edit(self):          # do this edit on GET       def _edit_post(self):          # this will be done when action is 'edit', but method is POST  So my immediate thoughts on revisiting this. The dispatch_in scheme seems like it'd be a significant amount of effort to handle multiple methods as is. So in the second case I'd instead propose:     [EMAIL PROTECTED]rest.restrict('POST')      def save(self):          # do something that should only be done on POST      [EMAIL PROTECTED]rest.dispatch_on(POST='_edit_post', DELETE='_edit_delete')      def edit(self):          # do this edit on GET       def _edit_post(self):          # this will be done when action is 'edit', but method is POST  To me, these two decorators deal with the most common cases as briefly as possible, and as explicitly as possible. Including the method= takes addition un-required effort since REST already implies that this deals with HTTP verbs IMO. How's that look? Cheers, Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss -~----------~----~----~----~------~----~------~--~---