I agree with George, and would like to not have to write the dispatch
out every time, but my only concern is how confusing an implicit
dispatch would be for developers first using the new class-based Views
system. As long as it was made abundantly clear via the docs what
exactly is happening when your route a url to a View class it really
shouldn't be an issue.
My apologies if it has already been brought up, but I'd also like to
propose that a default context_instance be added as a self variable to
the View class, if for nothing else than to avoid having to write
context_instance=RequestContext(request) in nearly every return
statement, or requiring every one of my apps to be dependent on
something like django-annoying for its render_to() decorator.
On Oct 4, 3:21 pm, George Sakkis <george.sak...@gmail.com> wrote:
> 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.
