Re: routes request

[Kendall Clark]

On Apr 2, 2006, at 3:20 PM, Ben Bangert wrote: 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. Sure, that's great. But now I have this restriction on how I name methods in *my* application code, and I don't really like that restriction. Consider a far-out case where I have a particular learning disorder that makes it hard for me to recognize upper case letters; or I have a tendency not to scan to the end of a word, etc. I've spent too much time, perhaps, in W3C standards bodies where we try to be *very* careful about restricting namespaces. And, yes, the existing system includes a naming convention, which is the simplest one possible and also the most natural: if an action lists a method name, "foo", then it's precisely *that* method that is invoked. That's also a convention, but hardly a fair comparison IMO. 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. Yes, though s/a route for every method/a route for every method the application wants to respond to/ -- so, as I said before, it's 2 extra routes in my case. But that's when I thought routing.py handled dispatch. I now realize that isn't true. 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. Well, google multimethods in Dylan. That's a dispatch system, quite elegant, and doesn't do method name restrictions. Very similar to CLOS. Yes, though naming conventions have great strengths. Surely you wouldn't want fellow developers not using the same style guide as you? No, of course not. But there's a huge difference between my imposing a naming convention on my programmers, and my framework imposing one on all of its users. That's the point of my W3C experience. Or having them all name their methods using totally different naming schemes? This is a red herring, Ben. I'm not arguing against naming conventions. I'm arguing against the one you've suggested for RestController, because it's far too implicit for my tastes. Conventions have great power when it comes to making systems predictable, usable, and more maintainable in the long run. Absolutely. Cute David-the-Rails-guy. I agree with that perspective, which is why I'm using Pylons. I just don't like *this particular* naming convention. :> 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. :) Great. :> 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. I'm not sure I understand how to connect this controller with what routing.py does. For the restrict case, what happens if some other method ends up routed to that method? Is that possible? Including the method= takes addition un-required effort since REST already implies that this deals with HTTP verbs IMO. Sorry, I couldn't parse this sentence. How's that look? I want to understand how it works with routing.py before forming an opinion. But thanks for being willing to listen to feedback! Kendall --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---