Hi Malcolm, Thanks for your input. I can certainly understand your perspective of wanting to keep the maintenance burden for Django to a minimum.
Sorry about the formatting. I didn't realize it wouldn't translate so well into the mailing list post. I'm new to the open source world (that's probably obvious). Thanks for pointing me towards dpaste, I'll be sure to use that in the future. On Jan 6, 6:46 pm, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > On Tue, 2009-01-06 at 11:01 -0800, Gabe wrote: > > Hello, > > > I really like the generic view feature of Django. It's been a handy > > way to save a lot of work. Lately though, I've been finding myself > > often wanting to display a list of objects filtered by some field. The > > documentation suggests handling this by writing a small view that > > filters the objects and then calling the generic view from within > > that. This works fine of course, but it seems that in a lot of cases > > one can end up writing a large number of small views that all simply > > display a filtered list of objects. I figured it might be helpful to > > abstract this behavior into a couple of additional generic > > views. These will automatically filter based on a keyword captured in > > the URL and a field specified in the urls.py file. I've called these > > new views object_list_field and object_list_foreign_field. > >From the description you've provided here, this sounds like a few lines > > to filter the queryset appropriately and then call an existing generic > view. That's the normal approach when you need more filtering: filter > the queryset and then pass of the existing view, perhaps after also > updating extra_context. Your code seems quite long and has wrapped > fairly horribly in the email, so my eyes were watering a bit too much to > read it all (if you really, really have to provide code of that length, > either an attachment or a link to something like dpaste would be great). > > I don't think this should be added to Django. If it scratches your itch, > then that's ideal. I think you could look at the wrapper approach for > simpler code, but that's entirely up to you for your purposes. However, > since the wrapper approach in conjunction with existing views does solve > this, it's a strong argument against needing to include it in core. > There are a million and one different use-cases that could be abstracted > in various forms. Django shouldn't include functions for all of them, > even if there's more than one user for it, since it would make the > codebase huge and adds stuff we have to maintain forever. We're working > with something that's closer to a library than a framework in many ways > (code is built on top of it, rather than within it) and so people should > be encouraged to build their enhancements externally. > > Please, please don't take this the wrong way. It always looks a bit > horrible when somebody posts a bunch of code and a problem description > (you get bonus points for at least mostly describing the problem you're > trying to solve here -- something that is often missing in proposals > that leap straight to solutions) and then some bozo like me comes along > and says they're not enthused. Remember that (a) it's only my opinion, > although that does carry some weight with some people and (b) I'm > answering from the perspective of "this is django-dev and you're asking > about including it in core", not evaluating whether the idea has any > validity at all in the wild. > > Best wishes, > Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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 -~----------~----~----~----~------~----~------~--~---
