Спасибо большое за советы. На выходных займусь плотным перепроектированием :) Попробую сделать иерархию и/или переписать часть на cbv и посмотреть что получится.
—–
оффтопик
JOHN_16, esp рулез!)
Полная версия: Подойдет ли django для проекта
def foo(request, param): instance=get_object_or_404(MyModel, pk=param) if request.method='POST': form=MyForm(request.POST) if form.is_valid: form.save() return HttpResponseRedirect(reverse( 'name' )) else: return render_to_response('template.html', {'object':instance, 'form':form}) else: form=MyForm() return render_to_response('template.html', {'object':instance, 'form':form})
пишется вот так:
def foo(request, param): instance = get_object_or_404(MyModel, pk=param) form = MyForm(request.POST or None) if request.method == 'POST' and form.is_valid(): form.save() return redirect('name') return render('template.html', {'object':instance, 'form':form})
что кстати даже короче получилось (7 строк vs 8 строк), чем с использованием специально заточенного generic view. Код можно еще чуть сократить (выкинуть проверку request.method == ‘POST’, если CSRF-защита везде используется). Ну и в джанге классические представления-функции не депрекнут, этого уж точно можно не бояться.
kmike, Вы сейчас собираетесь применить прием из набора шаблонов годного троллига?
Не стоит. Код, который я привел взят прямиком из Django-book. Вот отсюда
Вот он.
Как оно “вот так пишется правильно” объясните авторам фреймворка.
Что есть сказать по существу обсуждаемого сабжа не пытаясь кинуть каку в оппонента?
А то ведь в эту игру можно играть вдвоем, например, “Да ты просто не осилил CBV!
”
Не стоит. Код, который я привел взят прямиком из Django-book. Вот отсюда
Вот он.
def contact(request): if request.method == 'POST': form = ContactForm(request.POST) if form.is_valid(): cd = form.cleaned_data send_mail( cd['subject'], cd['message'], cd.get('email', 'noreply@example.com'), ['siteowner@example.com'], ) return HttpResponseRedirect('/contact/thanks/') else: form = ContactForm() return render_to_response('contact_form.html', {'form': form})
Как оно “вот так пишется правильно” объясните авторам фреймворка.
Что есть сказать по существу обсуждаемого сабжа не пытаясь кинуть каку в оппонента?
А то ведь в эту игру можно играть вдвоем, например, “Да ты просто не осилил CBV!
”
Я не понял ваших претензий ко мне (и удивлен тону беседы, кстати). В djangobook - хороший учебный материал, чтоб в голове все по полочкам разложилось, + книжка довольно старая, особенно по меркам IT. Вьюху contact в реальном проекте лучше написать так:
Конструктивной беседы не выходит, так что ладно, не буду больше докучать.
def contact(request): form = ContactForm(request.POST or None) if form.is_valid(): form.send_mail() return redirect("thanks") return render('contact_form.html', {'form': form})
Конструктивной беседы не выходит, так что ладно, не буду больше докучать.
kmike
пишется вот так:
def foo(request, param):
instance = get_object_or_404(MyModel, pk=param)
form = MyForm(request.POST or None)
if request.method == ‘POST’ and form.is_valid():
form.save()
return redirect('name')
return render('template.html', {'object':instance, ‘form’:form})
Пишется вот так:
class MyView(UpdateView): template_name = 'template.html' form_class = MyForm
kmikedef contact(request): form = ContactForm(request.POST or None) if form.is_valid(): form.send_mail() return redirect("thanks") return render('contact_form.html', {'form': form})
class MyContactView(EmailView): form_class = ContactForm template_name = 'contact_form.html'
kmike, в целом, мне понятны ваши аргументы. С некоторыми я согласен.
Но есть нюансы. Вот смотрите:
Ведь описываемая вами ситуация случилась (и случается) из-за отсутствия документации - раз, плохо настроенного процесса тестирования и коммита - два.
Давайте разберемся.
Одно дело, кода нужно разобраться с логикой модуля системы, другое - с логикой работы конкретного алгоритма внутри функции/метода.
Для первого нужна документация типа UML, для второго читаемый код и комментарии.
Когда разработчику нужно понять логику работы уже существующего модуля?
Несколько примеров:
1. Он работает с этим модулем впервые.
2. Он вернулся к нему после длительного перерыва.
3. Идет изменение архитектуры.
4. Обнаружена ошибка в бизнес-логике или архитектуре.
Очевидно, в этом случае, использовать диаграммы и погружаться в код в нужных местах удобнее, чем читать код, выстраивая логику работы модуля. Прямой анализ эффективнее обратного, если вы не Шерлок Холмс, умеющий составить общую картинку из большого количества отдельных кусочков.
Когда разработчику нужно понять логику работы существующего кода?
Примеры:
1. Нужна доработка локальной логики.
2. Найдена ошибка в коде. То, что ошибка именно в коде, а не модуле, известно из отчета тестера или результатов теста.
3. Знакомство с кодом в уже знакомой в целом системе.
4. Реализация новых функций, расширение возможностей конкретной функции/класса.
Чтение кода, комментариев и сверка с документацией модуля будет более эффективным и быстрым.
Имеют значение размер и читаемость кода, внятные inline-комментарии по существу, понятные комментарии ссылающиеся на глобальную документацию для сверки алгоритма.
Мы пришли к понимаю, что разные задачи выдвигают разные требования к коду.
Учитывая это, напрашивается вывод о бесполезности нецелевого использования кода как инструмента для изучения проекта и трате напрасных усилий в том месте, где от этого нет пользы проекту.
При этом польза разработчику вполне может иметь место, например, для самообразования или желания вникнуть.
На момент, касающийся тестирования и коммита кода у меня уже не осталось времени.
Коротко: тестирование и настройка CI для больших проектов делает ненужным большую часть описываемых вами задач, т.к. они решаются на другом уровне автоматизированным способом.
А для малых проектов CBV часто даже вредны, например, из-за естественной для них “многословности”.
Т.е. это чистой воды over engineering, соответственно - плохой выбор.
Тезисно, мое мнение в дополнение к статье по ссылке:
1. Использовать нужно и то, и другое.
2. Важно знать преимущества и недостатки (реально это возможно только при наличии опыта).
3. Выбирать подход нужно, исходя из нескольких критериев, например: сложность бизнес-логики, объем проекта и кода, план поддержки после сдачи проекта.
Но есть нюансы. Вот смотрите:
kmikeВам не кажется, что вы описываете последствия проблемы выше уровнем, выбрав CBV козлом отпущения?
Мне не нравятся generic views на CBV, т.к. для того, чтоб понять, что происходит во вьюхе, нужно прочитать код нескольких миксинов и в голове построить, что в каком порядке выполняется (особенно если есть вызовы super()), с учетом MRO. С вьюхой на функциях “поток выполнения” читается сразу, а с классом он то “заныривает” куда-то во внутренности джанги, то “выныривает” оттуда.
Ведь описываемая вами ситуация случилась (и случается) из-за отсутствия документации - раз, плохо настроенного процесса тестирования и коммита - два.
Давайте разберемся.
Одно дело, кода нужно разобраться с логикой модуля системы, другое - с логикой работы конкретного алгоритма внутри функции/метода.
Для первого нужна документация типа UML, для второго читаемый код и комментарии.
Когда разработчику нужно понять логику работы уже существующего модуля?
Несколько примеров:
1. Он работает с этим модулем впервые.
2. Он вернулся к нему после длительного перерыва.
3. Идет изменение архитектуры.
4. Обнаружена ошибка в бизнес-логике или архитектуре.
Очевидно, в этом случае, использовать диаграммы и погружаться в код в нужных местах удобнее, чем читать код, выстраивая логику работы модуля. Прямой анализ эффективнее обратного, если вы не Шерлок Холмс, умеющий составить общую картинку из большого количества отдельных кусочков.
Когда разработчику нужно понять логику работы существующего кода?
Примеры:
1. Нужна доработка локальной логики.
2. Найдена ошибка в коде. То, что ошибка именно в коде, а не модуле, известно из отчета тестера или результатов теста.
3. Знакомство с кодом в уже знакомой в целом системе.
4. Реализация новых функций, расширение возможностей конкретной функции/класса.
Чтение кода, комментариев и сверка с документацией модуля будет более эффективным и быстрым.
Имеют значение размер и читаемость кода, внятные inline-комментарии по существу, понятные комментарии ссылающиеся на глобальную документацию для сверки алгоритма.
Мы пришли к понимаю, что разные задачи выдвигают разные требования к коду.
Учитывая это, напрашивается вывод о бесполезности нецелевого использования кода как инструмента для изучения проекта и трате напрасных усилий в том месте, где от этого нет пользы проекту.
При этом польза разработчику вполне может иметь место, например, для самообразования или желания вникнуть.
На момент, касающийся тестирования и коммита кода у меня уже не осталось времени.
Коротко: тестирование и настройка CI для больших проектов делает ненужным большую часть описываемых вами задач, т.к. они решаются на другом уровне автоматизированным способом.
А для малых проектов CBV часто даже вредны, например, из-за естественной для них “многословности”.
Т.е. это чистой воды over engineering, соответственно - плохой выбор.
kmikeАд есть везде. Вот мнение, с которым я во многом согласен. Тут есть и пример заныривания для view-функций, и пример “ада” даже не из документации,- из исходников Джанги ;)
Вот это разве не ад (пример из документации)?
Тезисно, мое мнение в дополнение к статье по ссылке:
1. Использовать нужно и то, и другое.
2. Важно знать преимущества и недостатки (реально это возможно только при наличии опыта).
3. Выбирать подход нужно, исходя из нескольких критериев, например: сложность бизнес-логики, объем проекта и кода, план поддержки после сдачи проекта.
Помоему jquery было не совсем удачным выбором для ajax реализации. Можно же dajax заюзать было, оно вроде поудобней.
Вы в курсе, что django-dajax использует jQuery?
Кроме jQuery на клиенте могут использоваться и другие фреймворки.
Чуть удобнее на сервере, но лишний код на клиенте.
Вообще, на серверной стороне ваш AJAX запрос ничем не отличается от обычного HTTP-запроса.
В чем проблема то?
ЗЫ
django-dajax чем-то на Corba смахивает :)
Кроме jQuery на клиенте могут использоваться и другие фреймворки.
Чуть удобнее на сервере, но лишний код на клиенте.
Вообще, на серверной стороне ваш AJAX запрос ничем не отличается от обычного HTTP-запроса.
В чем проблема то?
ЗЫ
django-dajax чем-то на Corba смахивает :)
Проблема в том, что с серьезными проектами дела не имел, все сайты-визитки. Ну и опыта написания аякс приложений нет вообще.