Проблема с наследованием MapperTopic

XText
У меня есть плагин, который, в том числе, наследует ModuleTopic_MapperTopic… Так вот, поскольку XText переопределяет, например, метод UpdateTopic вусмерть, без всякого вызова методов родительских классов, весь функционал летит к чертям… Как-то совсем «не айс».

Так вот, вопрос… Есть ли возможность как-то это дело обойти без острых углов? Пробовал наследовать от PluginXtext_ModuleXtext_MapperTopic… Не особо помогает. Т.е. полностью игнорирует такое наследование. Да и вообще — не выход. Ведь еще могут быть плагины, использующие наследование мэппера…

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

avatar
есть два варианта
1. xtext поставить первым в списке плагинов
2. написать мега-магический код в энтити топика, который бы дергал debug backtrace и смотрел бы есть ли в цепочке вызовов MapperTopic и тогда геттеры отдавали бы для именно этой цепочки текст с необработанными entity-тегами.

1 — быстрый костыль
2 — сложная магия, но универсальная, при этом можно было бы обойтись вообще без переопределения мапперов
avatar
Ээээ… Проблема не в энтити и не в геттерах, проблема в том, что при апдейте топика я хочу делать свои манипуляции с БД, а т.к. ваш плагин не вызывает никаких родительских методов, то и, соответственно, мои манипуляции тоже не происходят.

Честно говоря вообще не понял необходимости так жестоко поступать — в смысле совсем переопределять — функционал движка. Это же вообще, можно сказать, краеугольный камень. Такие вещи, по-моему, совсем нельзя делать… Или делать опционально через конфиг. Ведь, насколько я понимаю, особой необходимости в этом не было, кроме как использовать именно ваш функционал работы с БД.
avatar
Да, и первым в списке делал, получалась вообще какая-то ересь. Щас уже не помню что конкретно, и времени ковыряться нет. :(
avatar
другого пути просто не было =(
avatar
Почему?!?? Насколько я вижу, вы просто заменили лайвстритовский движок БД своим, сократили апдейт, чтобы потом записать в поля значения по-своему…

Но… Неужели ничего нельзя было придумать, без нарушения цепочки наследования? Ну… Например своему переопределенному EntityTopic придумать какой-нибудь флаг, при котором в переопределенном, например, getText() берется не родительский getText(), а вызывается getXtextTextRaw()? И перед вызовом родительского Update() устанавливать это флаг?
avatar
функционал рождался в муках через кучу дебрей и я уже не помню, почему это решение получилось единственно возможным.
щас пробую замутить магию с debug_backtace
avatar
Ну попробуйте…

«Any sufficiently advanced technology is indistinguishable from magic» © :))
avatar
получилось, могу выслать для тестов, если есть время и интерес
avatar
Честно говоря, не совсем въезжаю при чем тут энтити и необработанные тексты…
я же писал
Проблема не в энтити и не в геттерах, проблема в том, что при апдейте топика я хочу делать свои манипуляции с БД, а т.к. ваш плагин не вызывает никаких родительских методов, то и, соответственно, мои манипуляции тоже не происходят.
Т.е. у меня есть плагин, который переопределяет метод Update стандартного MapperTopic. Так, как вы НЕ вызываете родительский Update, то и мой Update НЕ вызывается. Вот в чем проблема, а не в не/обработанных текстах…
avatar
суть в том что из энтити мне нужно подставить другие геттеры в запрос, отличные от оригинальных.
avatar
попробуйте обновить engine из svn, там эта проблема решена больше полугода назад
avatar
Стоит из SVN ревизия 1054, вроде как месяца 3 назад делал. А какая конкретно проблема решена?
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.