Python-сообщество

Спасибо большое за советы. На выходных займусь плотным перепроектированием :) Попробую сделать иерархию и/или переписать часть на cbv и посмотреть что получится.
—–
оффтопик
JOHN_16, esp рулез!)

пишется вот так:


что кстати даже короче получилось (7 строк vs 8 строк), чем с использованием специально заточенного generic view. Код можно еще чуть сократить (выкинуть проверку request.method == ‘POST’, если CSRF-защита везде используется). Ну и в джанге классические представления-функции не депрекнут, этого уж точно можно не бояться.

kmike, Вы сейчас собираетесь применить прием из набора шаблонов годного троллига?
Не стоит. Код, который я привел взят прямиком из Django-book. Вот отсюда
Вот он.

Как оно “вот так пишется правильно” объясните авторам фреймворка.
Что есть сказать по существу обсуждаемого сабжа не пытаясь кинуть каку в оппонента?
А то ведь в эту игру можно играть вдвоем, например, “Да ты просто не осилил CBV! ”

Отредактировано FishHook (Ноя. 16, 2012 08:23:10)

Я не понял ваших претензий ко мне (и удивлен тону беседы, кстати). В djangobook - хороший учебный материал, чтоб в голове все по полочкам разложилось, + книжка довольно старая, особенно по меркам IT. Вьюху contact в реальном проекте лучше написать так:

Конструктивной беседы не выходит, так что ладно, не буду больше докучать.

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})

Пишется вот так:

Отредактировано zheromo (Ноя. 16, 2012 15:35:29)

kmike

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})

Отредактировано zheromo (Ноя. 16, 2012 15:41:03)

kmike, в целом, мне понятны ваши аргументы. С некоторыми я согласен.
Но есть нюансы. Вот смотрите:

kmike
Мне не нравятся generic views на CBV, т.к. для того, чтоб понять, что происходит во вьюхе, нужно прочитать код нескольких миксинов и в голове построить, что в каком порядке выполняется (особенно если есть вызовы super()), с учетом MRO. С вьюхой на функциях “поток выполнения” читается сразу, а с классом он то “заныривает” куда-то во внутренности джанги, то “выныривает” оттуда.

Вам не кажется, что вы описываете последствия проблемы выше уровнем, выбрав CBV козлом отпущения?
Ведь описываемая вами ситуация случилась (и случается) из-за отсутствия документации - раз, плохо настроенного процесса тестирования и коммита - два.


Давайте разберемся.
Одно дело, кода нужно разобраться с логикой модуля системы, другое - с логикой работы конкретного алгоритма внутри функции/метода.
Для первого нужна документация типа UML, для второго читаемый код и комментарии.


Когда разработчику нужно понять логику работы уже существующего модуля?
Несколько примеров:
1. Он работает с этим модулем впервые.
2. Он вернулся к нему после длительного перерыва.
3. Идет изменение архитектуры.
4. Обнаружена ошибка в бизнес-логике или архитектуре.

Очевидно, в этом случае, использовать диаграммы и погружаться в код в нужных местах удобнее, чем читать код, выстраивая логику работы модуля. Прямой анализ эффективнее обратного, если вы не Шерлок Холмс, умеющий составить общую картинку из большого количества отдельных кусочков.


Когда разработчику нужно понять логику работы существующего кода?
Примеры:
1. Нужна доработка локальной логики.
2. Найдена ошибка в коде. То, что ошибка именно в коде, а не модуле, известно из отчета тестера или результатов теста.
3. Знакомство с кодом в уже знакомой в целом системе.
4. Реализация новых функций, расширение возможностей конкретной функции/класса.

Чтение кода, комментариев и сверка с документацией модуля будет более эффективным и быстрым.
Имеют значение размер и читаемость кода, внятные inline-комментарии по существу, понятные комментарии ссылающиеся на глобальную документацию для сверки алгоритма.


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


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

А для малых проектов CBV часто даже вредны, например, из-за естественной для них “многословности”.
Т.е. это чистой воды over engineering, соответственно - плохой выбор.

kmike
Вот это разве не ад (пример из документации)?

Ад есть везде. Вот мнение, с которым я во многом согласен. Тут есть и пример заныривания для view-функций, и пример “ада” даже не из документации,- из исходников Джанги ;)

Тезисно, мое мнение в дополнение к статье по ссылке:
1. Использовать нужно и то, и другое.
2. Важно знать преимущества и недостатки (реально это возможно только при наличии опыта).
3. Выбирать подход нужно, исходя из нескольких критериев, например: сложность бизнес-логики, объем проекта и кода, план поддержки после сдачи проекта.

Отредактировано Lexander (Ноя. 16, 2012 16:31:33)

Помоему jquery было не совсем удачным выбором для ajax реализации. Можно же dajax заюзать было, оно вроде поудобней.

Вы в курсе, что django-dajax использует jQuery?
Кроме jQuery на клиенте могут использоваться и другие фреймворки.

Чуть удобнее на сервере, но лишний код на клиенте.

Вообще, на серверной стороне ваш AJAX запрос ничем не отличается от обычного HTTP-запроса.

В чем проблема то?

ЗЫ
django-dajax чем-то на Corba смахивает :)

Проблема в том, что с серьезными проектами дела не имел, все сайты-визитки. Ну и опыта написания аякс приложений нет вообще.