2012-01-10 3 views
3

Я понимаю, что с помощью:Django переменных из шаблонов для просмотров - лучшая практика

... 
return render_to_response('mytemplate.html', 
locals(), context_instance=RequestContext(request)) 

в представлениях не считается хорошим кодом и что-то вроде:

... 
return render_to_response('mytemplate.html', { 
     'some_variable' : some_variable, 
     'some_list': some_list, 
}, context_instance=RequestContext(request)) 

считается лучше для его читаемости и эксплицитностей , Мне было просто любопытно, как лучше всего иметь дело с переменными, которые могут быть возвращены или не возвращены. Должен ли я явно установить их в виде следующим образом:

... 
some_variable = None 
some_variable = <some business logic> 
return render_to_response('mytemplate.html', { 
     'some_variable' : some_variable, 
     'some_list': some_list, 
}, context_instance=RequestContext(request)) 

, что приведет к более длинному коду просмотра. Или я должен проверить наличие переменных, прежде чем включать их в ответ?

Конечно, если я ничего не делаю, то я получаю:

local variable 'some_variable' referenced before assignment 

Любые предложения приветствуются.

+0

Что должно быть проблемой с вашим первым примером? – Marcin

+1

@Marcin: это ленивый, неряшливый код, который часто приводит к загрязнению контекста. Он * работает *, но считается очень неудовлетворительной практикой. –

+0

@ChrisPratt: Ленивый и неряшливый просто означает «Мне это не нравится». Является ли проблема только контекстным загрязнением в представлении с большим количеством местных жителей, которые не используются в шаблоне, или есть еще одна проблема? – Marcin

ответ

2

Средним способом является использование самого контекстного словаря в виде стека.

context = {} 
if <condition>: 
    context['cond1'] = 'foo' 

if <condition2>: 
    context['cond2'] = 'bar' 

return render_to_response('template.html', context) 

(Также обратите внимание, что с Django 1.3 вы можете использовать render(request, template, context) вместо longwinded context_instance=RequestContext вещи.)

+1

, конечно, если он использует 1.3, было бы лучше использовать представления, основанные на классах, которые, как правило, не предназначены (не предназначены для каламбуров) как устаревшие. ;) –

+0

Итак, я попробовал использовать 'render (request, template, context)'. Кажется, он работает так, как ожидалось, хотя теперь у меня много «context ['some_variable]) и нет словаря переменных в вызове' render'. Является ли это столь четким, как старый метод? –

2

Либо строить свой контекст условно, то есть:

context = { 'some_list': some_list } 

... 

if <something>: 
    context['some_variable'] = some_variable 

... 

return render_to_response('mytemplate.html', context, context_instance=RequestContext(request)  

Или использовать разумные значения по умолчанию:

return render_to_response('mytemplate.html', { 
    'some_variable' : some_variable or 'Default', 
    'some_list': some_list, 
}, context_instance=RequestContext(request)) 
+0

Мне нравится краткость второго метода, так как он не добавляет много длины кода в отличие от потери условных операторов. Может быть, есть какой-то недостаток? –

+1

На самом деле - это не работает для меня. Я до сих пор получаю 'локальную переменную 'some_variable', указанную перед ошибкой присваивания, если я устанавливаю' 'some_variable ': some_variable или None,' –

Смежные вопросы