Re: Migrating wrapped function-based generic view to class-based generic view

So, what I've come up with is subclassing ListView and then decorating
the dispatch method like so:

def checkNodeExists():
def decorator(func):
def inner(request,*args,**kwargs):
try:
object = Node.objects.filter(section__keyword=kwargs['sect'],
published=True)[0]
except:
return render_to_response('doesntexist.html', {'identifier':
'node'}, context_instance=RequestContext(request))
if object == None:
return render_to_response('doesntexist.html', {'identifier':
'node'}, context_instance=RequestContext(request))
return func(request, *args, **kwargs)
return inner
return decorator

class NodeSectionAllView(ListView):
template_name = 'node/section_list.html'
paginate_by = 10

def get_queryset(self):
if Section.objects.get(keyword=self.kwargs['sect']).sort_reverse:
sort_order = 'created'
else:
sort_order = '-created'
return
Node.objects.select_related().filter(section__keyword=self.kwargs['sect'],
published=True).order_by(sort_order).annotate(comment_count=Count('comment'))

@method_decorator(checkNodeExists())
def dispatch(self,*args,**kwargs):
return super(NodeSectionAllView,self).dispatch(*args,**kwargs)

Now, this works, but it seems needlessly complicated, and I have some
other, more involved wrapped views that I can't figure out how to
manage with this structure.

Is this really the thing I ought to be doing here? It really seems
like having to do this reduces the utility of the generic view to the
point where I'd be better off just breaking DRY and rewriting all
custom views.

On Mar 20, 11:15 pm, saxon75 <saxo...@gmail.com> wrote:
> Hi all,
>
> I have a site built on Django 1.2 that makes use of wrapped generic
> views, and I'm wondering what the right way to migrate them to the new
> class-based views in 1.3 is.  Here's an example:
>
> urlpatterns = patterns('',
>      (r'^(?P<sect>\S+)/$', views.node_section_all),
> )
>
> def node_section_all(request, sect):
>   try:
>     object = Node.objects.filter(section__keyword=sect, published=True)
> [0]
>   except:
>     return render_to_response('doesntexist.html', {'identifier':
> 'node'}, context_instance=RequestContext(request))
>   if object == None:
>     return render_to_response('doesntexist.html', {'identifier':
> 'node'}, context_instance=RequestContext(request))
>   if Section.objects.get(keyword=sect).sort_reverse:
>     sort_order = 'created'
>   else:
>     sort_order = '-created'
>   return list_detail.object_list(
>       request,
>       queryset = Node.objects.filter(section__keyword=sect,
> published=True).order_by(sort_order),
>       template_name = 'node/section_list.html',
>       allow_empty = True,
>       paginate_by = 10,
>   )
>
> This is a fairly straightforward wrapper.  Check to see if the Section
> contains any Nodes, and if so, display a list of all of the Nodes in
> the Section.  If not, display an error page.
>
> I tried just changing the "return list_detail.object_list(" line to
> "return ListView.as_view(" and then removing the "request" and
> "allow_empty" arguments, but I end up with an AttributeError:
> 'function' object has no attribute 'status_code'
>
> So, what's the right way to migrate this sort of wrapper? Should I
> subclass ListView and try to put the wrapper functionality in there?
> How would that work?

--
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 django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.