Пишем первый аддон для XenForo. MVC, шаблоны, стили, настройки, навигация — используем все!

Что-то на шаге создания свойства стиля после выбора "Скаляр" невозможно выбрать параметр "Цвет" (впрочем, как и любой другой). Что может быть?

 

Попробуйте текущее значение удалить, сохранить, затем попробовать изменить. Хотя проще будет просто удалить это свойство и создать такое же, только другого типа.

 

Все. Разобрался. Это у меня Firefox так себя ведет. В опере все норм. Значит, скорее всего, какое-то дополнение в нем "косячит".

 

Очень похоже на adblock plus

 

У меня такое чувство, что я этот "велосипед" вообще никогда не освою, чисто глаза разбегаются на этих иероглифах и нифига не могу уловить алгоритм всей этой писанины (может мозги пересадить надо, не знаю).

 

Не. У меня он не стоит. Да и фиг с ним. Потом как-нибудь разберусь. Главное, что причина найдена.

 

Сейчас загрузил какой-то плагин, посмотрел его.

По статье допустим я разберусь, фрэймворк тоже покурю. Но я никогда еще не упаковывал код в XML. Надеюсь это не ручками делается? Поделитесь секретом.

 

XML плагина делается путем экспорта его непосредственно из админки ксена. Языковый XML также делается через экспорт прямо из админки. Поэтому можете не беспокоиться о том, как этот файл нужно делать. Руками его делать не придется.

 

это значит, что в файлы ядра лезть не придется. радует. а то извращение наподобие модулей ipb мне совсем не нравится.

 

Лезть придется, но не для изменения, а для исследования

 

Всем привет.​

Долго выбирал движек и остановился на XenForo - даже купил уже.​

Теперь сижу разбираюсь в сём произведении искусства ​

Уважаемые Гуру форума подскажите начинающему Ксенаводу:​

1) тут разве не пропущено в самом конце $routePath может должно быть так:

PHP:

return $router->getRouteMatch('LikeReviewRus_ControllerPublic_Index', 'index', 'likes-review', $routePath);

2) мне во всём примере не понятен принцип указания адреса по которому создается страница и по которому она будет доступна. Если это задается в контроллере, то переменные
'index', 'likes-review' зададут адрес 'index?likes-review' - правильно я понял или адрес задается гдето в другом месте?

3) Откуда взялась переменная LikeReviewRus_ViewPublic_Index - она нигде на фигурирует и каталога ViewPublic нет.

PHP:

return $this->responseView('LikeReviewRus_ViewPublic_Index', 'likereviewrus_index', $viewParams);

4) Обязательно ли называть файл контроллера Index.php или XenForo вообще не смотрит на названия файлов, главное чтобы в нужном каталоге лежали файлы т.к. она лезет во все файлы - компилит их и классы хранит в базе и от туда их вызывает?

5) посидел помедитировал и кажись понял что ответ на 4) вопрос.
к примеру LikeReviewRus_ControllerPublic_Index - это фактически путь к файлу контроллера, правильно понял?

Но на 3) вопрос все равно ответа нет ведь каталога ViewPublic нет.

 

Вовсе нет. Последний параметр опциональный и тут не нужен. Либо в данном случае должен быть пустой.

По идее должно быть index/likes-review.

Похоже на ошибку. Действительно при таком указании должен быть каталог ViewPublic с файлом Index.php внутри.

Имя класса и ссылки на их имена обычно задаются через library/ИмяПлагина/ИмяКласса/ИмяКласса/ИмяФайлаСОписаниемКласса.php, которое преобразуется в ИмяПлагина_ИмяКласса_ИмяКласса_ИмяФайлаСОписаниемКласса. Таким образом символ подчеркивания по факту заменяется на слеш, и фреймворк именно по этому принципу пытается обнаружить описание класса и загрузить его.
Так работает автолодер. Если что-то не до конца понятно, то посмотрите документацию по Zend Framework. Ксен сделан на нем.
Ответ на 5-й пункт - Вы правильно поняли

 

Не должен. папка ViewPublic и конкретные классы в ней создаются только в случае, если надо провести дополнительные манипуляции с параметрами шаблона перед выводом. Или, если нужно выводить разное содержимое (обычный html или json) в зависимости от типа запроса.

 

Ага.
Значит первый параметр: LikeReviewRus_ViewPublic_Index - это предобработчик вывода шаблона.

PHP:

return $this->responseView('LikeReviewRus_ViewPublic_Index', 'likereviewrus_index', $viewParams);

Значит если нам не надо проводить хитрых манипуляций при выводе шаблона.
То мы умышленно даем название НЕ существующего Класса и пути.
Но чтобы никого не путать, соблюдаем структуру названия :
ИмяПлагина_ViewPublic_ИмяPHPфайла

так?
P/S/ я смотрю радко кто внимательно разбарается в коде всё по верхам особо не вдаваясь в смысл. Ведь вопрос лежал на поверхности при внимательном рассмотрении.
Посмотрел другие скачанные хаки. Там такой же прикол - ссылка на не существующий файл (класс).

 

Именно так.

А про внимательность и прочее — исходные коды XenForo достаточно хорошо документированы и если посмотреть в описания методов, то все становится ясно.

ЗЫ. Ссылки на несуществующий класс есть и в самом форуме. Таков механизм работы данного движка. не могу только понять, что вас смущает.

 

Создаю обработчик событий, задаю следующее:

Обрабатывать событие:
navigation_tabs

Выполнить обработчик:
LikeReviewRus_Tabs_MainTab :: addTab

получаю:

Метод "addTab" не корректный?

 

Создайте library/LikeReviewRus/Tabs/MainTab.php потом обработчик

 

Я может не до конца проникся религией движка. Но что тут хорошего когда для создания так сказать модуля надо сделать столько телодвижений по админки форума создав при этом кучку почти одинаковых идентификаторов? Насчитал как минимум от пяти переходов.
Почему бы не сделать отдельный режим под разработку?

 

Причина проста. Плагин (аддон) должен быть максимально абстрагирован от прямых правок оригинального кода, шаблонов и т.д. Это нужно для обеспечения совместимости между плагинами и версиями движка. Правильно написанный плагин как правило вообще не требует каких-то правок при апгрейде движка. Хотя в некоторых случаях все равно требуется вносить правки, но они минимальные. В результате имеем достаточно надежную систему плагинов, которая достаточно легко отлаживается (в различных IDE с дебагерами), а также хорошую безопасность функционирования.
Например, простейший плагин, включающий в код страницы какой-то свой код, должен иметь класс Listener, обеспечивающий вызов своих классов. Для этого требуется повесить свой обработчик на нужное событие. Ну и также должен быть класс для обработки хуков. Ничего сложного. Зато мы можем не беспокоиться, что какой-то плагин нарушит работу нашего плагина. Ведь обработчики вызываются последовательно, при этом вставая в очередь обработки. Единственное, где может произойти накладка - изменение вывода. Если мы его меняем, то должны убедиться, что мы его корректно меняем. При этом, в случае необходимости можно скорректировать последовательность вызовов. Ну и т.д. и т.п. В общем для программиста это не является сложной задачей.
В более сложных плагинах используется техника перегрузки оригинальных классов, используют фразы и т.д.

Естественно, таким образом достигается упорядоченность кода и его использования. Те же фразы легче редактировать через фразы, а не непосредственно в шаблонах. Ведь так? Да еще и добавляется возможность использования сразу нескольких языков. Все прозрачно и достаточно просто. Ну и главное - функционально.

Уже много программистов оценили удобство разработки под XenForo. Главное при этом - обеспечивается хорошая безопасность и совместимость кода и вводимых данных. Да и доступ к базе данных через движок также с одной стороны усложняет работу программиста (приходиться писать вроде как лишний код типа моделей), но с другой стороны снижает вероятность ошибки программиста, которая может привести к деградации безопасности. Да и предусмотреть с нуля безопасность и корректность действительно крайне сложно. Проще использовать уже отлаженные и предусматривающие многие нюансы использования классы и методы движка.

Короче - читайте статьи по тому же Zend Framework. На нем основан XenForo. Поэтому почти полностью наследует и всю его идеологию. Плюс добавляет хороший визуальный инструмент разработки, шаблоны и т.д.

 

magento страшным скриптом казался, а ведь тоже основан на Zend Framework))) А все оказывается лежит на своих местах! И очень даже удобно потом, когда знаешь что и с какой полки брать! MVC рулит! Просто все привыкли к другому подходу...