Generic Views - do you use them?
Ted
coding?
The more I code in django the less I find generic views to be useful
shortcuts (direct to template being the exception).
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.
* They can't be tweaked or changed much before you have to move the
code to the views file, destroying the keystroke savings.
* Second syntax for doing the same thing makes Django harder to
learn.
Am I alone on this?
I've thought about it and i think there is a better way. I want to
see if there are others in the community who aren't in love with
generic views before I develop the alternate approach.
I'm not trying to start a flame war.
ringemup
I don't use them either for much the same reasons, and because I often
end up using custom render_to_response shortcuts that set common
context or handle custom template loading. Although the new class-
based views may make them more customizable.
I don't see much need for an alternative, though (I'm perfectly happy
writing my own views), and don't know what sort of alternate approach
you're suggesting.
derek
interested to see an alternative also because it might improve my
understanding.
SivaTumma
"code by own" the functionality provided by them.
We would have better control + peace of mind. Frameworks unnecessarily
bring hassle, irritation for a programmer.
Shawn Milochik
> I have not really understood when and why they are needed; I would be
> interested to see an alternative also because it might improve my
> understanding.
>
I've never used them before, and always avoided looking into them
because I thought they were some dumbed-down way for newbies to avoid
writing views. Also, the views in my company's application tend to be
fairly complex and I was certain that they'd be too limiting.
However, I was just reading the 1.3 alpha release notes and followed this link:
http://docs.djangoproject.com/en/dev/topics/class-based-views/
It seems that they could be really useful in nearly any application
(at least the ListView), even for experienced Django developers. In
any case, it's an interesting read and I recommend having a look.
Shawn
Rainy
as I usually work on open-ended projects that would grow
out of generic views soon even if they may be possible to
use at first.
I think there's a problem with the way generic views are
introduced in documentation. I've actually tutored someone
on use of Django and we ran into a problem that they
started using generic views and kept asking me how to
do this or that with them and they could do almost nothing
they wanted. I could see it was frustrating for the student.
I think the docs should either completely move generic
views into some optional section or there should be an
extremely clear and explicit walkthrough of their limits
and a disclaimer that you shouldn't use them unless
you're pretty sure they can do everything you need your
app to do.
I think I've seen a web talk by Adrian where he said
generic views were introduced for designers (i.e.
non-programmers) to make it possible to make a
useful app with no programming at all. I don't have
a problem with that at all. The main issue is how the docs
approach generic views..
Łukasz Rekucki
http://docs.djangoproject.com/en/dev/topics/class-based-views/
They're much more flexible.
> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>
>
--
Łukasz Rekucki
Rainy
> You should try the new class-based generic views:http://docs.djangoproject.com/en/dev/topics/class-based-views/
>
> They're much more flexible.
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.
Ted Tieken
previous version. They are a more powerful, more complicated version,
but they're still a red-herring.
Ted
Łukasz Rekucki
> 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 <andre...@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
Rainy
On Dec 10, 5:22 pm, Łukasz Rekucki <lreku...@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 ?
look kind of nice. I think calling them generic views may be a bit
misleading at this point because a lot of people probably will end
up using them for all complex views while leaving functions for
simpler ones. In other words, you might use predefined generics for
the most basic views, then use functions for slightly more complicated
ones and custom generic for everything else. -rainy