Переопределить функции ядра
Добрый день. Есть необходимость переопределить методы классов ядра (xPDO, modResource) так, чтобы изменения не затирались при обновлении. Как это лучше сделать?
Комментарии: 12
Создать свой класс, расширяющий modResource.
Нужно переопределить, а не расширить. Все объекты текущего класса должны работать с новой функцией. Т.е. если это modResource, то новая функция переопределена для всех
$modx->getObject('modResource');
во всем коде.
Если не секрет: Чего вы пытаетесь добиться от переопределения и чем не устраивает оригинал?
Есть проект с несколькими корневыми разделами и большим количеством документов. Для каждого раздела должны быть свои контент-менеджеры. Чтобы правильно распределить права между менеджерами, нужно каждому ресурсу задать группу ресурсов, а это долго и неудобно. Удобнее поместить в группу только родительский раздел, пометив его tv-параметром «Наследовать права».
Собственно это я и сделал, переписав метод findPolicy в modResource.
Собственно это я и сделал, переписав метод findPolicy в modResource.
Какой же молодец! Как же я люблю подобные извращения, вызванные не желанием открыть и прочитать пару умных книг.
Если включить голову и задуматься о том, как происходит загрузка ресурса, то не сложно догадаться, что сначала идет проверка прав на загрузку из БД данных для ресурса, а дальше идет проверка прав на их просмотр. Ну и если эти права есть, то только после этого вообще должна начаться загрузка ТВ у ресурса, по ходу которой для каждой ТВ будет производиться аналогичные проверки прав на просмотр и т.д.
В вашем случае все наоборот ТВ -> РЕСУРС ->ТВ. И это не верно, т.к. у недоступного для пользователя ресурса значения ТВ тоже будут недоступны и следовательно при вашем «алгоритме» все через задницу. Словно сундук на замке, ключ от которого лежит внутри этого сундука.
В вашем случае все наоборот ТВ -> РЕСУРС ->ТВ. И это не верно, т.к. у недоступного для пользователя ресурса значения ТВ тоже будут недоступны и следовательно при вашем «алгоритме» все через задницу. Словно сундук на замке, ключ от которого лежит внутри этого сундука.
Чтобы не быть голословным, приведите пожалуйста ссылки на умные книги, где описанная задача с правами решена.
Есть очень конкретный запрос от пользователя — переносить в группу один ресурс, а не ресурс и все его дочерние элементы. И пользователя не интересуют особенности проверки прав в MODX.
Алгоритм работает, проверку прав на ТВ я обошел. Изначальный вопрос алгоритма вообще не касался. Но если у вас есть решение элегантнее, то опять же — поделитесь.
Есть очень конкретный запрос от пользователя — переносить в группу один ресурс, а не ресурс и все его дочерние элементы. И пользователя не интересуют особенности проверки прав в MODX.
Алгоритм работает, проверку прав на ТВ я обошел. Изначальный вопрос алгоритма вообще не касался. Но если у вас есть решение элегантнее, то опять же — поделитесь.
Я бы написал плагин на сохранение ресурса, с проверкой его группы и переносом в неё потомков.
В данной книге поставленная задача не решается.
Да и не забудьте сначала вернуть к первоначальному виду класс modResource.
Небольшое дополнение — при сохранении ресурса проверять группу родителя (-ей) и переносить в соответствующую. Чтобы механизм работал не только при сохранении родителей.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.