On 10 December 2010 22:47, Ted Tieken <ted.tie...@gmail.com> wrote:
> Class based generic views still have the major drawbacks of the
> previous version.  They are a more powerful, more complicated version,
> but they're still a red-herring.

Can you elaborate on this ? Taking your original concerns:

> My biggest complaints are:
> * You don't end up saving many keystrokes unless you have 3 or more
> views that are going to use the same info_dict.

That sounds like a general rule for all things "generic" - if you
don't have similar problems, you must have different solutions. If you
have a couple of views that are almost similar, you can create a
common base class and make final tweaks as parameters to the as_view()
function.

* They can't be tweaked or changed much before you have to move the
code to the views file, destroying the keystroke savings.

Class-based views are designed to solve exactly this problem. By
creating a subclass you can customize the parts you want and reuse
others. If the current API doesn't suite your needs, please do say.
I'm not going to argue it's perfect, but it surely is the right
direction :)

* Second syntax for doing the same thing makes Django harder to learn.

I don't understand this one. Is this targeted at old generic views or
the new views ?

> On Fri, Dec 10, 2010 at 9:37 AM, Rainy <andrei....@gmail.com> wrote:
>>
>> Is there a doc somewhere that details what the limitations are? How
>> do you tell if some task is definitely too much for new generic views?
>> I'm not using 1.3 yet and generally what I've been doing recently
>> doesn't seem to fit generic views but eventually I might use them.

What kind of limitations you have in mind ?

Generic views usually can't solve your task out-of-the-box - this is
where the need for customization comes from. Old generic views let you
only customize small parts of variables. Class-based views take a
different approach - every time there is a (substantial) decision to
make, call a method on self. This way subclasses can redefine the way
that decision is made without the need to copy all of the view's code.

-- 
Łukasz Rekucki

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Reply via email to