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? class BlahViewDirector(Director): # director:view::manager:model ... class Blah(View): views = BlahDirector() # or left out for a "default director" ... url(r'blah/(?P<key>\d+)/$'), views.Blah, name="blah") url(r'blah/(?P<key>\d+)/glonk/$'), views.Blah, glonk=True) => Blah.views.get(key=key) and Blah.views.get(key=key, glonk=True) to get a Blah instance that's perhaps itself a callable expecting a request, or has GET/POST/PUT etc. methods. Wouldn't that be rather more in keeping with the structure of the rest of the framework? A Director could be simple or sophisticated (e.g. caching and reusing instances thread-safely), much like a Manager. -- 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.
