That's probably a discussion for the django-developers list, http://groups.google.com/group/django-developers . Unless those changes happen, you're likely best off creating multiple dictionaries or extending them in the individual url dict.
On Thu, Mar 27, 2008 at 12:49 PM, Michael <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
