Переопределение. Будет ли конфликт? Как определить не зная кода иного плагина.

Прочитал Новые возможности по переопределению/наследованию классов LiveStreet, но так и не понял, как быть в ситуации, если мне, например, требуется переопределить маппер одного из модулей, а я не знаю, переопределен ли он уже иним плагином?

Например, работаю через
protected $aInherits=array(
        // Переопределяю маппер 
        'mapper'  =>array('ModuleComment_MapperComment')
    );


Переопределяю один из стандартных методов маппера комментариев: например добавляю работу с дополнительными полями таблицы комментариев
К примеру, этот метод класса /classes/modules/comment/mapper/Comment.mapper.class.php

public function GetCommentsRatingByDate($sDate,$sTargetType,$iLimit,$aExcludeTarget=array(),$aExcludeParentTarget=array())


Как мне узнать, не был ли уже этот метод переопределен другим плагином? Что будет, если он уже был переопределен? И нужно ли мне сообщать другим плагинам, что я переопределяю этот метод? Ну что бы не было конфликтных ситуаций…

20 комментариев

avatar
Как мне узнать, не был ли уже этот метод переопределен другим плагином?
получить объект маппера и прочитать имя его класса. потом имя отца, потом имя деда в цикле %)
так узнаешь всю цепочку

Что будет, если он уже был переопределен?
выполнится последний в цепочке

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

магический sql-билдер у нас не прижился, посему в мапперах имеем сырые sql-запросы.
в общем, ситуация с мапперами такая же унылая, как и с переопределением шаблонов.
avatar
Т.е., если я переопределю в плагине через $aInherits один из методов маппера, выполняющего sql-запрос, то поставлю под удар все плагины других разработчиков? Или они мой…
Получается так?
avatar
да
avatar
Хм… а как тогда быть, если один разработчик, например, для расширения возможностей комментариев, переопределил в своем плагине класс маппера, добавив работу с доп. полем в таблице комментов, фактически переписав sql-запрос… то что делать другим разработчикам в этой ситуации?

И как не подвести других, если пишешь плагин?

Банально, я хочу переопределить метод
GetCommentsRatingByDate
, добавив в его sql запрос обработку своего поля…

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

class PluginName_ModuleComment_MapperComment extends PluginName_Inherit_ModuleComment_MapperComment {
public function GetCommentsRatingByDate($sDate,$sTargetType,$iLimit,$aExcludeTarget=array(),$aExcludeParentTarget=array()) {

//Мой код тут

}
}
avatar
Это опасно для других?:

class PluginName_ModuleComment_MapperComment extends PluginName_Inherit_ModuleComment_MapperComment {

public function GetCommentsRatingByDate($sDate,$sTargetType,$iLimit,$aExcludeTarget=array(),$aExcludeParentTarget=array()) {

    //Мой код тут

}
}
avatar
Я бы и сам непротив это услышать ответ на этот вопрос
avatar
Да никак. Это проблема всех кодописов ЛС. Каждый пишет, как умеет, типа по-аналогии. Нет четких стандартов. Поэтому и конфликтов куча. А возьми тот же Друпал. Там 3000 модулей, которые пишут кодописы со всего мира. А конфликтов мало. Потому, что есть общепринятые стандарты.
  • aex
  • 0
avatar
Так это поэтому ДРупал почти уже умер?
avatar
Ну почему так уж и умер? :))) Обама свой Белый Дом еще на нем держит :)
avatar
Я ориентируюсь на вот habrahabr.ru/post/149590/
avatar
А я ориентируюсь на свой опыт. Давно друпалю. Да и заказчик, когда проект выбирает, хочет, чтобы на общеизвестном движке работал. Типа, мой сайт на Друпале! Это для многих звучит круто :)))
avatar
Друпалу куева туча лет. И не сразу пришли они к стандартам. LS — очень перспективный двиг, и, думаю, что стандартизация не менет и его.
avatar
Ну, не такая и куева. 12 лет. Сейчас семерока даже очень ничего. А для развития ЛС очень нужен свой бесплатный СКК. И лучше не в виде плагина, а встроенный в ядро. Тогда ЛС заиграет.
avatar
А вообще, было бы хорошо, чтобы к каждому плагину шла малява, типа, переопределил то-то и то-то, делегировал туда-то и туда-то, поломал это и там-то. Чтобы можно было ориентироваться, где еще можно самому напакостить :)
  • aex
  • 0
avatar
Так для этого есть главный класс плагина. Там все и видно.
avatar
Как видишь, не всем. И это надо лазить туда смотреть. А так всем на обозрение, общий список по всем плагинам, что, где, когда.
avatar
Если вы об авторе вопроса, то он не об этом спрашивал, имхо. А о том, как избежать конфликтов. Если он пишет плагин и спрашивает про $aInherits, думаю, он видит список переопределений.
avatar
Вот и я столкнулся вчера с подобной проблемой. Делал плагин-поток для вывода на главной странице по последним изменениям в топике (добавление комментария, редактирование топика).
Отладил у себя, все работает гладко. Устанавливаем на сайте заказчика… Работает не так, как надо.
Оказывается, один из уже установленных плагинов переопределяет тот функционал, который нужен моему плагину.
Там где безболезненно для остальных плагинов, можно было сделать Хуком в пару строчек, почему то переопределяются методы, с большой вероятностью важные для других плагинов.
В итоге приходится делать хук, «восстанавливать» переопределенный и убитый функционал… Выискивать зависимости в других планинах…
Неудобно. Очень. В идеале, разработчик плагина должен быть зависим только от движка. А в итоге получаем, что разработчик плагина зависим от разработчиков всех других плагинов. Нет централизации и независимости.
avatar
В идеале, разработчик плагина должен быть зависим только от движка. А в итоге получаем, что разработчик плагина зависим от разработчиков всех других плагинов.
Святые слова… И теперь, когда разработчиков плагинов под LS уже достаточно много их «модерация» перед попаданием в каталог должна включать и проверку на какие-то очевидные вещи, способные поломать другие плагины. Типа переопределение методов, без вызова родительских методов и т.п. А то ставишь плагин и начинаешь играться с plugins.dat для достижения правильного эффекта…
avatar
Все правильно. Для этого и модерация существует, чтобы проверить все плагины на совместимость и отправить на доработку в случае чего.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.