Пара быстрых вопросов
Всем доброго времени суток!
Ребят, скопилось у меня тут пара-тройка вопросов, кто что знает — подскажите, пожалуйста.
1. Права доступа. Вот с ними разобрался, вроде всё логично:
— создаём политику доступа (или изменяем существующую) на основе заготовленных разработчиками шаблонов (разрешая одно/запрещая другое);
— создаём группы пользователей, связываем группы с политиками;
— если надо — создаём группы ресурсов и связываем их с группами пользователей.
Одного не пойму — каким боком здесь роли? Это мифическое для меня понятие обладает лишь таким же мифическим рангом. Если со значением ранга (0-9999) всё понятно, то не понятно как ранги этих ролей влияют на перечисленные выше взаимосвязи…
2. Вот есть такой процессор «resource/duplicate» (не суть важно), логику которого мне надо слегка поменять. Ну здесь тоже вроде всё понятно, создаём свой процессор, наследуясь от нужного и подменяем необходимые методы. Но в процессе изучения метода «process» этого процессора, обнаружилось, что основную задачу выполняет метод «duplicate» класса «modResource», т.е.
Метод этот лежит здесь, т.е. в «core/model/modx/modresource.class.php». И вот как назло, именно этот метод содержит логику, которую необходимо видоизменить.
Вопрос — можно ли как-то прозрачно подменить метод в этом классе для всех объектов modresource? Или как-то добавить туда новый метод? Чувствую я, что дорога мне в сторону CRC, но что-то нет желания из пушки по воробьям стрелять…
3. Тупой вопрос, но лучше перестрахуюсь и уточню… Как правильней обновить систему? :-)
Качаю всегда advanced-дистрибутив, который содержит только папки «core» и «setup». Можно ли папку «core» кидать с заменой уже существующей? Ничего там лишнего не перетрётся?
Ребят, скопилось у меня тут пара-тройка вопросов, кто что знает — подскажите, пожалуйста.
1. Права доступа. Вот с ними разобрался, вроде всё логично:
— создаём политику доступа (или изменяем существующую) на основе заготовленных разработчиками шаблонов (разрешая одно/запрещая другое);
— создаём группы пользователей, связываем группы с политиками;
— если надо — создаём группы ресурсов и связываем их с группами пользователей.
Одного не пойму — каким боком здесь роли? Это мифическое для меня понятие обладает лишь таким же мифическим рангом. Если со значением ранга (0-9999) всё понятно, то не понятно как ранги этих ролей влияют на перечисленные выше взаимосвязи…
2. Вот есть такой процессор «resource/duplicate» (не суть важно), логику которого мне надо слегка поменять. Ну здесь тоже вроде всё понятно, создаём свой процессор, наследуясь от нужного и подменяем необходимые методы. Но в процессе изучения метода «process» этого процессора, обнаружилось, что основную задачу выполняет метод «duplicate» класса «modResource», т.е.
public function process() {
// ...
/*...*/ $resource->duplicate(array(
'newName' => $this->getProperty('name',''),
'duplicateChildren' => $this->getProperty('duplicate_children',false),
// блаблабла
));
// ...
}
Метод этот лежит здесь, т.е. в «core/model/modx/modresource.class.php». И вот как назло, именно этот метод содержит логику, которую необходимо видоизменить.
Вопрос — можно ли как-то прозрачно подменить метод в этом классе для всех объектов modresource? Или как-то добавить туда новый метод? Чувствую я, что дорога мне в сторону CRC, но что-то нет желания из пушки по воробьям стрелять…
3. Тупой вопрос, но лучше перестрахуюсь и уточню… Как правильней обновить систему? :-)
Качаю всегда advanced-дистрибутив, который содержит только папки «core» и «setup». Можно ли папку «core» кидать с заменой уже существующей? Ничего там лишнего не перетрётся?
Комментарии: 6
1. Внутри одной группы можно сделать несколько уровней доступа, так как политика назначается с учетом роли. То есть, будет группа менеджеры, а внутри:
— Главный менеджер, с политикой Administrator
— Обычный менеджер — Content Editor
— Копирайтер — Text edit only
Это надо для очень больший сайтов с толпой юзеров, я пока не пользовался.
2. Ты можешь реализовать всю эту логику в своём процессоре. Но вообще да, так сделанно именно для CRC. Например, товары MS2 дублируются немного иначе, чем обычные ресурсы.
3. Да, просто накатываешь сверху setup и core, а потом обновляешь. Чтобы не было проблем — сначала сделай бэкап. Важный файл там только один — config.inc.php, он не затирается.
Лично у меня все обновления завершались без ошибок.
— Главный менеджер, с политикой Administrator
— Обычный менеджер — Content Editor
— Копирайтер — Text edit only
Это надо для очень больший сайтов с толпой юзеров, я пока не пользовался.
2. Ты можешь реализовать всю эту логику в своём процессоре. Но вообще да, так сделанно именно для CRC. Например, товары MS2 дублируются немного иначе, чем обычные ресурсы.
3. Да, просто накатываешь сверху setup и core, а потом обновляешь. Чтобы не было проблем — сначала сделай бэкап. Важный файл там только один — config.inc.php, он не затирается.
Лично у меня все обновления завершались без ошибок.
Василий, спасибо огромное!
И ещё один вопрос можно? Сразу что-то забыл про него…
При установке своего компонента, создаю системную настройку. Настройка эта находится в правильном неймспейсе (в списке настроек меняю значение комбобокса с «core» на «mycomponent» и вижу её в списке). Но вот если я её получаю через:
Но ведь это никуда не годится… Если у любого другого компонента будет настройка с таким же именем или, что ещё хуже, есть системная настройка с таким же именем?
Вот не хочет настройка получаться через указание неймспейса и всё тут. В чём проблема — не знаю. Может сталкивался?
И ещё один вопрос можно? Сразу что-то забыл про него…
При установке своего компонента, создаю системную настройку. Настройка эта находится в правильном неймспейсе (в списке настроек меняю значение комбобокса с «core» на «mycomponent» и вижу её в списке). Но вот если я её получаю через:
$modx->getOption('mycomponent.mysetting');
, то получаю «NULL», а если через $modx->getOption('mysetting');
, то правильное значение.Но ведь это никуда не годится… Если у любого другого компонента будет настройка с таким же именем или, что ещё хуже, есть системная настройка с таким же именем?
Вот не хочет настройка получаться через указание неймспейса и всё тут. В чём проблема — не знаю. Может сталкивался?
Поэтому все нормальные компоненты делают настройки с префиксами, типа ms2_option.
Неймспейсы на данный момент для красоты.
Неймспейсы на данный момент для красоты.
Оу, не знал… А почему во всех компонентах и сниппетах, какие не посмотри, везде используется, к примеру,
$modx->getOption('mycomponent.core_path');
? Да, конечно, делают проверки и подставляют значения по умолчанию, но неужели это просто задел на будущее?
Ну так у них и параметры также называются, через точечку. А у меня через дефис =)
Так принято, другой причины не знаю.
Так принято, другой причины не знаю.
Ну так у них и параметры также называются, через точечкуАаа! Эвона как © Не знал, что так можно :-) Спасибо!
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.