믹스인과 as_view()

A class cannot be a URL target on its own. as_view() returns a function that creates an instance and dispatches the request.

In urls, you call the class with as_view(), never the bare class. That callable is what Django actually routes to.

You can override class attributes right in the URL by passing them to as_view(). Handy for small tweaks without subclassing.

A mixin is a small class that adds one focused behavior. You combine mixins to compose a view from reusable parts.

A mixin is not used alone. It only makes sense when combined with a real view class through multiple inheritance.

LoginRequiredMixin blocks anonymous users and redirects them to login. Add it to any CBV that needs a signed-in user.

List the mixin first, then the view. Python resolves methods left to right, so the mixin can act before the base view runs.

Generic CBVs already mix in ContextMixin, which is why get_context_data exists. Mixins are everywhere in Django.

You can stack multiple mixins for several behaviors at once, like requiring login and adding permissions, in one class.

Good mixins do one thing. Small, focused mixins stay easy to reuse and combine without surprising conflicts.

Putting it together, a generic CBV is really a stack of mixins plus a base view, all wired into urls by as_view().

Why must you call as_view() in your URL configuration?

You wrapped up CBVs: as_view() turns a class into a routable callable, and mixins compose small reusable behaviors, order-sensitive, into one view. 🧩