Ну, пример был сильно упрощенный. В джанго ведь наследумая модель может быть самостоятельной или абстрактной, можно использовать прокси-модели. Всё зависит от ситуации.
Например, у вас в категории может быть не один, а много разных типов материалов, причем сложных типов с объемными тяжелыми материалами. Так вот чтобы публикации списка материалов категории не дергать все эти материалы разных типов из разных таблиц, можно создать базовую легкую модель с минимальным набором полей: тайтл, анонс, превьюшная картинка, ключ на категорию и подобное. А все остальные сложные типы будут наследоваться от этой базовой модели. Тогда при публикации категории вы одним запросом извлекаете объекты базового типа и через шаблон публикуете их список (тайтл, картинка, анонс). И всё. Всего один запрос к БД, не зависимо от типов материалов и прочего.
SeVlad, спасибо за пример.
Мне анекдот вспомнился:
"Стюардесса в салоне нового лайнера объявляет о то, что находится в самолете:
- На первой палубе - багаж, на второй - бар, на третьей - поле для гольфа, на четвертой бассейн.
И добавляет:
- А теперь, господа, пристегнитесь. Сейчас со всей этой фигнёй мы попробуем взлететь."
Как я понял, в WP тот же принцип создания полей, что и создание пользовательских полей в друпале. Т.е. для каждого поля создается отдельная таблица. Это конечно гибко, но громоздко и непроизводительно - при рендеринге объекта приходится дергать все эти таблицы в БД. Я всё же в большинстве случаев предпочитаю хранить все поля материала в одной таблице типа материала. Это прозрачно и работает быстро и надежно. Недостаток - новое поле надо в коде ручками прописывать (1 строку), а не в админке создавать.
Sly32, Очень приятный движок. У меня самопис был построен на подобных принципах (дерево и т.д.), но самопис так и остался сделанным на коленке, т.е. я могу использать его только для своих нужд. А тут наткнулся на похожее решение, но уже из коробки и поддерживаемое сообществом.
Правда сыроват, т.к. находится в стадии активного развития. Но все проблемы, что у меня возникли, я решил. Прикрутил кастомные фильтры изображений, colorbox и т.д.
Кстати, там основная поисковая система - elasticsearch. Крайне рекомендую попробовать. Правда пришлось повозиться с настройкой, так как многие возможности эластиксёча еще не реализованы нативно в вагтэйле, но я уже прикрутил русскую морфологию и вывод поисковых сниппетов с подсветкой искомых слов. Протестировал на паре миллионов документов среднего размера. Индексация на шестиядерном интеле заняла всего 50 минут. Сам поиск идет субъективно около 1 секунды (точно не замерял).
Там из коробки и
Пример не на чистой Джанго, а на CMS Wagtail, которая основана на Джанго, с приятной простой админкой - аля вордпресс, и практически без каких-либо ограничений и с деревом объектов.---------- Добавлено 29.11.2016 в 11:32 ----------
Нужно просто на базе имеющегося типа материала создать новый тип с тем же самым функционалом, только с дополнительным полем или методом. Я привел пример, как это можно сделать в три строчки кода без какого-либо избыточного дублирования.---------- Добавлено 29.11.2016 в 11:36 ----------
Глянул справочник. Нет, это не то. Эта функция просто добавляет поле в имеющийся тип. А мне надо создать новый тип на базе имеющегося, т.е. с наследованием всех его плюшек.
Вы лучше пример реализации моего примера приведите, чтобы можно было наглядно сравнить.
А от Друпал 8 мне увы пришлось отказаться. Из-за тормозов - он оказался вдвое медленней, чем Друпал 7, который также быстротой и легковесностью не отличался.
Давайте так. Предположим у нас есть сайт с неким функционалом и в нем есть тип материала - статья (Article) или что то посложнее - со множеством полей, методов и т.д. И вот нам потребовалось такое же платье, только с перламутровыми пуговицами - например, новый тип Статья (NewArticle) с тем же самым сложным функционалом, что у типа Article, но с дополнительным полем, например "Дата публикации" (public_date).
В моем случае это может выглядеть примерно так:
class NewArticle(Article): public_date = models.DateField() content_panels = Article.content_panels + [ FieldPanel('public_date'), ]
Собственно всё. В админке мы имеем новый тип - такой же как Article, только с новым полем "дата публикации", которое там присутствует со всеми плюшками в виде всплвающего календаря.
WP, Joomla, Drupal могут что-нибудь подобное (по простоте)?
StarMaster, а зачем вам это? На userAgent я бы не полагался в серьезном деле. Как вариант - собирать базу userAgent для всех возможных браузеров и устройств, но это гемор ещё тот.
Ну, вы же платили НДФЛ, поэтому не вижу причин для беспокойства.
Вопрос не имеет смысла. Зависит от задачи. Для каких нибудь стандартных вещей WP из коробки будет конечно проще настроить. А для нестандартных вещей может быть совсем наоборот.
Ну, не знаю. Мой опыт создания поиска с помощью алгоритмов типа нейронных сетей, lda и подобного оказался скорее отрицательным, чем положительным. Да, результаты получаются интересные... для эксперта, например. Но по факту практическая польза для простого чела оказалась меньше, чем от использования более примитивных прямолинейных и прозрачных алгоритмов, не оперирующих вероятностями.
Также при использовании нейронной сети любая страница будет релевантна любому запросу. Т.е. для каждого запроса всякая страница имеет ненулевой вес. В результате в выдачу могут попадать совершенно левые сайты. Да и из презентации нового алгоритма Яндексом это видно: на запрос про скандинавское евангелие в результат в их примере попала страница с заголовком "Мебель из Икеи"... Не на первых местах, но всё же это не хорошо. Да, полнота получается значительно выше, но на месте обывателя, увидев такой результат в выдаче (совершенно не в тему), я бы усомнился в адекватности всей выдачи.
