On Fri, Oct 15, 2010 at 8:30 PM, David De La Harpe Golden <david.delaharpe.gol...@ichec.ie> wrote: > On 15/10/10 07:11, Russell Keith-Magee wrote: > >> We're happy to entertain design suggestions, but only if they're >> enlightened by the extensive discussions that have proceeded the >> implementation that we have. You're free to say "as_view() sucks", but >> unless you are proposing an *specific* alternative that isn't fraught >> with the problems that led us to that solution in the first place, >> you're not going to get much traction. >> > > I find the use of an .as_view() direct classmethod vaguely peculiar > given classmethods have been avoided elsewhere in django in favor of the > flexible "Manager" pattern? > > Why not have views class property on the class by analogy with the > "objects" property, that the resolver calls a "get" method on with the > params to get a view instance?
Why not? Because of decoration. If the URL resolver needs to manipulate the thing that is defined in a URL pattern, that means you can't use decorators in the URL pattern. See the wiki for more details [1]. To try and head this off at the pass: when I said any feedback is welcome, I was really referring to the organization of the class-based views themselves, not the dispatch mechanism. There's been a *lot* of thought put into the dispatch mechanism -- read the archives if you don't believe me -- and we've come to the conclusion that as_view() is the best of a less-than-ideal set of solutions. If you *really* think you've discovered the perfect solution that nobody else has proposed: 1) No, really, you haven't. Check the wiki archives, and I'll give good odds that *someone* has proposed your idea before, and the problems that exist with the idea have been explored. 2) If your specific idea hasn't been suggested, it can probably be ruled out for one of the clearly documented reasons in the wiki, so you'd better be *really* certain that it addresses the issues that are described in the wiki. 3) You'd better come armed with a demonstration implementation that, at the very least, meets all the use cases described by Luke Plant's experimentation suite [2]. I'm sorry if this seems rude or curt, but the last thing we need at this point is another round of attempted bikeshedding on dispatch mechanisms. This isn't a trivial problem. A lot of thought has gone into the solution that is on the table. If you're going to enter the discussion at this late stage, the very least you can do is give the rest of the community the courtesy of coming up to speed with the debate so we don't have to rehash old ground yet again. [1] http://code.djangoproject.com/wiki/ClassBasedViews [2] http://bitbucket.org/spookylukey/django-class-views-experiments/src/tip/ Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
