very noob : DRY violation in views.py

[Osiaq]

VIEWS:

def services(request):
property = Property.objects.all().order_by('name')[:4]
city = City.objects.all()
category=PropertyCategory.objects.all()
status=PropertyStatus.objects.all()
return render_to_response('website/services.html',{'property':
property, 'city':city,'category':category,'status':status})

def profile(request):
property = Property.objects.all().order_by('name')[:4]
city = City.objects.all()
category=PropertyCategory.objects.all()
status=PropertyStatus.objects.all()
return render_to_response('website/profile.html',{'property':
property, 'city':city,'category':category,'status':status})

How to define "property" just once and use it in many defs?
Thanks

[Itay Donenhirsch]

i'm quite a noob myself but my best guess is to use context processor,
see http://stackoverflow.com/questions/557460/django-having-middleware-communicate-with-views-templates

> --
>
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>
>
>

[Brian Victor]

If you're looking to avoid repetition of more than just "property,"
there are a couple of simple refactorings you could use without having
to resort to context processors.

def get_standard_context():
return {
'property': Property.objects.all().order_by('name')[:4],
'city': City.objects.all(),
'category': PropertyCategory.objects.all(),
'status': PropertyStatus.objects.all(),
}

def services(request):
return render_to_response('website/services.html', get_standard_context())

def profile(request):
return render_to_response('website/profile.html', get_standard_context())

Or, you could move render_to_response into the refactored function:

def my_render_to_response(template):

property = Property.objects.all().order_by('name')[:4]
city = City.objects.all()
category=PropertyCategory.objects.all()
status=PropertyStatus.objects.all()

return render_to_response(template,{'property': property, 'city':city,'category':category,'status':status})

def services(request):
return my_render_to_response('website/services.html')

def profile(request):
return my_render_to_response('website/profile.html')

--
Brian

[Osiaq]

@Brian
Thank you very much for clear explanation!
I gives me much more than enormous pages of manuals.

@Itay
Thanks for suggestion, but refractoring inside views.py looks more
clear to manage.
I wasn't also sure, if such simple solution requires middleware
involved. I will probably have
more than only this one example, so I was looking for as simple
solution as it's possible.

Thanks to both of you.

[Ethan Jucovy]

Lately I have really liked using custom template tags for these sorts of queries.

Once you get the hang of writing them, it's very quick to build a little library of queries in custom tags for your application.  These are *very* convenient to use because you don't have to modify views.py -- or any Python code -- to use them in template in your entire project, e.g.

{{{
{% load my_custom_tags %}
{% get_all_properties limit 4 as all_properties %}

Viewing the first four properties:
{{all_properties.0.name}}
[...]
}}}

They also make reusable apps much more reusable, since you can use the templatetags provided to integrate their data into your project.  And you can even extend a reusable app's "template-ready query library" by defining your own templatetags that use its models .. it's very powerful and flexible.

-Ethan

[Osiaq]

Just one word: wow!
Yes, definitely I'm gonna dig into it :)

On Dec 20, 2:34 am, Ethan Jucovy <ethan.juc...@gmail.com> wrote:
> Lately I have really liked using custom template tags for these sorts of
> queries.
>
> Once you get the hang of writing them, it's very quick to build a little
> library of queries in custom tags for your application.  These are *very*
> convenient to use because you don't have to modify views.py -- or any Python
> code -- to use them in template in your entire project, e.g.
>
> {{{
> {% load my_custom_tags %}
> {% get_all_properties limit 4 as all_properties %}
>
> Viewing the first four properties:
> {{all_properties.0.name}}
> [...]
>
> }}}
>
> They also make reusable apps much more reusable, since you can use the
> templatetags provided to integrate their data into your project.  And you
> can even extend a reusable app's "template-ready query library" by defining
> your own templatetags that use its models .. it's very powerful and
> flexible.
>
> -Ethan
>

> On Sat, Dec 19, 2009 at 6:17 PM, Osiaq <osiaq.net...@gmail.com> wrote:
> > @Brian
> > Thank you very much for clear explanation!
> > I gives me much more than enormous pages of manuals.
>
> > @Itay
> > Thanks for suggestion, but refractoring inside views.py looks more
> > clear to manage.
> > I wasn't also sure, if such simple solution requires middleware
> > involved. I will probably have
> > more than only this one example, so I was looking for as simple
> > solution as it's possible.
>
> > Thanks to both of you.
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > django-users...@googlegroups.com<django-users%2Bunsu...@googlegroups.com>