18 мая 2007 в 10:03
Модуль Taxonomy Fields
Какая связь между CCK и Taxonomy? Эти модули занимаются разным делом: CCK конструирует типы контента, Taxonomy упорядочивает контент. Полезный и уже привычный функционал. Зачем придумывать еще что-то? Может не стоит умножать сущности?
Оказывается, принцип таксономии удобен не только для группировки материалов, но и для организации структуры материала. Каждому элементу таксономии (некоторые переводят слово 'term' как 'термин', хотя здесь на мой взгляд лучше подойдет слово 'элемент') можно сопоставить список полей из обычного набора CCK. Материал, принадлежащий этому элементу, получит его поля (они будут доступны для заполнения после сохранения материала с новым значением поля таксономии), как если бы вы вручную добавили их для данного типа материала, но изменения коснутся лишь материалов, принадлежащих данному элементу. Изменение положения материала в таксономии может привести к потере данных из утраченных полей, необходимо это учитывать.
При древовидной структуре таксономии элементы-потомки могут наследовать поля предков (фраза попахивает сельским хозяйством :). Можно назначить 'универсальное' поле, значение которого будет постоянным для всех материалов элемента и не будет доступно из формы редактирования материала.
Такой вариант архитектуры данных очень полезен при большом разнообразии контента. Один и тот же тип материала может иметь разный набор полей в зависимости от положения в таксономии. Перемещаясь по таксономии, материал может 'обрастать' новыми данными, добавляя их к уже имеющимся.
Интерфейс модуля плохо подходит для древовидных таксономий, при большом числе элементов и полей становится очень путаным. Предлагаю попробовать мой патч для версии 5.x-1.4-dev и функции для template.php (функцию 'theme_taxonomy_fields_list_output' надо переименовать в '<имя_вашей_темы>_taxonomy_fields_list_output' или 'phptemplate_taxonomy_fields_list_output').
Патч добавляет в массив данных, передаваемых модулем теме, дополнительную информацию об элементе таксономии, не увеличивая число запросов к базе.
Функции темы отображают дерево таксономии и добавляют унаследованные (inherited) поля к таблице элемента.
Планирую добавить к элементам комбо-боксы 'add existing field' и 'add new field', чтобы обойти лишний переход с неудобным диалогом выбора элемента.
Комментарии
Ой я прошу прощения, немного туповат, если Вас не затруднит нельзя ли практический пример использования ?
Добавил картинку. Будем считать, что она иллюстрирует и патч, и сферу применения модуля.
Да, я тож не догнал о применении, когда пробовал модуль
Очень хочется комментариев
я тоже не сразу. требуется серьезная ревизия идеи CCK. область применения практически та же, что и у CCK – то есть неограниченная. кроме статичного набора полей у вас есть несколько дополнительных, иерархически организованных.
А вот конкретный вопрос из теории БД есть сущности и связь между ними один к одному - пример заказ товара и товарные позиции в нем. Вопрос следующий подойдет ли это поле ( о котором Вы пишете) для организации связки подчиенния материала - "товарная строка заказа" -> "заказ" , чтобы потом можно было через views отображать "товарные строки" к конкретному заказу (связь по аргументу) ?
конкретно этот модуль тут не при чем. это делает модуль nodereference из стандартной поставки CCK.
Вот теперь понятно написал - молодца. А nodereference позволяет коннектить уже созданный материал.
То есть это, по сути, как статические данные в классах объектно-ориентированных языков?
То есть один (или несколько) элементов являются общими для всех экземпляров данного класса (данного типа CCK)?
И при его изменении, значение обновляется для всех экземпляров (материалов)?
Так?
каждое поле тоже как бы класс, его экземпляры можно добавлять к типам контента, которые типа тоже класс, экземпляром которого является контент.
если добавить новое поле вручную (admin/content/types), оно возникнет как класс и как его пока единственный экземпляр для редактируемого типа контента. для всех экземпляров данного типа контента (материалов) это поле будет доступно вне зависимости от позиции материала в таксономии.
интересная деталь – настройки виджета (набор зависит от типа поля: widget_type, label, weight, description, ...). они настраиваемы для каждого экземпляра поля отдельно. т.е. если добавить поле руками, внутри этого типа контента его настройки виджета постоянны. они могут быть другими у другого экземпляра поля в другом типе контента.
спасибо автору, что решил нас не пугать: получить в одном материале 2 экземпляра одного поля с разными виджетами мне не удалось – статические поля приоритетнее таксономных.
а в остальном экземпляры полей, присоединенных к различным термам, ведут себя так же, как присоединенные к различным типам контента. наследуемые поля приоритетнее и не перенастраиваются под потомков.
про 'универсальное' поле я уже писал – его значение устанавливается для терма и его потомков (если включить наследование), все материалы терма содержат это поле как константу.
Хотел просто написать "пиздец!", но сдержался
Хорошо, что сдержался, а то неудобно как-то перед http://drupal.ru/profile/gender/женский
как я понял все очень просто - когда надо сделать много разных типов контента но у них есть одинакового типа поля - то что-б не плодить много всего - этот патч позволяет объединять одинаковые поля в одно, а разные выстраиваются в дерево, да? только таксономии при чем?
для того, о чем вы говорите, достаточно просто поставить CCK (а с 6-й версии ничего ставить не надо).
модуль предлагает организовывать типы контента в дерево с различными наборами полей.
патч и функции темы делают этот процесс более наглядным.
Нет использование cck_field разными content встроено, а вот насчет чтобы не плодить вы правы, дело в том, что это следующий уровень абстракции типов
хехе!
по крайней мере один человек меня понял
Навеяло. Гегель говорил: "Никто меня толком не понял, только Мейнерт. Да и тот понял неправильно."
отличное развитие...
только есть одна ошибка...
когда выбираешь терм к которому нужно добавить поле, select listы словарей выводятся с учетом параметров словарей, т.е. получается если отмечено что должен быть выбран хотяб один термин, то он уже автоматическии выбран при добавлении!!! т.е. поле добавляется еще к термам которые не нужны, приходится удалять вручную
Попробовал модуль, он не очень вписывается в философию Drupal, по идее должна быть иерархия Типов Материалов, а не приписывание полей Категориям. В любом случае хоть что-то...
И еще хотел резюмировать/спросить работу модуля:
1. Мы должны создать базовый Тип Материала, без добавления в него доп. свойств
2. Мы должны включить этот Тип Материала в Категорию
3. Добавляем свойства уже к иерархии Терминов
Таким образом у нас получается, что Тип Материала, созданного нами лишь номинально присутствует в системе лишь для того, чтобы иметь возможность создавать материал ЛЮБОГО ТИПА из иерархии терминов, так?
Вот он высокий порог вхождения: когда даже Drupal-разработчик еле сдерживается, чтобы не сказать "Пиздец!"
ну а еще был модуль category кажется который делал нодами все - и таксономии и что-то еще, в общем надо что бы не очень усложнять