On Apr 2, 2006, at 1:40 PM, Ben Bangert wrote:
> > On Apr 2, 2006, at 8:13 AM, Kendall Clark wrote: > >> Actually I don't think this change would affect URL generation *at >> all*. HTTP methods have nothing to do with URL generation, and a >> route with a post or with a get method on the same URL would generate >> the same URL. I can't see any change. > > Routes are searched to see if they can be used during URL generation. > If you have a route that requires a http_method of POST, then that > would be a valid generated URL *if* you were using url_for within a > <form action=.... method="POST"> call. It would *not* be a valid URL > to generate if you were merely making a link. This is what I mean > when I say that url_for will need to be context aware to generate > URL's. Well, my point was that the http_method bit just wouldn't impact generation at all, only dispatching. But I see below that Routes doesn't *do* dispatch, so I guess the entire suggestion is kinda moot at this point. Fair enough. I still don't see that you'd *have* to consider http_method in url_for (), but that's not really important given yr points below about dispatch/resolvers. > Odd, I consider having to write 2 routes for 2 http methods to be > quite ugly. Consider, with my approach, you could have a single > Route, dispatch to 4 different actions depending on the http method, > merely by adding a method action_GET, action_POST, etc. With your > approach, you not only have to have those 4 actions, you have to have > 3 more routes as well. Yeah, I'd prefer that. Method name hacks are just irreducibly ugly IMO. But YMMV. :> > Imagine 2 dozen different actions with 4 http method toggles each. > Your proposal requires a Route for each, that's 8 DOZEN Routes. Ouch! 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. > The controller method I mention requires none of that heavy > repetition. No, it requires me to define a *lot* of methods with a pretty awful name restriction. > recognizes a URL, and returns a dict if it does. The framework then > decides what to do with the results, and the framework dispatches. Okay, that's the bit I didn't know. It makes yr position more sensible, so thanks for filling in that gap of mine. > the Pylons resolver. This is why I proposed to extend the > BaseController, since thats *already* one of the points of dispatch. 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. > Yes, but the problem is that if its recognizing web requests, but > cannot generate web requests, there's a bit of a problem. Hmm, I guess I don't agree that that *is* a problem. But it's yr baby. :> > This is > because those Routes which are used for recognizing are the same ones > used to generate. If those Routes are now recognizing web requests, > how are they to be utilized properly to create URL's? Good question -- I don't know enough about Routes internals to have an opinion about different implementation strategies. > Given that I designed it in this way, why wouldn't it make sense to > have a RESTful controller that dispatches appropriately? I'm not saying that it doesn't make sense; I'm saying that dispatching based on a method name hack is ugly. ;> > >> But it wouldn't break generation at all. Generation just creates >> strings. Strings that don't have anything to do with HTTP methods. >> This suggestion wouldn't change generation in the slightest sense. > > Since the suggestion creates Routes that may only be valid based on > HTTP method, that affects generation because those same Routes are > searched during generation attempts. So, it seems to me you'd just leave the generation code as is; it doesn't presently check for any http_method bits, and it could go on not checking for them. 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! :>) So, it's not the best suggestion, and I'm happy not see you not implement it. Great. But I still have something of a quandary, because I do want the combination of HTTP method and Request-URI to be used to connect requests to code, and I'd prefer not to get into method name munging in order to do that in Pylons (which in just about every other way, I really love). Can you think of another way to have a RestController, other than foo_POST and foo_BAR? > >> Well, if it comes to that, I'd rather write if-switches to dispatch >> to (essentially) private actions, rather than do the method-name >> hack. Sorry, but the method-name hack is *really* ugly, IMO. ;> > > I'm not sure why you'd consider it an ugly hack. Because explicit is better than implicit; and having a naming convention for methods that determines which one gets called is very implicit. 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*. > Agreed, unless it results in so much additional work that people are > ready to jump ship. Your suggestion results in a Route for every http > method for every action. No, not at all. I said the default (no httpd_method given in the route) was that Routes would act exactly as they act now. So for most people, there would be no change at all. I don't see how that would make anyone "ready to jump ship"? > That totally violates DRY by creating huge > amounts of repetition. I appreciate that you see it that way; I don't agree. ;> > The RESTController approach does not result in > dozens or hundreds of additional Routes, 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. > This is *exactly* why the controller is called as it is. So that it > can be extended to dispatch differently within a controller based on > your needs. Why is it ugly to extend the existing action dispatch? 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. :> > I would like to have a solution that makes you happy, but I'm > extremely wary of this suggestion in its current form due to the > amount of Routing code one will need to write. Do you have any other > thoughts on how to reduce that? None whatsoever. I didn't realize it would be such a big rewrite, but perhaps I should have read the code before making a design suggestion (that's, uh, kinda not the greatest culture to encourage, I think, but that's IMO). Anyway, as I said, because my case isn't degenerate (100s of routes), I'd rather write the if-then code and do my own dispatching inside the controller than have to name a bunch of methods like _POST and _HEAD, etc. Cheers, 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 -~----------~----~----~----~------~----~------~--~---
