20 сентября 2012 в 13:30
на Вильяма, понимаете ли, м-м, нашего Шекспира? на словари?
В 7-ке после обвешивания словарей полями различие между словарями и материалами как такового не стало. А нужны ли тогда вообще словари как класс, если их функционал полностью дублируется?
Зачем сейчас используются словари?
В основном для связи материалов и создания иерархии (ну и SEO-нисты облака делают). Может что ещё пропустил 
- Иерархия покрывается подшивками (можно тут развить и сделать удобным UI).
- Связи перекрываются референсами между материалами. Для отдельных случаев можно делать тип материала - называемый словарь. В этом типе можно использовать хоть 1 поле и как вариант вообще убирать страничный вывод.
При этом: у нас убавится куча лишних таблиц и искусственное разделение, права раздавать будет тоже - проще (не растягивая отдельно для словарей, отдельно для материалов), ну и версионность.
Комментарии
Таксономия нужна и точка.
Подшивки, они модуль book - скоро вымрут как класс
А можно задницу пальцем вытирать, а потом об стену.
Ещё один плюс таксономии над материалами, это таблица taxonomy_index
А откуда дровишки... в смысле, информация? И что планируется на замену подшивкам?
Просили высказываться по делу. Вить, для своих фантазий - открой отдельно топик.
Что в этой таблице гениального, чего нет в node?
Нам нужны парент и референс для node. Легко сводится в 1-2 вместо существующих 4-5. Ну и - 2 отдельных таблицы чисто для полей словаря.
Я могу ошибаться, но ты Вася в курсе про Структурированный Язык Запросов и можешь посчитать сколько всего разного придётся джойнить для фильтрации в случае материалов.
О, уже ближе по делу :).
Джоинить - ровно столько же, сколько сейчас, и даже меньше т.к. количество связующих таблиц типа taxonomy_term_data и taxonomy_vocabulary убавится.
Гм...
Может я что не понял?
Есть каталог от убера, например. Есть класс товаров - ручка гелевая от фирмы Big. Корпус синий. С колпачком. Со стразиками сваровски. Стреляющая.
Товар относится к словарям ручки, гелевые, синий корпус, с колпачками, илитные, стреляющие. Да, это может быть один словарь, но с подкатегорями, но это уже скучные подробности.
Как это реализовать подшивками?
Почему именно подшивки? Нужно к node иерархия и связи. И будет taxonomy. Как UI будет сделано - да хоть как сейчас. Но любой тип материала может выступать в качестве словаря (в том числе иерархического).
как удобно редактировать эти подшивки, иерархии и т.д.? городить еще один огород и обвешивать ноды лишним функционалом, который не всегда нужен? цена вопроса две лишние таблицы?
p.s. такой логикой можно дойти до того, что слить весь функционал в один модуль.
p.p.s многое в 7-ке пересекается по функционалу, но это не повод, чтобы вырезать модули и вешать не нужный функционал на другие модули.
Ну и да, Вась, тут пытаются от нод избавиться, а ты предлагаешь на них вешать функционал
Вопроса UI не касаемся. Можно как сейчас со словарями, можно как таксономи-менеджер, можно что-то другое.
Вопрос не в 2-х (хотя их больше) таблицах, а в избыточном коде и полностью дублирующем функционале.
Сейчас(в 7-ке) node =(практически ) taxonomy и код и API отдельно для обоих сущностей написан. Со всеми проблемами, багами и избыточностью и т.д.
Не функционал, а сущности. У нас сейчас, по сути, сущность одна - весь функционал сдублирован 2 раза.
Модули не нужно вешать никуда. Нужно чтобы сущности, с полностью одинаковым функционалом, были в коде в 1 экземпляре.
И чем предлагают заменить?
Ноды - понятие условное. nodо-ой(как сейчас) - должен быть любой объект, который может чем то расширяться(функционалом, отображениями, полями и т.д.)
я тогда за удаление нод) а термины оставить
Ну не важно как этот бандл обозвать. Суть, что то, что есть избыточно и не всегда удобно.
Пример:
Словарь города.
Связывали им материал и не отображали ни где на сайте. Потом захотели по каждому городу сделать отдельно статью.
В 6-ке вообще нужно было еще один материал, его к словарю и чуть чуть бубном в PHP покрутить.
В 7-ке проще, но тоже.. словарь обвесили полями и используем в качестве node (где логика)?
http://drupal.org/node/1255674#comment-4917848
Дык, если на то пошло, то и ноды уже смысла не имеют, а имеют смысл сущности, а таксономия тоже сущность.
Всё, круг замкнулся.
И не поспоришь ведь..
PVasili, а ты отключи модуль таксономии и попробуй собрать вменяемый сайт.А мы посмотрим. "Страницу таксономии" вьюхой придётся делать?
Прежде чем что-то писать - полезно прочесть сам топик...
а можно поподробнее.. чем таксономия дублирует ноду..?
Кстати.. еще про product в commerce забыли.. да что там говорить.. и user и т.п.-))
ЗЫ.. что-то мне подсказывает.. что если попытаться ноду приспособить для категоризации контента..
то получиться таксономия-))))
Идея, конечно, забавная, но есть большая разница между контентом и словарём - поддерка ревизий!!!
И этот признак прописывается в информации о сущности, также он сильно влияет на контроллер
Предлагаю лучше сосредоточить усилия на интересном начинании - превращении коментов в поле http://drupal.org/node/1790764
Проще идти от обратного: попробуйте привести отличия (если разговор идет о 7-ке) :).
Эти 2 объекта имеют практически абсолютно идентичный функционал, а кода, таблиц, хуков и глюков в 2 раза больше. При этом всё это дублируется 2 раза.
Тем более замечательно! Мы получим к "комбайну" или как Виктор правильнее обозвал "сущности" дополнительный функционал в виде версий (чего сейчас нет у словарей).
Не важно чем будет сущность node или taxonomy (что проще взять за основу будет). это из той же серии... коменты можно цеплять будет к любой сущности. imho очень гибко и удобно. Только как на производительности скажется. Нужно у
начальника транспортного цехаВиктора спросить, он там с большими числами в коментах сталкивался.Тезис в топике - скорее не совсем про словари. Он скорее про материалы и словари. Но за основу для сущности node (imho) проще взять.
Не поверишь-и топик прочитал, и комментарии к нем.
Сам таким
извратомспособом не занимался,но считаю что это не то.. Вот например простенький сайт http://flywer.ru . Ноды,2 словаря таксономии и для хлебных крошек 1 допиленный модуль.Никаких полей у словарей и вьюх. Крутится на бесплатном хосте. В этом случае будет целесообразен твой подход?
А если мне для нескольких типов материалов, необходимо несколько атрибутов с выбором значений(10-50 позиций, возможно с иерархией).. От атрибута мне нужен только его ИД и ИМЯ..
Мне это все на нодах "мутить"?-))
нахрена мне для этих атрибутов:
Автор
Дата создания
Дата изменения
Настройка прав на редактирование, просмотр, удаления
Комменты
Ревизии
Показывать на главной
Опубликовано
и т.д. ?
ЗЫ.. Вот кстати и отличия... а одинакового у них только поле "Заголовок"..
2 сущности с типом материал и 2-е с типом словарь (поля они не имеют). Всё работает абсолютно как сейчас. И с чем проблема? Вы видите всё как у вас есть сейчас.
Так для типа сущности словарь, по умолчанию, будет выводится только заголовок. Сущности можно будет в UI и группировать как словари отдельно от материалов.
Кроме того:
для сущностей типа словарь будут в базе, и зачастую они сейчас бывают нужны для словарей. А тут будут "из коробки". Всё что вы перечислили сейчас легко делается из словарей + поля или связи. А будет унифицировано. Ну и + если ещё добьют инициативу с отделением комментов, как Андрей дал ссылку. Будет гибко и удобно.
И разработчики будут шире смотреть на разработку сайтов, а не мыслить шаблонами в духе "а давайте вам форум поставим" ...
Кстати, видится ещё очень полезным функционал отключения для сущностей создание страницы.
Часто то, что сейчас называется словарь используется только для связи, а материалы только как контейнеры для поставки своих полей в views и/или другие материалы, а drupal по умолчанию им генерирует страницы...
Например:
- делаем слайд-шоу. Картинки в полях. Слайд-шоу через Views в блок. Зачем мне ещё и страница?
- делаем набор объявление, которые выводятся через блоки (или через Views в панели) тоже приходится страдать из-за дополнительной нагрузки в виде страниц
Сущности - это от фреймворк-составляющей Д., ноды и таксономия - это уже экземпляры сущностей, настроенные определенным образом, используются непосредственно в CMS.
Хочешь - используй только ноды или таксономию, хочешь - обе сущности сразу.
А можно, например, насоздавать собственных
велосипедовсущностей вместо них.Модуль таксономии, кстати, можно просто отключить и почистить от него базу, если мешает.
если речь о страницах по адресу /entity-name/entity-id, то всё равно потребуются пути
/entity-name/add
/entity-name/entity-id/edit
/entity-name/entity-id/delete
да и путь /entity-name/entity-id в некоторых случаях будет полезен - например, показывать содержимое сущности в лайтбоксах.
Т.е. моё имхо такое - да, в друпале существует избыточность фуккционала, который в ряде случаев дублируется, но эта избыточность присутствует в его CMS-составляющей, и придает друпалу гибкости.
это задел на 9-ку или в 8-ке будет?
он не мешает, а почти полностью дублирует по коду и функционалу node (ну или наоборот)
Избыточность не всегда придаёт гибкость, а дублирование - ошибки, абсолютно лишнюю работу по кодингу и нагрузку по памяти и времени.
нет, это существующая ситуация: есть entity "node", есть entity "taxonomy", можно насоздавать своих, это то, что я назвал "фреймворк-составляющей"
если разработчику (в рамках CMS) нужны оба функционала - он может задействовать их оба, либо отключить taxonomy, если считает необходимым
также, на уровне CMF он может создать свои сущности с требуемым функционалом и использовать их в CMS
я имею в виду - разработчику CMS предоставляются 2 готовые сущности, функционал которых он может использовать на своё усмотрение, "из длинного завсегда получится сделать короткое", в этом смысле
А для чего его собственно ещё использовать?Или я не прав?
В 8ке будет 2 вида сущностей - ContentEntity & ConfigEntity (детали), наглядные примеры тому http://drupal.org/node/1588422 и http://drupal.org/node/1552396
За оставшиеся 2 месяца лучше сделать больше сущностей и обкатать новый entityAPI в ядре до релиза!!!
...посему универсализацию терминов терминов считаю слишком поспешной - это, однозначно, материал для Drupal 9.
А в 8ке еще нужно успеть новый Property API допилить
EDIT а вот для связей нужно успеть аналог EntityReference в ядро положить
2 месяца вроде как для закрытия хотелок? Андрей, всё равно, потом же всё допиливать будут... Может сейчас пофлешмобить, чтобы меньше мусора сразу в 8-ке было? Для 9-ки ещё идей появится море, а сейчас тупиковую ветвь зачем дальше развивать?