Не пора ли, друзья мои, нам замахнуться ....

Главные вкладки

Аватар пользователя PVasili PVasili 20 сентября 2012 в 13:30

на Вильяма, понимаете ли, м-м, нашего Шекспира? на словари?
В 7-ке после обвешивания словарей полями различие между словарями и материалами как такового не стало. А нужны ли тогда вообще словари как класс, если их функционал полностью дублируется?
Зачем сейчас используются словари?
В основном для связи материалов и создания иерархии (ну и SEO-нисты облака делают). Может что ещё пропустил Smile
- Иерархия покрывается подшивками (можно тут развить и сделать удобным UI).
- Связи перекрываются референсами между материалами. Для отдельных случаев можно делать тип материала - называемый словарь. В этом типе можно использовать хоть 1 поле и как вариант вообще убирать страничный вывод.
При этом: у нас убавится куча лишних таблиц и искусственное разделение, права раздавать будет тоже - проще (не растягивая отдельно для словарей, отдельно для материалов), ну и версионность.

Комментарии

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 20 сентября 2012 в 13:39

Таксономия нужна и точка.

"PVasili" wrote:
- Иерархия покрывается подшивками (можно тут развить и сделать удобным UI).

Подшивки, они модуль book - скоро вымрут как класс
"PVasili" wrote:
- Связи перекрываются референсами между материалами. Для отдельных случаев можно делать тип материала - называемый словарь. В этом типе можно использовать хоть 1 поле и как вариант вообще убирать страничный вывод.

А можно задницу пальцем вытирать, а потом об стену.

Ещё один плюс таксономии над материалами, это таблица taxonomy_index

Аватар пользователя RedRat RedRat 20 сентября 2012 в 16:07

RxB wrote:
Подшивки, они модуль book - скоро вымрут как класс

А откуда дровишки... в смысле, информация? И что планируется на замену подшивкам?

Аватар пользователя PVasili PVasili 20 сентября 2012 в 13:41

Просили высказываться по делу. Вить, для своих фантазий - открой отдельно топик.

"RxB" wrote:
один плюс таксономии над материалами, это таблица taxonomy_index

Что в этой таблице гениального, чего нет в node?
Нам нужны парент и референс для node. Легко сводится в 1-2 вместо существующих 4-5. Ну и - 2 отдельных таблицы чисто для полей словаря.

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 20 сентября 2012 в 13:57

"PVasili" wrote:

Что в этой таблице гениального, чего нет в node?


Я могу ошибаться, но ты Вася в курсе про Структурированный Язык Запросов и можешь посчитать сколько всего разного придётся джойнить для фильтрации в случае материалов.

Аватар пользователя PVasili PVasili 20 сентября 2012 в 14:01

"RxB" wrote:
сколько всего разного придётся джойнить для фильтрации в случае материалов.

О, уже ближе по делу :).
Джоинить - ровно столько же, сколько сейчас, и даже меньше т.к. количество связующих таблиц типа taxonomy_term_data и taxonomy_vocabulary убавится.

Аватар пользователя NaZg NaZg 20 сентября 2012 в 14:12

Гм...
Может я что не понял?
Есть каталог от убера, например. Есть класс товаров - ручка гелевая от фирмы Big. Корпус синий. С колпачком. Со стразиками сваровски. Стреляющая.
Товар относится к словарям ручки, гелевые, синий корпус, с колпачками, илитные, стреляющие. Да, это может быть один словарь, но с подкатегорями, но это уже скучные подробности.
Как это реализовать подшивками?

Аватар пользователя PVasili PVasili 20 сентября 2012 в 14:46

"NaZg" wrote:
Да, это может быть один словарь, но с подкатегорями, но это уже скучные подробности. Как это реализовать подшивками?

Почему именно подшивки? Нужно к node иерархия и связи. И будет taxonomy. Как UI будет сделано - да хоть как сейчас. Но любой тип материала может выступать в качестве словаря (в том числе иерархического).

Аватар пользователя q2_faith q2_faith 20 сентября 2012 в 15:28

"PVasili" wrote:

как удобно редактировать эти подшивки, иерархии и т.д.? городить еще один огород и обвешивать ноды лишним функционалом, который не всегда нужен? цена вопроса две лишние таблицы?
p.s. такой логикой можно дойти до того, что слить весь функционал в один модуль.
p.p.s многое в 7-ке пересекается по функционалу, но это не повод, чтобы вырезать модули и вешать не нужный функционал на другие модули.

Аватар пользователя PVasili PVasili 20 сентября 2012 в 16:13

"q2_faith" wrote:
как удобно редактировать эти подшивки, иерархии и т.д.? городить еще один огород и обвешивать ноды лишним функционалом, который не всегда нужен? цена вопроса две лишние таблицы?

Вопроса UI не касаемся. Можно как сейчас со словарями, можно как таксономи-менеджер, можно что-то другое.
Вопрос не в 2-х (хотя их больше) таблицах, а в избыточном коде и полностью дублирующем функционале.
Сейчас(в 7-ке) node =(практически ) taxonomy и код и API отдельно для обоих сущностей написан. Со всеми проблемами, багами и избыточностью и т.д.

"q2_faith" wrote:
p.s. такой логикой можно дойти до того, что слить весь функционал в один модуль.

Не функционал, а сущности. У нас сейчас, по сути, сущность одна - весь функционал сдублирован 2 раза.

"q2_faith" wrote:
p.p.s многое в 7-ке пересекается по функционалу, но это не повод, чтобы вырезать модули и вешать не нужный функционал на другие модули.

Модули не нужно вешать никуда. Нужно чтобы сущности, с полностью одинаковым функционалом, были в коде в 1 экземпляре.

"RxB" wrote:
тут пытаются от нод избавиться, а ты предлагаешь на них вешать функционал

И чем предлагают заменить?
Ноды - понятие условное. nodо-ой(как сейчас) - должен быть любой объект, который может чем то расширяться(функционалом, отображениями, полями и т.д.)

Аватар пользователя q2_faith q2_faith 20 сентября 2012 в 16:22

"PVasili" wrote:
Модули не нужно вешать никуда. Нужно чтобы сущности, с полностью одинаковым функционалом, были в коде в 1 экземпляре.

я тогда за удаление нод) а термины оставить

Аватар пользователя PVasili PVasili 20 сентября 2012 в 16:31

"q2_faith" wrote:
я тогда за удаление нод) а термины оставить

Ну не важно как этот бандл обозвать. Суть, что то, что есть избыточно и не всегда удобно.
Пример:
Словарь города.
Связывали им материал и не отображали ни где на сайте. Потом захотели по каждому городу сделать отдельно статью.
В 6-ке вообще нужно было еще один материал, его к словарю и чуть чуть бубном в PHP покрутить.
В 7-ке проще, но тоже.. словарь обвесили полями и используем в качестве node (где логика)?

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 20 сентября 2012 в 16:32

"RedRat" wrote:

А откуда дровишки... в смысле, информация? И что планируется на замену подшивкам?


http://drupal.org/node/1255674#comment-4917848

"PVasili" wrote:
И чем предлагают заменить?
Ноды - понятие условное. nodо-ой(как сейчас) - должен быть любой объект, который может чем то расширяться(функционалом, отображениями, полями и т.д.)

Дык, если на то пошло, то и ноды уже смысла не имеют, а имеют смысл сущности, а таксономия тоже сущность.
Всё, круг замкнулся.

Аватар пользователя PVasili PVasili 20 сентября 2012 в 17:11

"RxB" wrote:
Дык, если на то пошло, то и ноды уже смысла не имеют
ну об этом и сказано. Как назвать - другое дело.

Аватар пользователя Chyvakoff Chyvakoff 20 сентября 2012 в 17:35

"q2_faith" wrote:
я тогда за удаление нод) а термины оставить

"RxB" wrote:
Дык, если на то пошло, то и ноды уже смысла не имеют, а имеют смысл сущности, а таксономия тоже сущность.
Всё, круг замкнулся.

И не поспоришь ведь..

PVasili, а ты отключи модуль таксономии и попробуй собрать вменяемый сайт.А мы посмотрим. "Страницу таксономии" вьюхой придётся делать?

Аватар пользователя PVasili PVasili 20 сентября 2012 в 20:52

"Chyvakoff" wrote:
а ты отключи модуль таксономии и попробуй собрать вменяемый сайт.

Прежде чем что-то писать - полезно прочесть сам топик...

Аватар пользователя Orion76 Orion76 21 сентября 2012 в 0:04

а можно поподробнее.. чем таксономия дублирует ноду..?

Кстати.. еще про product в commerce забыли.. да что там говорить.. и user и т.п.-))

ЗЫ.. что-то мне подсказывает.. что если попытаться ноду приспособить для категоризации контента..
то получиться таксономия-))))

Аватар пользователя andypost@drupal.org andypost@drupal.org 21 сентября 2012 в 1:07

Идея, конечно, забавная, но есть большая разница между контентом и словарём - поддерка ревизий!!!
И этот признак прописывается в информации о сущности, также он сильно влияет на контроллер

Предлагаю лучше сосредоточить усилия на интересном начинании - превращении коментов в поле http://drupal.org/node/1790764

Аватар пользователя PVasili PVasili 21 сентября 2012 в 2:18

"orion76" wrote:
а можно поподробнее.. чем таксономия дублирует ноду.

Проще идти от обратного: попробуйте привести отличия (если разговор идет о 7-ке) :).
Эти 2 объекта имеют практически абсолютно идентичный функционал, а кода, таблиц, хуков и глюков в 2 раза больше. При этом всё это дублируется 2 раза.

"<a href="mailto:andypost@drupal.org">andypost@drupal.org</a>" wrote:
большая разница между контентом и словарём - поддерка ревизий!!!

Тем более замечательно! Мы получим к "комбайну" или как Виктор правильнее обозвал "сущности" дополнительный функционал в виде версий (чего сейчас нет у словарей).
Не важно чем будет сущность node или taxonomy (что проще взять за основу будет).

"<a href="mailto:andypost@drupal.org">andypost@drupal.org</a>" wrote:
превращении коментов в поле
это из той же серии... коменты можно цеплять будет к любой сущности. imho очень гибко и удобно. Только как на производительности скажется. Нужно у начальника транспортного цеха Виктора спросить, он там с большими числами в коментах сталкивался.

Аватар пользователя PVasili PVasili 21 сентября 2012 в 2:24

Тезис в топике - скорее не совсем про словари. Он скорее про материалы и словари. Но за основу для сущности node (imho) проще взять.

Аватар пользователя Chyvakoff Chyvakoff 21 сентября 2012 в 9:13

"PVasili" wrote:
Прежде чем что-то писать - полезно прочесть сам топик...

Не поверишь-и топик прочитал, и комментарии к нем.
Сам таким извратом способом не занимался,но считаю что это не то.. Вот например простенький сайт http://flywer.ru . Ноды,2 словаря таксономии и для хлебных крошек 1 допиленный модуль.
Никаких полей у словарей и вьюх. Крутится на бесплатном хосте. В этом случае будет целесообразен твой подход?

Аватар пользователя Orion76 Orion76 21 сентября 2012 в 9:30

А если мне для нескольких типов материалов, необходимо несколько атрибутов с выбором значений(10-50 позиций, возможно с иерархией).. От атрибута мне нужен только его ИД и ИМЯ..

Мне это все на нодах "мутить"?-))

нахрена мне для этих атрибутов:
Автор
Дата создания
Дата изменения
Настройка прав на редактирование, просмотр, удаления
Комменты
Ревизии
Показывать на главной
Опубликовано
и т.д. ?

ЗЫ.. Вот кстати и отличия... а одинакового у них только поле "Заголовок"..

Аватар пользователя PVasili PVasili 21 сентября 2012 в 10:27

"Chyvakoff" wrote:
Ноды,2 словаря таксономии... В этом случае будет целесообразен твой подход?

2 сущности с типом материал и 2-е с типом словарь (поля они не имеют). Всё работает абсолютно как сейчас. И с чем проблема? Вы видите всё как у вас есть сейчас.

"orion76" wrote:
От атрибута мне нужен только его ИД и ИМЯ..

Так для типа сущности словарь, по умолчанию, будет выводится только заголовок. Сущности можно будет в UI и группировать как словари отдельно от материалов.
Кроме того:
"orion76" wrote:
Автор, Дата создания, Дата изменения, Настройка прав на редактирование, просмотр, удаления, Комменты, Ревизии, ,Показывать на главной, Опубликовано, и т.д. ?
для сущностей типа словарь будут в базе, и зачастую они сейчас бывают нужны для словарей. А тут будут "из коробки". Всё что вы перечислили сейчас легко делается из словарей + поля или связи. А будет унифицировано. Ну и + если ещё добьют инициативу с отделением комментов, как Андрей дал ссылку. Будет гибко и удобно.

И разработчики будут шире смотреть на разработку сайтов, а не мыслить шаблонами в духе "а давайте вам форум поставим" ...

Аватар пользователя PVasili PVasili 21 сентября 2012 в 11:03

Кстати, видится ещё очень полезным функционал отключения для сущностей создание страницы.
Часто то, что сейчас называется словарь используется только для связи, а материалы только как контейнеры для поставки своих полей в views и/или другие материалы, а drupal по умолчанию им генерирует страницы...
Например:
- делаем слайд-шоу. Картинки в полях. Слайд-шоу через Views в блок. Зачем мне ещё и страница?
- делаем набор объявление, которые выводятся через блоки (или через Views в панели) тоже приходится страдать из-за дополнительной нагрузки в виде страниц Sad

Аватар пользователя Andruxa Andruxa 21 сентября 2012 в 13:33

Сущности - это от фреймворк-составляющей Д., ноды и таксономия - это уже экземпляры сущностей, настроенные определенным образом, используются непосредственно в CMS.
Хочешь - используй только ноды или таксономию, хочешь - обе сущности сразу.
А можно, например, насоздавать собственных велосипедов сущностей вместо них.

Модуль таксономии, кстати, можно просто отключить и почистить от него базу, если мешает.

"PVasili" wrote:
функционал отключения для сущностей создание страницы

если речь о страницах по адресу /entity-name/entity-id, то всё равно потребуются пути
/entity-name/add
/entity-name/entity-id/edit
/entity-name/entity-id/delete

да и путь /entity-name/entity-id в некоторых случаях будет полезен - например, показывать содержимое сущности в лайтбоксах.

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

Аватар пользователя PVasili PVasili 21 сентября 2012 в 14:45

"Andruxa" wrote:
Сущности - это от фреймворк-составляющей Д., ноды и таксономия - это уже экземпляры сущностей,

это задел на 9-ку или в 8-ке будет?
"Andruxa" wrote:
таксономии, кстати, можно просто отключить и почистить от него базу, если мешает.

он не мешает, а почти полностью дублирует по коду и функционалу node (ну или наоборот)

"Andruxa" wrote:
а избыточность присутствует в его CMS-составляющей, и придает друпалу гибкости.

Избыточность не всегда придаёт гибкость, а дублирование - ошибки, абсолютно лишнюю работу по кодингу и нагрузку по памяти и времени.

Аватар пользователя Andruxa Andruxa 21 сентября 2012 в 17:14

"PVasili" wrote:
это задел на 9-ку или в 8-ке будет?

нет, это существующая ситуация: есть entity "node", есть entity "taxonomy", можно насоздавать своих, это то, что я назвал "фреймворк-составляющей"

"PVasili" wrote:
он не мешает, а почти полностью дублирует по коду и функционалу node (ну или наоборот)

если разработчику (в рамках CMS) нужны оба функционала - он может задействовать их оба, либо отключить taxonomy, если считает необходимым
также, на уровне CMF он может создать свои сущности с требуемым функционалом и использовать их в CMS

"PVasili" wrote:
Избыточность не всегда придаёт гибкость, а дублирование - ошибки, абсолютно лишнюю работу по кодингу и нагрузку по памяти и времени.

я имею в виду - разработчику CMS предоставляются 2 готовые сущности, функционал которых он может использовать на своё усмотрение, "из длинного завсегда получится сделать короткое", в этом смысле

Аватар пользователя Chyvakoff Chyvakoff 21 сентября 2012 в 17:56

"PVasili" wrote:
Часто то, что сейчас называется словарь используется только для связи

А для чего его собственно ещё использовать?Или я не прав?

Аватар пользователя andypost@drupal.org andypost@drupal.org 24 сентября 2012 в 4:23

В 8ке будет 2 вида сущностей - ContentEntity & ConfigEntity (детали), наглядные примеры тому http://drupal.org/node/1588422 и http://drupal.org/node/1552396

За оставшиеся 2 месяца лучше сделать больше сущностей и обкатать новый entityAPI в ядре до релиза!!!

...посему универсализацию терминов терминов считаю слишком поспешной - это, однозначно, материал для Drupal 9.
А в 8ке еще нужно успеть новый Property API допилить

EDIT а вот для связей нужно успеть аналог EntityReference в ядро положить

Аватар пользователя PVasili PVasili 29 сентября 2012 в 23:11

"<a href="mailto:andypost@drupal.org">andypost@drupal.org</a>" wrote:
...посему универсализацию терминов терминов считаю слишком поспешной - это, однозначно, материал для Drupal 9.

2 месяца вроде как для закрытия хотелок? Андрей, всё равно, потом же всё допиливать будут... Может сейчас пофлешмобить, чтобы меньше мусора сразу в 8-ке было? Для 9-ки ещё идей появится море, а сейчас тупиковую ветвь зачем дальше развивать?