Re: routes request

[Ben Bangert]

On Apr 2, 2006, at 12:43 PM, Kendall Clark wrote: 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. :> Ah, ok. Makes sense.     [EMAIL PROTECTED]rest.dispatch_on(POST='_edit_post', DELETE='_edit_delete')      def edit(self):          # do this edit on GET  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? These are merely decorators on the actions being called in the Controller. They have no tie-in to routing.py at all. The dispatch_on is essentially just wrapping up the if/then logic you were talking about earlier into a generic controller. Routes works as normal, and if you want to change the action depending on an HTTP verb, you put that in the decorator. In the case of restrict, it would throw a 404. If you wanted instead of restricting, to have something else happen, you'd use dispatch_on decorator. Your example would come out: map.connect("instances", "kb/instances", controller="kb", action="") class KbController(BaseController):    [EMAIL PROTECTED](POST='make_instance')     def instances(self):         # Handles the get     def make_instance(self):         # Handles the post So Routes continues to handle just the URL recognition, and you alter action dispatching using the decorator. Personally, just looking at it... I like it. It has the explictness of action mapping you like, and it doesn't require me to be flipping to routing.py to see where things are going, since the decorator makes it very clear what will change the action dispatch. 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. I meant that having keyword arguments like "method=" were not needed. So the second example left them out, and used the more concise syntax to make it easier to split dispatching depending on HTTP verb. But thanks for being willing to listen to feedback! Absolutely, I want to continue to add useful functionality to Pylons. REST is definitely something people want, so I believe the next step is to have a solid way to handle it. So overall with this approach, we're only one away from what I think would be your ideal situation. That is, you're still stuck with a "default" action regardless of HTTP verb. Or does this cover your situation in a satisfactory manner? 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 -~----------~----~----~----~------~----~------~--~---