On Oct 4, 7:22 pm, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Mon, Oct 4, 2010 at 12:08 PM, Alex Gaynor <alex.gay...@gmail.com> wrote:
> > Given that the primary complain against the __new__ solution is that
> > it's unintuitive to Python programmers that instantiating their class
> > results in some other class, why not simply go with a more explicit
> > classmethod. Simply used as:
>
> > url("^articles/$", ArticlesView.dispatch).
>
> Interesting. So `View.dispatch` would look something like:
>
> @classmethod
> def dispatch(cls, request, *args, **kwargs):
> instance = cls()
> callback = getattr(instance, request.method.lower())
> return callback(request, *args, **kwargs)
>
> (e.g. create an instance of `cls` then call `get`/`post`/etc. on it).
>
> Other than the slight cruftyness of `dispatch`, I quite like it. Seems
Since dispatch is going to be defined on the base View class, can't we
omit it from the urlconf and have the URLresolver do:
if isinstance(view, type) and issubclass(view, View):
view = view.dispatch
> it addresses most of the issues we've found so far. Doesn't solve the
> "pass configuration into __init__" idea, but frankly I didn't think
> much of that idea in the first place.
Luke's View.configure(**kwargs) classmethod takes care of that too.
George
--
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.
