I guess I didn't explain myself well enough. 90% of the views on my site don't need anything special being passed to a wrapper view function or anything. In my "info_dict" I typically define only the items that stretch across the generic views of the entire model, typically queryset and date_field. But then typically I have a object_list generic view as well, which doesn't like the argument date_field, so I need to pass just one parameter to it queryset, but I could want to add a paginate_by argument, which needs to passed to some of the date_based views too but not all of them.
The arguments needed change in the generic views which means that I either need to define an extra 'info_dict' or define the arguments inline. Not difficult, but when you are looking at a list of 10 urls and maybe 2 need maybe one extra argument and another 3 don't want that argument it seems silly to have to customize for each when 50% of the time the arguments are the same. So I tinkered with the internals of generic views and added **kwargs at the end of each. That's the discussion I wanted to have. I know I can get around this, but sometimes I am stubborn especially when I don't really see a downside to the generic objects receiving extra arguments. Maybe I am just being difficult. On Thu, Mar 27, 2008 at 11:39 AM, Erik Vorhes <[EMAIL PROTECTED]> wrote: > > This should help: > > > http://www.b-list.org/weblog/2006/nov/16/django-tips-get-most-out-generic-views/ > > Say you've got this in "yourproj.yourapp.views" (assuming there's a > ForeignKey on Thing2): > > from django.views.generic import date_based > from yourproj.yourapp.models import Thing1 > from yourproj.yourotherapp.models import Thing2 > > def your_object_detail_view(request, year, month, day, slug): > q1 = Thing1.objects.all() > q2 = Thing2.objects.filter(thing1__slug=slug, public=True) > params = { > 'queryset': q1, > 'date_field': 'date_field', > 'year': year, > 'month': month, > 'day': day, > 'slug': slug, > 'extra_context': { > 'sub_thingies': q2 > } > } > return date_based.object_detail(request, **params) > > This would allow you to pass any related & public stuff from Thing2 > into a detail view for Thing1 (assuming your slug_field is called > 'slug' and your date_field is called 'date_field). > > Hope that helps! > > > > > On Thu, Mar 27, 2008 at 10:09 AM, Michael Newman <[EMAIL PROTECTED]> wrote: > > > > I was just messing around with my sites urlconf to keep it organized > > and manage clean things up a bit. I make use of generic views quite a > > bit and they really save me a lot of time. One of the things that I > > noticed however as I was trying to combine a lot of "info_dicts" was > > that the generic views (except archive_day) don't accept extra key > > word arguments. > > > > I realize that passing extra arguments to a function is less than > > ideal, but sometimes it is nice to have one "info_dict" that defines > > paginate, date_field, slug, etc. for model views. Obviously this > > caused problems with a lot of the generic view functions, but that > > easily rectified by adding **kwargs as an extra argument. > > > > I don't know if this is something that would be right to have in the > > default views, but I was interested in starting a conversation to the > > pros and cons to this approach. > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
