Taxonomy + CCK = Taxonomy Fields

Ой я прошу прощения, немного туповат, если Вас не затруднит нельзя ли практический пример использования ?

Добавил картинку. Будем считать, что она иллюстрирует и патч, и сферу применения модуля.

Да, я тож не догнал о применении, когда пробовал модуль :)

Очень хочется комментариев :)

А вот конкретный вопрос из теории БД есть сущности и связь между ними один к одному - пример заказ товара и товарные позиции в нем. Вопрос следующий подойдет ли это поле ( о котором Вы пишете) для организации связки подчиенния материала - "товарная строка заказа" -> "заказ" , чтобы потом можно было через views отображать "товарные строки" к конкретному заказу (связь по аргументу) ?

я тоже не сразу. требуется серьезная ревизия идеи CCK. область применения практически та же, что и у CCK – то есть неограниченная. кроме статичного набора полей у вас есть несколько дополнительных, иерархически организованных.

конкретно этот модуль тут не при чем. это делает модуль nodereference из стандартной поставки CCK.

Вот теперь понятно написал - молодца. А nodereference позволяет коннектить уже созданный материал.

То есть это, по сути, как статические данные в классах объектно-ориентированных языков?
То есть один (или несколько) элементов являются общими для всех экземпляров данного класса (данного типа CCK)?
И при его изменении, значение обновляется для всех экземпляров (материалов)?
Так?

каждое поле тоже как бы класс, его экземпляры можно добавлять к типам контента, которые типа тоже класс, экземпляром которого является контент.

если добавить новое поле вручную (admin/content/types), оно возникнет как класс и как его пока единственный экземпляр для редактируемого типа контента. для всех экземпляров данного типа контента (материалов) это поле будет доступно вне зависимости от позиции материала в таксономии.

интересная деталь – настройки виджета (набор зависит от типа поля: widget_type, label, weight, description, ...). они настраиваемы для каждого экземпляра поля отдельно. т.е. если добавить поле руками, внутри этого типа контента его настройки виджета постоянны. они могут быть другими у другого экземпляра поля в другом типе контента.
спасибо автору, что решил нас не пугать: получить в одном материале 2 экземпляра одного поля с разными виджетами мне не удалось – статические поля приоритетнее таксономных.

а в остальном экземпляры полей, присоединенных к различным термам, ведут себя так же, как присоединенные к различным типам контента. наследуемые поля приоритетнее и не перенастраиваются под потомков.

про 'универсальное' поле я уже писал – его значение устанавливается для терма и его потомков (если включить наследование), все материалы терма содержат это поле как константу.

Хотел просто написать "пиздец!", но сдержался :)

Хорошо, что сдержался, а то неудобно как-то перед http://drupal.ru/profile/gender/женский :)

:)

как я понял все очень просто - когда надо сделать много разных типов контента но у них есть одинакового типа поля - то что-б не плодить много всего - этот патч позволяет объединять одинаковые поля в одно, а разные выстраиваются в дерево, да? только таксономии при чем?

Нет использование cck_field разными content встроено, а вот насчет чтобы не плодить вы правы, дело в том, что это следующий уровень абстракции типов :)

для того, о чем вы говорите, достаточно просто поставить CCK (а с 6-й версии ничего ставить не надо).

модуль предлагает организовывать типы контента в дерево с различными наборами полей.

патч и функции темы делают этот процесс более наглядным.

хехе!

по крайней мере один человек меня понял :))

Навеяло. Гегель говорил: "Никто меня толком не понял, только Мейнерт. Да и тот понял неправильно." :)

отличное развитие...
только есть одна ошибка...
когда выбираешь терм к которому нужно добавить поле, select listы словарей выводятся с учетом параметров словарей, т.е. получается если отмечено что должен быть выбран хотяб один термин, то он уже автоматическии выбран при добавлении!!! т.е. поле добавляется еще к термам которые не нужны, приходится удалять вручную

Попробовал модуль, он не очень вписывается в философию Drupal, по идее должна быть иерархия Типов Материалов, а не приписывание полей Категориям. В любом случае хоть что-то...
И еще хотел резюмировать/спросить работу модуля:

1. Мы должны создать базовый Тип Материала, без добавления в него доп. свойств
2. Мы должны включить этот Тип Материала в Категорию
3. Добавляем свойства уже к иерархии Терминов

Таким образом у нас получается, что Тип Материала, созданного нами лишь номинально присутствует в системе лишь для того, чтобы иметь возможность создавать материал ЛЮБОГО ТИПА из иерархии терминов, так?

Вот он высокий порог вхождения: когда даже Drupal-разработчик еле сдерживается, чтобы не сказать "Пиздец!" :)

ну а еще был модуль category кажется который делал нодами все - и таксономии и что-то еще, в общем надо что бы не очень усложнять