Re: extra arguments in generic views
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
-~--~~~~--~~--~--~---
Re: extra arguments in generic views
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
-~--~~~~--~~--~--~---
Re: extra arguments in generic views
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
-~--~~~~--~~--~--~---
extra arguments in generic views
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 -~--~~~~--~~--~--~---
