Field Permissions: разные настройки для повторно использованных полей

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

Аватар пользователя NikBRD NikBRD 16 июля 2019 в 21:29

Всем здравствуйте!

Есть модуль "Field Permissions" (https://www.drupal.org/project/field_permissions), который позволяет присваивать права отдельным полям.

Если создать 1 поле и использовать его в разных типах материалов, то не получается этому полю присвоить разные права отдельно в каждом типа материала: если права нужного поля меняешь в одном типе материала, то права этого же поля также и изменяются в другом типе материала.

Подскажите, кто использует модуль, - это у меня какие-то конфликты на сайте или модуль так и работает?

Комментарии

Аватар пользователя marassa marassa 16 июля 2019 в 22:45

bumble wrote:
Неправильно, с т.з. архитектуры, использовать одно поле в разных типах сущностей.

А чем именно это чревато? Друпал это довольно настойчиво предлагает, я сначала удивился, потом попробовал, нашёл удобным и стал использовать. Пока ни с какими граблями не столкнулся. Какие неприятности меня ждут?

Аватар пользователя bumble bumble 16 июля 2019 в 22:48
2

Есть такая штука как связанность (coupling), ее принято держать на минимуме (по хорошим практикам). Зависимость компонентов между собой - нарушает эти принципы.

Черевато тем, что если нужно будет изменить в только одном месте - это сделать не получится, на лицо - сабж.

Аватар пользователя marassa marassa 17 июля 2019 в 7:23

Долго думал, пришел к выводу, что это палка о двух концах, как обычно. Есть ещё такая штука как reuse, которую принято держать на максимуме (по хорошим практикам). Поэтому, если видишь, что пишешь один и тот же код второй раз, принято вынести его в функцию или библиотеку. А если на одиннадцатый раз видишь, что в одном месте нужно что-то изменить, ну не вызывай там эту функцию, или расширь ее нужным аргументом/параметром.
У поля в Друпал довольно много важных параметров, и каждый раз забивать их все вручную, если нужно добавить совершенно одинаковые по семантике поля к разным типам материалов, неудобно и неправильно. Вот буквально только что на своем сайте одним кликом добавил поле "счётчик" к очередному новому типа материала, и счётчик совершенно автоматически и единообразно появился в нужной вьюхе.
Все системные поля Друпал (Published, Authored by, Authored on и т.п.) определены единожды для любого контента, и это правильно. Если есть такая возможность, надо ей пользоваться. С умом, естественно.

Аватар пользователя gun_dose gun_dose 17 июля 2019 в 8:17
1

Что хорошо, вся темизация поля также подтягивается, наверное, это и есть хороший критерий целесообразности повторного использования: если выглядит одинаково, то можно использовать, а если есть различия, то лучше завести отдельное поле. Но что интересно, в семёрке все поля были сквозными для всех сущностей - можно было зайти, скажем, в настройки термина и добавить поля, которые добавлены к нодам. В восьмёрке такое не прокатывает.

Аватар пользователя Orion76 Orion76 17 июля 2019 в 8:19
1

Для Drupal 7 был(есть) модуль "наследования" сущностей(бандлов) для решения подобных "проблем" в плане сущностей.

Да, было бы не плохо и для полей иметь такой модуль.
Который позволял бы "наследовать" параметры поля от "родительского" поля с сохранением связи с "родителем"(наследование) или без ("копирование" поля-"родителя").

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

Или написать..

Аватар пользователя gun_dose gun_dose 17 июля 2019 в 10:44

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

Аватар пользователя bumble bumble 17 июля 2019 в 10:45

Все так, да не так Smile
На самом деле, это reuse (а точнее dry) - двуконечная палка. И с ней нужно весьма аккуратно, иначе может дойти до банальностей, когда все фанатично выносится в общие методы и функции, считаясь "повторением", но таковым не являясь. Тем самым увиличивая, ранее упомянутую, метрику связанности.

Но эти принципы еще как-никак могут применяться к коду, в то время, как переиспользование полей это про переиспользование конфигураций.

При проектировании, принято абстрагироваться как можно больше от конкретных реализаций и мыслить о модуле (не друпал-модуле, а модуле системы), с т.з. максимально независимого компонента. Каждый тип сущности, каждый бандл - должны быть отдельным компонентом, иначе зачем они разделены (возможно была допущена ошибка при разбивке на компоненты)?

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

Аватар пользователя marassa marassa 17 июля 2019 в 11:17

bumble wrote:
При проектировании, принято ... мыслить о модуле (не друпал-модуле, а модуле системы), с т.з. максимально независимого компонента.

Это при условии, что данный модуль гипотетически может быть реюзан где-то вне текущего контекста. А если не может? Ну или проектировщик принимает осознанный риск, что для него простота общей конструкции и ее сопровождения важнее абстрактной возможности реюза компонента вне текущего контекста?
bumble wrote:
Каждый тип сущности, каждый бандл - должны быть отдельным компонентом, иначе зачем они разделены (возможно была допущена ошибка при разбивке на компоненты)?

Ну, страны, регионы, города и архитекторы - очевидно разные сущности в реальном мире с разными атрибутами, поэтому и разделены. Но есть у них и общие атрибуты - Published, Authored by, Authored on и Счетчик артефактов. И каждый из них оформлен как одно поле, используемое разными бандлами. Причем первые три созданы (условно) Дрисом, причем для всех сайтов на Друпале сразу, а четвертое - мной, причем для одного отдельно взятого сайта. Мне так значительно удобнее. И я осознанно иду на риск, что если мне вдруг захочется в одном из бандлов сделать это поле текстовым или многозначным, то у меня это не получится.

Аватар пользователя bumble bumble 17 июля 2019 в 11:47

Это при условии, что данный модуль гипотетически может быть реюзан где-то вне текущего контекста

Нет, это уже следствие.

Ну или проектировщик принимает осознанный риск

Какие риски принимать проектировщику - дело, безусловно, его. Но оно не перестает быть неправильным от того что осознано принято.

Попробуйте спроецировать ситуацию, в которой принимается осознанный риск проектировщика жилых домов, ради "простоты общей конструкции" (а на деле из-за того что лень накликать еще раз) применяющий одинаковые элементы для построения различной этажности домов, к примеру.

общие атрибуты - Published, Authored by, Authored on

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

В это же время, "Счетчик артефактов" - действительно, есть возможность спроектировать как нужно.

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

Аватар пользователя gun_dose gun_dose 17 июля 2019 в 12:15

Тут крайне неверно применено слово "риски". Не все принимаемые решения являются рисками. И если проводить аналогию с жилыми домами, то архитектор может спроектировать жилой дом без лифта, потому что он трёхэтажный, и это будет правильно и не будет никаких рисков, даже несмотря на то, что есть "риск", что в будущем захотят построить ещё N этажей и понадобится лифт.

Соответственно с полями такое же дело - если в обозримой перспективе проблем не предвидится, то это никакой не риск.

Аватар пользователя bumble bumble 17 июля 2019 в 13:11

Да, верно. Не риск.

Пример подходящее: когда архитектор во всех домах либо строит, либо не строит лифты. Вне зависимости от к-ва этажей (использует только одну конфигурацию).

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

Для меня это как будто кто-нибудь привязывает одну из своих рук, чтоб специально ей не пользоваться, экономить. А зачем? Есть же вторая. Все равно я руку буду использовать для того чтоб хватать что-то, так я и другой рукой хватаю. То же самое... А если нужно будет не хватать а молотить - просто изменю конфиг. Все равно же какой рукой молотить. Зачем повторять один и тот же интерфейс, если он будет, предположительно, использоваться так же? (и ничего что один и тот же инструмент - "рука", используясь точно для тех же целей - "хватания", может быть необходим сразу для 2х задач, к примеру - "рулить на мех. коробке"). Реальной выгоды нет.

И, конечно, можно решать проблемы по мере поступления: появится необходимость - перенести данные в другое поле и настроить как нужно. А можно - не создавать таких проблем. Я, лично, давно взял за привычку делать поля "field_article_image", "field_blog_image", "field__image". Это не так сложно, и не требует так много усилий (не целыми же днями клепать бандлики). А таски из разряда "тут ннада также, нно только вот это чу-чуть не так" возникают не если, а когда. Это аксиома. Потому - зачем на этом ловится.

Аватар пользователя bumble bumble 17 июля 2019 в 13:32

Вот, как раз, в настройках поля, в котором параграфы - можно выбирать разные сеты параграфов для разных сущностей (если необходимо разграничить). Хороший пример. Wink

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

Аватар пользователя gun_dose gun_dose 17 июля 2019 в 14:43

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

А теперь представь ситуацию, где поля определяются их назначением, а не сущностью, в которой они будут использоваться. По-хорошему, у полей общие только настройки хранилища - количество допустимых значений, длина, список допустимых значений (у списков). Не так уж трудно просчитать наперёд, нужно новое поле или нет.

Кстати, хороший пример для повторного использования полей: вывести список новостей и книг, помеченных галочкой "выбор редакции". С одним полем задача будет абсолютно тривиальная. С двумя разными полями нужно городить OR в фильтрах, снижать производительность выборки, а если фильтр контекстный, то вообще беда.

Аватар пользователя bumble bumble 17 июля 2019 в 14:55

А теперь представь ситуацию, где поля определяются их назначением, а не сущностью, в которой они будут использоваться.

Я про параграфы, а не про поля. Параграфы (их строение) определяется назначением, а не сущностью в которой оно будет использоваться. Это про ".. типы параграфов для разных полей тоже лучше пересоздавать?". Т.е. - нет, не нужно пересоздавать типы параграфов для разных полей, в разных полях можно выбирать разные сеты параграфов.

Поля как раз сущностью и определяются, или даже они определяют сущность.

Кстати, хороший пример для повторного использования полей: вывести список новостей и книг, помеченных галочкой "выбор редакции". С одним полем задача будет абсолютно тривиальная. С двумя разными полями нужно городить OR в фильтрах, снижать производительность выборки, а если фильтр контекстный, то вообще беда.

Честно - плохой пример.

  • Во-первых, сложно представить реальный кейс в котором нужен список из 2х разных сущностей.
  • Во-вторых, чем так сложен OR (если он вообще нужен, вероятно это обусловлено использованием представлений, хотя может и они хендлят нормально)? И чем контекстный фильтр добавляет нагрузки?
  • И в третьих, с каких пор выборка данных должна хоть как-то влиять на структуру модели?
Аватар пользователя gun_dose gun_dose 17 июля 2019 в 15:04

OR не сложен ничем, просто добавляется дополнительный джоин. А если контекстный фильтр, то там всё просто - он тупо не поддерживает OR в принципе.

И в третьих, с каких пор выборка данных должна хоть как-то влиять на структуру модели?

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

Аватар пользователя gun_dose gun_dose 17 июля 2019 в 15:27

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

Но это неправильно. Здравый смысл должен быть первичен.

Аватар пользователя bumble bumble 17 июля 2019 в 15:36

Эти принципы (которые как раз практические) разрабатывались в годах 90х, если не раньше. Тогда еще совсем не дешево было сервера скейлить, а значит по другим причинам. Но тенденции такие есть, да. Считаю это нормальным, живая эволюция. Проггеры всегда будут нужны, просто квалификация должна расти вместе с общим прогрессом.

А производительность - для сайта она такая же. Для программиста - тоже. Куда хуже когда проект собран как-попало и кем-попало, на их страхи и риски (за которые, внезапно нужно отвечать), и для внесения небольшого изменения требуется неделями хендлить последствия этих изменения, отлавливая их по всему сайту, где не ожидаешь на них. Вот это - снижение производительности.

Аватар пользователя marassa marassa 17 июля 2019 в 15:47

bumble wrote:
сложно представить реальный кейс в котором нужен список из 2х разных сущностей.

Абсолютно реальный кейс. У меня на сайте в виде аккордеона выводятся связанные с текущей нодой ноды разных других типов - под Страной выводятся ее Регионы, Города, Архитекторы, События и Ссылки. Соответственно, под Городом - его Районы, Здания, События и Ссылки. И весь этот аккордеон выводится ОДНОЙ вьюхой, причем реально одной и для Стран и для Регионов и для Городов и т.п. Всё исключительно благодаря повторному использованию полей. Конечно, я мог бы в угоду неверно истолкованным "практикам" создать кучу почти одинаковых полей и кучу почти одинаковых вьюх, застраховать себя от гипотетических проблем в будущем, но при этом устроить себе вполне реальный и каждодневный maintenance nightmare. Мой выбор - так не делать.
Кстати, и на карте у меня динамически, в зависимости от текущего масштаба, маркерами отображаются то здания, то города, то страны, и всё благодаря тому, что поле coordinates у них общее.

Аватар пользователя bumble bumble 17 июля 2019 в 16:12

Блин... Я тут уже себя в роли злодея чувствую, который заставляет бедных друпаллеров их дела делать "правильно", а не так как им говорит Друпал. Дальше лень.

Ради бога. Делайте как считаете правильным. В конце-концов, каждый сам себе архитектор.

Аватар пользователя gun_dose gun_dose 17 июля 2019 в 10:54

иначе зачем они разделены

Иначе зачем впёрли в друпал этот селект "выберите существующее поле"?

заведомо согласиться

В этом нет ничего плохого, когда действуешь обдуманно.

Аватар пользователя bumble bumble 17 июля 2019 в 11:07

Иначе зачем впёрли в друпал этот селект "выберите существующее поле"?

Не знаю точно. Подозреваю, это пережиток времён экономии на таблицах бд. А может, очередной артефакт друпал-вея, навязывающий свое поведение.