I can't say I'm a big fan of this proposal, personally. While I can understand where you're coming from, it smells a bit too much like J2EE's doGet/doPost stuff for my taste.
On a more objective note, though, would that mean that every urlpattern would require an HTTP method, or could it be ignored (with GET presumably implied)? If it can be ignored, how would the resolver tell the difference between an HTTP method string and a URL regex string? (I think I have an answer for this, but it's worth asking anyway.) And if the method is in fact required in all cases, I think this would add way too much added complexity for the common case. Most people only use GET and POST, and most of their URLs are going to be GET only. On top of that, I expect most GET/POST views are forms, where it would make sense to share logic for form generation, template selection, etc. Expecting people to separate those into two separate views seems unnecessarily complex. And yes, I do realize that your constants proposal does alleviate some of these problems. For instance, you mention having HTTP_ALL, which, if used as a default, would provide existing functionality without change. Also, by using constants, the values could be numbers, which could then be OR'd together (ie, HTTP_GET | HTTP_POST), and this would also provide a means of differentiating between the required HTTP method(s) and the regex string. These things do help somewhat, but they add a great deal of complexity where I don't think it's merited. That said, I think there are probably others out there like you who would want this, and there's actually nothing stopping you from releasing it as a separate app, or even a snippet. Essentially, you'd just write a replacement for the existing url resolvers, probably subclassing the existing ones to minimize new code. Then in your urls.py, you import your own rather than the Django ones. If nothing else, this would give the core developers proof of what you're talking about, it would give other developers a chance to try it out and see if they like it any better, it would give you some valuable feedback on the proposal in case it needs tweaking, and it would give you a chance to get your feet wet on hacking a bit on things related to Django internals. If you'd like to go that route, let me know and I'd be willing to help you out with it. -Gul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
