1. Если метод нужно реализовывать в классе-наследнике, то нужно не `pass`, а `raise NotImplementedError`
2. Если вам нужно что-то сделать с queryset'ом, то это лучше делать в менеджере модели, а не во вьюхе.
3. Сериализация (в том числе и в JSON) уже есть в Джанге.
А еще смотрите, если вы решите использовать ваше `MixedView` для другой модели, то, вам придется написать:
class ArticleView(MixedView):
def get_context(self, request): #!
context = dict() #!
context['articles'] =Article.objects.all()
return context #!
template_name = 'articles_list.html'
def convert_context_to_json(self, context): #!
json_context = dict() #!
json_context['article_names'] = [p.name for p in context['articles']]
return json.dumps(json_context, encoding='utf-8', ensure_ascii=False) #!
Восклицательными знаками я отметил строчки, которые придется копировать без изменений. Их 6 из 10! Просто anti-DRY. Можно, в качестве альтернативы, добавить еще один слой наследования и в конец запутать код.
Мне кажется, что CBV в 95% случаев не нужны. Хитросплетения методов и цепочек наследования намного сложнее поддерживать, чем функции. Они не гибкие (если вы используете ListView, а однажды вам понадобится вывести не один а два списка чего-то, что тогда?). Если у вас реально сложная иерархия вьюх в проекте, то может быть CBV и подойдут, но много ли таких проектов.
Что такое «перспективность высшего образования в Интернете»? Для кого? Для студента? Работодателя? Университета-организатора? Человечества?
А по цифрам, даже если предположить, что курс прошло до конца 989 человек, это все равно чуть менее, чем дохрена. Сравните с любой оффлайновой альтернативой.
Какая задача решалась? Сделать код понятнее? List comprehension понятнее и «общепринятее». Сделать код быстрее? List comprehension быстрее раза в два на моем компьютере. Упростить поддержку кода? Да одно и то же.
Да и гибкости у вашего кода мало. А что, если атрибут будет называться не 'name'? А что, если у разных полей атрибут будет называться по-разному? А что, если fields вдруг будет не iterable? Тут до гибкости еще работать и работать. :-)
Насколько же можно все усложнить. Нет никакой прокрастинации, нет никаких «иррационалов» и не нужно искать гармонию. Нужно просто делать. Не делаешь — твое право, только не надо это валить на что-то еще. Ты просто не делаешь. И ничто не мешает начать делать. Достаточно просто взять на себя ответственность за свою же жизнь.
Автор забыл сказать, что тегами нельзя расплатиться в магазине, ими нельзя открыть консервную банку, а еще теги — не лучший аксессуар к вечернему платью этим летом. Жуткие проблемы, да.
Или что, кто-то сидит и «интерпретирует теги»? Или пытается точно понять, о чем пост, по тегам? Или бьется в припадке ярости, когда по тегу «звезда» получает пост о геометрической фигуре, хотя он искал что-то по астрономии? Или (боже мой) пытается выяснить, «сколько постов в этом облаке имеют два и более тэгов»? У меня ни разу не было ничего похожего, я что, один такой?
Еще автор анонсировал некий «второй вариант», видимо, «убийцу тегов». Можно будет этот второй вариант проиллюстрировать на примере last.fm или stackoverflow. Я просто сгораю от любопытства, как же там можно отказаться от тегов.
Вот в чем смысл реферата? Проверить, как студент умеет находить, обрабатывать, понимать информацию по теме из разных источников. Как это проверить? Только защитой, со сложными вопросами. Собеседованием по теме, если угодно. Тогда совершенно неважно, сплагиатил он или сам написал. Структурировал, понял, изложил — молодец. А в плагиате нет ничего плохого, может и лучше, что не стал велосипед изобретать.
Чтобы не забывать что-то взять, я всегда «собираюсь». То есть, когда прихожу домой, вытаскиваю все из карманов. А перед выходом укладываю все обратно. В итоге мне не нужно хлопать себя по карманам, проверяя, все ли на месте, все ли прощупывается, я просто кладу все в карманы (сумку, и т. д.), и на leot спокойно. Как говорится, explicit is better than implicit. :-)
Для любой социальной сети миллионы хомячков будут важнее тысяч гиков. А хомячкам не нужно «информационное пространство». Им нужно «фига, Машка с Сашкой встречается, о, в Питер ездили, надо ей на стену песенку кинуть про Питер». Хомячкам важно, чтоб было удобно и просто, а для этого перенос существующей механики в онлайн — самое то. В общем, хомяки счастливы, владельцы социалок счастливы, гики мечтают.
Да, и без всякого презрения к хомячкам, мы все такие в тех или иных сферах.
Но это хорошо показывает сложность поддержки CBV.
2. Если вам нужно что-то сделать с queryset'ом, то это лучше делать в менеджере модели, а не во вьюхе.
3. Сериализация (в том числе и в JSON) уже есть в Джанге.
А еще смотрите, если вы решите использовать ваше `MixedView` для другой модели, то, вам придется написать:
Восклицательными знаками я отметил строчки, которые придется копировать без изменений. Их 6 из 10! Просто anti-DRY. Можно, в качестве альтернативы, добавить еще один слой наследования и в конец запутать код.
Мне кажется, что CBV в 95% случаев не нужны. Хитросплетения методов и цепочек наследования намного сложнее поддерживать, чем функции. Они не гибкие (если вы используете ListView, а однажды вам понадобится вывести не один а два списка чего-то, что тогда?). Если у вас реально сложная иерархия вьюх в проекте, то может быть CBV и подойдут, но много ли таких проектов.
А по цифрам, даже если предположить, что курс прошло до конца 989 человек, это все равно чуть менее, чем дохрена. Сравните с любой оффлайновой альтернативой.
Да и гибкости у вашего кода мало. А что, если атрибут будет называться не 'name'? А что, если у разных полей атрибут будет называться по-разному? А что, если fields вдруг будет не iterable? Тут до гибкости еще работать и работать. :-)
Или что, кто-то сидит и «интерпретирует теги»? Или пытается точно понять, о чем пост, по тегам? Или бьется в припадке ярости, когда по тегу «звезда» получает пост о геометрической фигуре, хотя он искал что-то по астрономии? Или (боже мой) пытается выяснить, «сколько постов в этом облаке имеют два и более тэгов»? У меня ни разу не было ничего похожего, я что, один такой?
Еще автор анонсировал некий «второй вариант», видимо, «убийцу тегов». Можно будет этот второй вариант проиллюстрировать на примере last.fm или stackoverflow. Я просто сгораю от любопытства, как же там можно отказаться от тегов.
Да, и без всякого презрения к хомячкам, мы все такие в тех или иных сферах.