Класс, содержащий только константы. Хорошо или плохо.

  • Автор темы Автор темы Adelf
  • Дата начала Дата начала
Есть пользователь "вася", есть ресурс, "просмотр счетов" приходит управляющий запускает уи нажимает на кнопку "добавить роль" пишет имя роли "младший научный бухгалтер", нажимает на кнопочку "добавить права", выбирает "просмотр счетов", нажимает на кнопочку "выбрать пользователей для этой роли" нажимает на "вася".
 
@WMix, допустим есть у тебя кнопка, которая должна быть видна только тем у кого есть право ее нажать. Как это будет выглядеть у тебя в коде? Ведь тебе надо в коде както идентифицировать нужный пермишен.
 
допустим есть у тебя кнопка
если мы о view вероятнее всего {% if user.hasRoute('modul.controller.action.name') %}<button />{% endif %} где 'modul.controller.action.name' это значение из routes.conf массива некий алиас ресурса...
и да этот же алиас записан в базе. чаще будет все на js нарисовано хотя в конечном счете всегда проверка на существование ресурса у данного пользователя.
 
основа кстати это дай меню на уровень, а дальше foreach и render() и нет алиасов. но возможность по алиасу тоже есть
 
$app['twig']->registerFunction('hasRoute', ...) совершено не важно как это называется в данном контексте
 
если мы о view вероятнее всего {% if user.hasRoute('modul.controller.action.name') %}<button />{% endif %} где 'modul.controller.action.name' это значение из routes.conf массива некий алиас ресурса...
и да этот же алиас записан в базе. чаще будет все на js нарисовано хотя в конечном счете всегда проверка на существование ресурса у данного пользователя.
О том и речь, что у тебя везде будет распихано 'modul.controller.action.name'
Но это твое упрощенное acl по роутам, которое в случаях кастомного поведения одного роута для разных ролей - не работает. Ну, когда в роутере user/update в зависимости от роли можно менять разные поля. И тогда появляются дополнительные проверки, типа hasRoute('user/update') && hasPermission("update_private_field"). И вот эти все строки, означающие действия (включая те же роуты в твоем случае) и есть константные строки.
Которые можно вынести в константы, ибо автокомплит и все такое, т.е. вероятность ошибки в написании меньше. А если их вынести в константы, то и строки не нужны, можно вернуться к магическим числам.
Я бы это написал как $ACL->canDelete($User).
Внутри все равно будет проверка на какое-то значение базы.
 
  • Like
Реакции: AmdY
когда в роутере user/update в зависимости от роли можно менять разные поля

Зачастую это, кстати, проблема самого REST-подхода, когда какой-нибудь json-rpc с разными методами был бы намного уместнее и проще в разработке и поддержке, но зачем-то упарываемся по restful и сами себе создаем проблемы.

Это не аргумент против остального, а так, в сторону.
 
hasPermission("update_private_field"). И вот эти все строки, означающие действия (включая те же роуты в твоем случае) и есть константные строки.
Которые можно вынести в константы, ибо автокомплит и все такое, т.е. вероятность ошибки в написании меньше. А если их вынести в константы, то и строки не нужны, можно вернуться к магическим числам..
Не универсально.
- Если будет админка, где админ должен иметь возможность проставлять ролям или пользователям вот эти права, то просто какого то магического числа не достаточно. Право нужно представить человеко понятным образом - на текущем языке, в нужной категории прав, в определенной позиции.
- Есть еще права, существующие динамически. Например создал меню, появилось право "управлять меню_Имя_меню" . Строками универсально получается.
 
Если будет админка, где админ должен иметь возможность проставлять ролям или пользователям вот эти права, то просто какого то магического числа не достаточно.
Ты же не показываешь им строку-идентификатор, да, скажи, что да ;) Описание в базе можно держать с каким угодно полем
Есть еще права, существующие динамически. Например создал меню, появилось право "управлять меню_Имя_меню" . Строками универсально получается.
Да, может быть удобнее. Хотя я бы думал в таких случаях об одельном храненни прав работы с меню в базе, что-то вроде многие-многие.
 
О том и речь, что у тебя везде будет распихано 'modul.controller.action.name'
это вью, там и другие "константные" значения прописывают (элементы формы), нет смысла для этого прописывать константы, довольно частая ситуация что там блоками хардкодят, для вью все нормально
 
это вью, там и другие "константные" значения прописывают (элементы формы), нет смысла для этого прописывать константы, довольно частая ситуация что там блоками хардкодят, для вью все нормально
Какая разница вью или не вью? Блин, 95% твоих постов я просто не могу понять.
 
Какая разница вью или не вью? Блин, 95% твоих постов я просто не могу понять.
разница большая, там и php та уже нет. при удобном дизайне можно было бы циклом пробежаться и в ряд нагенерить, но такого же нет, нужно в разных местах кнопочки расставлять, да и не только кнопочки,
а в этом случае тебе нужно на чтото опираться, и набор рут тут ни каким боком...

для сравнения, представь что группы записаны только в коде, константами и представь все места где эти значения групп будут использованы
 
@WMix ты опять пытаешься всех обмануть. В шаблоне у тебя обычная строковая константа вместо именованной из-за отсутствия возможности; если бы она была, ты бы скорее всего использовал именованные, поскольку профит очевиден: индексация IDE.
 
  • Если view это soap, или js кому нах нужны твои константы, тут нужен wsdl или json при особом желании их можно и нагенерить некой командой, нагенериРесурсыВПхпКонстанты, и поставить фильтр. Тебе лично нужен за пределами представления константа? , да пиши!
 
  • Если view это soap, или js кому нах нужны твои константы, тут нужен wsdl или json при особом желании их можно и нагенерить некой командой, нагенериРесурсыВПхпКонстанты, и поставить фильтр. Тебе лично нужен за пределами представления константа? , да пиши!
А чем отличается soap или html в нанном случае? В html тебе нужно условие в if, что бы кнопку нарисовать, в soap - выдать значение поля canDance.
 
Нет, в всдл у тебя просто небудет описания того, на что у тебя нет прав
 
Вообще я не про это, но ладно. "Нет, в всдл у тебя просто небудет описания того, на что у тебя нет прав" - оно там в wsdl магически пропадет? Или ты где-то в коде генерации wsdl поставить if с проверкой прав?
 
Сверху