Вопрос терминологии

Один мудрый человек сказал: в действительности понимает явление только тот, кто способен рассказать совершенно несведущему суть явления буквально на пальцах так, чтобы несведущий его понял.

Для меня таким явлением в одночасье стала ксенфоро со всеми цепляющимися к этому атрибутами.
Есть задача её нужно решить. Человек которому я смог доверять отказал мне в решении задачи за деньги сославшись на занятость. Думаю что у негодействительно были для этого причины. Пришлось начать решать задачу самостоятельно. Теперь втянувшись в процесс уже не хочется бросать.

По скольку я привык решать вопросы концептуально, то и к этому вопросу решил подойти так-же.
Пассив:
1. Знания о программировании постановке задач и архитектуре ПО: Хорошие, но уже пыльные. Минимум 15 лет прошло с тех пор как я что-то на чем-то кодил, не говоря уже о административной работе.
2. Желание разобраться, умение найти способ это сделать, гибкость ума, настойчивость: Всё на высшем уровне.
3. Понимание MVC, ООП, важности понимания архитектуры: тоже весьма пыльное но не фатально.
4. Техзадание написанное мной самим: Плюс в том что я сам-же могу его править по необходимости.
5. Знания по администрированию серверов: Как выяснилось недавно, тоже запылились. Не было последине несколько лет задач связанных с вебом.
Актив:
1. Полное не знание языков программирования на которых прийдется работать: php, html/css. Даже описание атрибутов тегов приходится иногда смотреть в учебнике. Благо есть гугл.
2. Полное не знание архитектуры базового продукта: Ксенфоро увидел тогда впервые.
3. Наличие сверхзадачи: Выбора нет, мне прийдется написать то что задумано.
4. Время: Так как я работаю сам на себя и не плохо зарабатываю тратя на это минимум времени, свободное время есть.

Вот с таким раскладом было принято решение бросить искать исполнителя для проекта и заняться учебой и практикой.

Сразу-же торжественно столкнулся с трудностями. Нормального учебника с хорошими практическими примерами нет ни для php, ни для html/css и уж тем более для ксенфоро. По крайней мере на русском языке. То что есть, в лучшем случае справочники по командам. Вспомнились с тоской времена появления дельфи и их прекрасного мана, на русском языке, по продукту и ООП. Но не суть работаем с тем что имеем.

Огромное спасибо Фракталайзеру за его перевод вот этого мануальчика. К сожалению сам мануал мало что дает в вопросе понимания происходящих в ксене процессов, но зато дает возможность почувствовать что ты смог это создать.

Собственно топик создан для тех кто прийдет к ксене с таким-же нулем знаний как и я. Плагин задуманный мной объемный, потребует использовать, как я полагаю, максимум сторон её базового функционала. И полагаю что сможет помочь не тратить время зря копаясь в груде гугловского мусора начинающим.

Что бы я хотел увидеть в топике:
1. Конструктивную критику моих действий. Но с учетом что знания нулевые.
2. Отсылки на почитать. Но только максимально конкретные. Ссылка и указание где именно читать и почему. Я не выношу RTFM-щиков. Что значит термин RTFM гугл еще помнит. Мне плевать что Вы знаете много и дошли до всего своим умом, это не дает вам права тыкать этим. Или делитесь знаниями, или Вам тут не место.
3. Вопросы от новичков. Но тоже конкретные и тщательно сформулированные на уровне темы топика. Я буду стараться разбирать их даже если это будет уходом в сторону.

Думаю что вступительное слово на этом можно завершить и начнем.

================================================

Первое с чем я столкнулся это с непонимание структуры данных и общими способами передачи данных и событий. Пока мы в пределах php, вроде всё понятно. Но как только мы начинаем пытаться понять это на уровне ксенфоро всё встает с ног на голову.

Понятия class (класс), object (объект), method (метод), property (свойство), понятны и логичны это ООП.
Но термины хук, контроллер, листенер, хэлпер, фраза, роутер - загадочны.
Не ясно что для чего нужно, что с кем и в каких случаях взаимодействует и главное как куда и при каких условиях передаются данные.

Я буду вести в таком виде справочник терминов:
Фраза - phrase: наименование некоей текстовой переменной ксенфоро.
Способ обращения: {xenhrase Description}
Обычно используется в локализации аддона. В шаблоне в момент рендеринга страницы вместо {xenhrase Description} подставляется содержимое поля "Текст фразы".
Данные через фразу могут передаваться только в таком виде:
Содержимое поля текст фразы: Статус авторизации {numPosts}.
Обращение к фразе: {xenhrase Description, 'numPosts={xen:number $secParams}'}
Итоговый результат выводимый в браузер: Статус авторизации 3. Если значение переменной $secParams равно 3.

 

Ну и не выносите дальше. Если Вам плевать на то кто что знает, и как он эти знания получил, то мне например глубоко плевать на все Ваши вопросы. И меня очень бесят вопросы, когда нельзя дать правильный ответ, т.к. спрашивающий просто не поймет этот правильный ответ.

На все Ваши вопросы практически первым ответом давали правильное направление - где смотреть и что почитать, но Вас сильно не хватает базовых занний php и Вы пытаетесь разобраться с XenForo не разобравшись в php, ооп и mvc.

P.S. При знании php на среднем уровне (чуть выше Junior-а) только исходников XenForo достаточно для понимания того как он работает (один из немногих движков с относительно современным фреймворком и вообще с понятными внутренностями)

 

А я не спорю. Вам решать делиться знаниями или задирать нос и считать что общаться с недоучками удел не ваш. Я даже Вас в этом не обвиняю. Это вопрос личный.

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

Ну допустим в вопросах ООП я не так уж и слаб. А вот касательно php, mvc (хотя это вообще спорная тема) и ксенфоро я полный профан. Зато быстро учусь.

Наверное Вы правы. Знаний php на уровне новичек++ достаточно для того чтобы понять как работает ксена просто полистав исходники. Хоть это и спорно. Разобраться в ООП только листая исходники продукта написанного на C# даже имея знания языка, без понимания принципов работы ООП близко к не реальному.

P.S. Может быть я вообще зря этот топик затеял... Если все знатоки отреагируют так-же как вы, то.... В общем я расстроен.

 

@AfterWork, купите и прочтите от корки до корки книгу PHP: объекты, шаблоны и методики программирования. Когда я столкнулся с тем, что у меня было почти полное отсутствие знаний объектно-ориентированного программирования в PHP, да и сам PHP мною был мало изучен, я выписал по интернету книжку и прочитал ее. И поверьте, после этого я уже вполне осмысленно смотрел на код Zend Framework и XenForo. Ну а знания HTML и CSS у меня и сейчас очень посредственные.
Книгу я купил именно для того, чтобы писать под XenForo. Тоже появилась задача, которую нужно было решить. Так что не надо сопли распускать, а просто обложитесь книжками, примерами и изучайте. Я это советую Вам именно по своему собственному опыту. Причем и стартовый набор знаний и поставленная задача, уверен, весьма похожи на Ваши.
Если бы я стал заваливать всех своими вопросами без соответствующих полученных знаний, то я также, как и Вы, в результате бы обиделся на сообщество. Будьте адекватными сообществу, у которого Вы просите помощь. Тогда и помощь станет адекватной для Вас.

 

Давайте я поищу в гугле за вас (все определения ниже - это копипаста из гугла):

Хелперы, как говорит их название, помогают в решении ваших задач. Каждый файл с хелперами — это простая коллекция функций в той или иной категории.

Контроллеры - это сердце вашего приложения. В контроллере определяется как необходимо реагировать на тот или иной запрос. Звучит абстрактно, но по факту это опять-таки коллекция функций.

Listener - ну вроде банально же, из названия можно понять что это "слушатель", а что можно слушать в XenForo? Можно слушать события - парсинг ббкодов, написание сообщений, загрузку страницы и т.п.

Роутер - вот вам ссылка на Zend Framework, там расписано что это такое. http://framework.zend.com/manual/1.12/ru/zend.controller.router.html

---

А узнать XenForo можно исключительно лишь листая его исходники и смотря примеры других аддонов. Никакой внятной документации вы не найдете.

 

Я бы сказал что это даже не надо гуглить - надо просто изучать практики программирования на современных фреймворках, современные шаблоны и методики проектирования, потому что даже у джуниора писавшего хоть немного на любом из современных фреймворков таких вопросов нет (и это могу сказать по собственному опыту, т.к. я обучил не одного джуниора). Единственный вопрос, который возникает у большинства - это динамическое наследование, но в данном случае его не объяснить если у Вас отсутствуют базовые знания.

Программированием должен заниматься программист, а не менеджер/продавец/администратор/и т.д. (выбрать нужное). Хотите сами программировать, то становитесь программистом (хоть на время). А это значит изучение кучи документации и прочтение кучи исходников + написание довольно большого количества кода для проверки своих знаний. Если же не хотите - то оставьте это специалистам.

А вы сейчас просите объяснить квантовую физику человеку без знаний математики.

Просто здесь форум обсуждения XenForo, а не форум обучения php. Например было недавно обсуждение работы парсинга ббкодов xenforo на стороннем сайте и когда вопрос был конкретный, то и был поставлен конкретный ответ. Но вот по Вашей теме "Создание собственной таблицы в БД форума" видно что Вы не хотите разбираться, а хотите чтобы сообщество все сделало за Вас, под видом объяснения "а как это работает". Я не всегда согласен с @infis-ом особенно в плане кода, но в данном случае он дал 100% правильный и корректный ответ.

 

Да я не распускаю сопли. Это последнее что стоит делать в моём случае. Толку и продуктивности от распускания соплей ровно ноль. Да и для обижаться я уже несколько староват. Просто было вдруг странно и неожиданно вновь столкнуться с такой ситуацией.

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

Спасибо. Всё это я уже как-бы находил. Но всё это не объясняет как и в каком случае правильно использовать тот или иной инструмет. В каких случаях как и куда и когда мигрируют в системе данные. Просто концептуально это не ясно. А читать исходники не понимаю концепции продукта, как бы это глупо не звучало, просто не продуктивно. Смотришь на исходник как баран на новые ворота.

Это я уже давно понял. Нет не то что внятной документации, никакой нет. Ну по крайней мере на русском языке.
--- добавлено : Jul 27, 2015 8:55 AM ---

Вот как бы смешно это сейчас не выглядело, но с динамическим наследованием у меня всё нормально. Хотя признаюсь честно, когда только начал изучать программирование (15++ лет назад) понимание многого в теории ООП было очень трудным. Очень много было убито времени за банальным рисованием на листочках для того чтобы в голове сложился правильный и четкий образ. Но зато как только возникло понимание примитивов, все встало на свои места и сложности перестали быть сложными.

Преподаватель.

Если бы не хотел, то и не мучал бы тут людей идиотскими вопросами.

Вот как раз для понимания квантовой физики, знания математики нужны на уровне арифметики. Не шучу. Знания вышки могут даже мешать.

Вот тут Вы правы на 500%. Я этого сильно не учел. С другой стороны на форуме обучения пхп мне тоже вряд-ли бы ответили корректно. Потому что мои вопросы на стыке ксены и пхп как бы странно это не звучало.

Вы плохо посмотрели. Я как раз задал вопрос только тогда когда осознал что просто не знаю в каком направлении искать. Я просто не знал как устроен процесс инсталяции плагинов ксены. Более того тут на сайте я нашел всю необходимую информацию о том как реализовать то что мне нужно. Всё есть лежит и раписано достаточно подробно. Я просто не знал куда мне пихать этот код. Теперь знаю. Всё оказалось просто. Жаль только что я нарвался на эту информацию абсолютно случайно, а не по наводке @infis-а.

P.S. В общем ладно, Я только что закончил читать лекцию и у меня просто прекрасное настроение. Пошел искать рекомендованную @infis-ом книжку.

 

Ладно уточню свою формулировку "динамическое наследование в XenForo". Это близко к АОП и чем-то близко к программированию на аннотациях в симфони. А если бы вы программировали на чем-то подобном, то у вас не возникло бы ни одного из вопросов заданных на этом форуме. По крайней мере там бы была совсем другая формулировка.
Ну просто нельзя понять какой от какого класса наследуется (учитывая что делается это через не любимый многими eval) не поняв работу внутренностей ксена и не прочитав его исходники. А то что Вы так заявляете еще раз говорит о недостатке ваших знаний.

Тогда вопрос почему ее не преподают в 3-4 классе школы сразу после изучения арифметики?

Жалко мне Ваших учеников/студентов.

P.S. Обсуждение здесь полностью бесполезное и смысла продолжать не вижу его

 

Вот это другой разговор. Да я действительно не понимаю не то что наследование динамическое в ксенфоро, я вообще смутно понимаю внутренюю логику этого продукта. На симфони я не программировал и о концепции АОП только слышал краем уха к сожалению. Не является програмиирование моим основным заработком. Я изучал ООП во времна дельфи 2.0 в теже времена занимался проектированием и разработкой баз данных. И у меня не стоит задачи стать классным программистом php и научиться виртуозно разрабатывать под ксенфоро. У меня задача создать плагин под вполне конкретные задачи. И создать его так чтобы тот кто будет читать его исходники не ругался грязно постоянно натыкаясь на костыли и ужасные решения в коде.

И выходит замкнутый круг. Я читаю исходники понимаю что не черта не понимаю потому что не вижу картины в целом. Пусть без деталей но в целом. Прошу рассказать на пальцах основную логику работы и меня торжественно отправляют читать исходники со словами почитаешь поймешь. Очень тяжело что-то изучать когда не понимаешь что именно надо изучать.
Я более чем уверен что если просто изучать исходники БД то конечно постепенно поймешь общую концепцию заложенную в изучаемую БД. Вопрос только сколько на это уйдет времени. Не проще ли попросить проектировщика обрисовать тебе концепцию в целом, чтобы опираясь на это знание уже читать исходники и детально разбираться в продукте?

Это просто бессмысленно. Да и не всем нужна квантовая физика. Но это не значит что если её начать преподавать им они её не поймут.

А не надо их жалеть, они то как раз очень довольны тем что и как я преподаю. Эффект в явном вмде имеет место быть.

Всё что мы с вами тут обсуждали сводится к простой формулировке: Вы пытаетесь мне доказать что я что-то не смогу понять, причем ваша уверенность зиждется только на том что вы уверены что я не смогу понять. Действительно бессмысленное обсуждение. Согласен, если нет желания попробовать объяснить именно то что я хочу узнать, тогда стоит закончить.

 

==================================================================
Почитал описание ZF. Как мне кажется возникло кое какое понимание процессов происходящих в ксено.
Во первых события:
1. Событие запроса страницы. (например нажали F5 в браузере) Передается контроллеру в качестсве параметра имеет только имя действия. Предполагаю что как раз тут задействован роутер.
2. Событие генерируемое формой. (например нажали кнопку в форме) Передается контроллеру? как контроллер получает параметры из формы? А их контроллер получает?
3. События таймера. Полагаю что получает их контроллер. Но с этим пока не разбирался.

Во вторых у ксено есть несколько логический сущностей (название плохое но лучше пока не подобрал) которые так или иначе взаимодействуют между собой:
1. Форма. совственно то что отображает браузер.
2. Контроллер. Обрабатывает события принимает решения о передаче данных в форму о запросе или передаче данных в модель, реализует логику работы и вообще самый важный.
3. Роутер. Строит связь между формой и контроллером.
4. Модель. Работает с данными по запросу контроллера. Пишет, читает, форматирует.
5. Шаблон. С помощью примитивной логики строит форму по команде контроллера из данных полученных от контроллера. Или от модели? Он собственно последняя инстанция которая видит форму перед тем как её получит браузер.
6. Хелпер. Как японял используется шаблоном для выполнения какой-то логики и получения данных от модели. Или я не понял или зачем-то он работает в обход контроллера. В общем совсем не ясно что это за зверь.
7. Хук. Пока вообще не очень понимаю зачем он нужен и как его правильно применять и куда и в каких случаях.
8. Обработчик событий. Вот уж совсем загадочный пока зверь. Полагаю что с их помощью контроллер расширяет для себя список обрабатываемых событий. Внутри какая-то селекторная логика может быть, но думаю что обработку данных в них лучше не делать.

Ну т третье цепочки передачи данных:
1. моделью <--> контроллер. в оба направления в любой момент командует контроллер.
2. модель -> контроллер -> шаблон -> форма. Ну тут как-бы всё ясно.
3. форма -> контроллер -> модель. тоже как бы ясно, но я не уверен что цепочка верна.

Получилась вот такая картинка. Если не сложно подскажите пожалуйста что в этой картине мира не так?

 

Подход XenForo несколько иной, хотя в целом и совпадает. Проще будет непосредственно по названиям папок в library/Xenforo ориентироваться. Таким образом картина будет примерно следующая:

• ControllerPublic - контроллеры фронт-енда, обрабатывают действия/переходы, результат отдают в виде вьювера с указанным шаблоном и передаваемыми в шаблон параметрами
  
• DataWriter - датарайтеры, обеспечивают непосредственную работу с таблицами в базе данных (не всегда используются моделями)
• Helper - хелперы, обычно содержат небольшие функции, которые используются в различных местах движка, методы часто объявляются статичными для того, чтобы вызывать без создания экземпляра класса
• Model - модель, это какой-либо объект, работает с данными, используя датарайтеры и/или напрямую с базой данных
• Route - роутер, по сути это путь, который связывает адрес и действия на сайте (часть адресной строки в браузере) с контроллером, попутно строит URL
• ViewPublic - вьювер, определяет формат передаваемых данных и сами данные, обычно используется для работы с JSON, но не всегда

Это вкратце в разрезе движка XenForo. Очень условно, лишь для общего понятия, чтобы было понятно, куда лезть смотреть код

Понятия формы в XenForo нет, а за отображение отвечают шаблоны. То есть используется собственный шаблонизатор.

 

Я Вас понял. Попытаюсь встроить это знание в предложенную ""модель мира". Так что видимо сегодня у меня марафон с дебагером.
Я понимаю что у ксены строго нет понятия "форма". Как и нет строго понятия "цепочка движения данных". Собственно как и событий возникает формально гораздо больше чем описано.
Я ввел эти абстракции для более полной и точной "картины мира" так сказать построенной простыми словами с соблюдением правильной логики. Такой подход дает возможность не городить огород и всегда понимать что ты делаешь создавая приложение в той или иной среде. И как бонус быстро вникнуть в суть проекта с которым работаешь вне зависимости от языка, среды и т.д. и т.п.

Я искренне благодарен вам за ваши подсказки. Спасибо.

P.S. То есть хелпер как и хук это скорее некий костыль в ксенфоро позволяющий решить вопрос повторяемости кода, простоты сопровождения кода и разделения по модели MVC и т.п. , чем какой-то базовый компонент явно встроенный в основную модель и имеющий свою ключевую функцию?

 

Если грубо, то да, так и есть.

 

Поскольку тема полна отвлеченных рассуждений, то я тоже порассуждаю

Форум (не важно какай) - это веб-скрипт. Это не десктопное приложение. А Вы, судя по постам, имели опыт именно с десктопными. Поэтому есть некоторое непонимание происходящего.

Так вот, "цепочка данных" следующая.

PHP - интерпретируемый скриптовый язык, который выполняется на сервере. Для того, чтобы скрипт выполнился, кто-то должен к нему обратится. Обычно этот кто-то - броузер пользователя. Обратится к скрипту - это ввести в адресную строку броузера какой-то урл. Работу днс пропустим, запрос попадает на сервер по протоколу http/https, затем передается на какой-либо скрипт вида *.php. Сейчас принято делать одну-две точки входа вида index.php. В этом index.php решается задача - какая часть кода скрипта выполнится в зависимости от конкретного запроса пользователя. Вот это и есть роутинг.

Роутинг - часть кода, которая решает, какая часть кода выполнится в зависимости от запроса, и как будет выглядеть урл. Внешний вид урл важен в нашу эпоху сео-зависимости.
В общем виде роутинг есть у любого приложения, просто иногда он совсем простой, иногда достаточно сложный.
XenForo использует паттерн программирования MVC. Смысл его - разделение кода по классам исходя из задач.

M - модель - код, который отвечает за получение данных, чаще всего из БД.
V - вью, отображение - код, который отвечает за отображение данных.
C - контроллер - эти классы отвечают за все остальное Есть старый холивар насчет того, где должна быть бизнес-логика приложения, в XenForo логику принято держать в контроллерах.

Еще есть DataWriter - по сути это часть модели, отвечает за сохранение данных в БД и контроль целостности, валидацию и т. п. Позволяет не привязываться к конкретной СУБД, так что теоретически можно использовать не только MySQL.

Еще один слой - это шаблоны.


Так вот, вернемся к цепочке данных.
Пользователь ввел что-то в адресной строке => попал на index.php => попал на метод класса роутинга => роутинг вызвал метод класса контролера => метод контролера что-то сделал (получил данные из модели, или записал данные дата-врайтером) => метод контролера вызвал метод вью, передав туда результат своей работы (данные) => метод вью решил что именно отобразить и вернул результат своей деятельности в броузер пользователя.

Варианта отображения обычно 2 - это html страница или же json данные.
В случае html страницы и нужны шаблоны, которые отвечают за внешний вид этой страницы.

95% работы форума укладываются в эту схему, исключение - задачи по расписанию (крон). Они работают по другому немного.

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

 

Ну как сказать, пока да. Только отвлеченные рассуждения. Но думаю всё это оформить в виде статьи позднее чтобы этот путь не приходилось проходить через чтение сотен страниц полученных из гугла.

Вы правы. Большая часть моего опыта именно десктопные приложения. Правда понятие тонкого клиента мне знакомо не по наслышке как и MVC . Принципиальной разницы конечно нет, но как я уже понял кое что имеет немного иную логику связанную чисто с вебом.

P.S. Спасибо огромное за то что вы потратили время на написание этого поста, вы натолкнули меня на мысль которая надеюсь резко продвинет мои исследования в нужном направлении.

 

Процитировал потому что хотел просто привлечь Ваше внимание к вопросу. Извините если что не так.

Именно. Есть серьезная разница.
При создании тонкого клиента в отличии от веб приложения не существует явного механизма передачи данных от клиента к серверу. Он спрятан в АПИ и на него без необходимости не морочишься.

В случае с тонким клиентом при изменении данных в клиентской форме сразу генерируется событие передачи данных. Его можно обработать или в клиентской форме или просто прозрачно пропустить (не обрабатывать на клиенте) на сторону сервера. То есть понятие роутер в тонком клиенте спрятано глубоко в АПИ.

С пхп и вебом всё иначе. Тут роутер явное и обязательное явление в цепочке. Вот именно механизм его работы я и не понимаю.
Допустим (весь код взят из статьи с этого форума и просто модифицирован) есть некая страница которая генерируется по ссылке http://127.0.0.1/likes-review Ссылка на статью откуда взято.
Дополняем код шаблона следующим кодом:
<div class="primaryControlsG">
<!-- block: primaryControlsG -->
<h3>{xenhrase G_search_label}</h3>
<input type="search" name="keywords" value="" class="textCtrl" placeholder="{xenhrase G_search_user}..." results="0" title="{xenhrase G_enter_user_name_and_hit_enter}" id="QuickSearchQueryG" />
<!-- end block: primaryControlsG -->
<input type="submit" value="{xenhrase G_search}" class="button primary Tooltip" title="{xenhrase G_find_now}" />
<input type="hidden" name="_xfToken" value="{$visitor.csrf_token_page}" />
</div>
И у нас появляется на странице симпатичный сёчьбар с кнопкой.
Вопрос. Как его обрабатывать? Нужен ли новый роутер или правильнее расширять код likes-review и как? Нужен ли новый контроллер? И если да то в каком случае нужен, а в каком нет?
Я в превую очередь хочу понять сам механизм который используется. Ту часть механизма которую мне надо обрабатывать ручками. Маленький простой пример который бы на пальцах объяснил работу механизма роутера. Что куда в каких случаях и как передается.
Пробовал сделать на примере с русского форума Зенд. Только еще больше запутался.
Просьба не отсылать к дебаггеру. К сожалению не смог запустить пока дебаггер. Дурная ситуация про которую гугл просто ничего не знает. Такое бывает но к данному вопросу не относится.

P.S. Подскажите бб для форматирования кода тут.

 

Складывается такое ощущение, что это просто не Ваше...

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

Если брать штатные контроллеры, то они расположены в library/XenForo/ControllerPublic (для фронтэнда, публичная часть) и в library/XenForo/ControllerAdmin (для бакэнда, административная часть).
Для обработки параметров в пути (а также для правильного построения пути с параметрами) требуется расширение класса XenForo_Route_Interface. Такие штатные расширения найдете в libary/XenForo/Route/Prefix (для паблика) и в library/XenForo/PrefixAdmin (для админки).

Четвертая кнопка справа, затем третий пункт сверху вставляет бб-код кода. При этом допускаются следующие типы кода: CODE, PHP и HTML. Последние два раскрасят теги, а первый передаст все, что заключено в тег, как есть.

 

У меня такое-же ощущение. Но огромная практика, хоть и старая, по написанию проектов в дельфи приводит к выводу что я скорее всего не понимаю чего-то действительно абсолютно элементарного. Какой-то простой нюанс который не дает мне полностью понять логику и перейти уже непосредственно к коду. Это примерно из серии: как можно решать куда пойдет курс акции, вверх или вниз не понимая чем это может быть обусловлено?

Спасибо. Хоть и было понятно без пояснений тем не менее ремарка полезная и я почерпнул из нее кое что важное для себя.

С этим я разобрался.

Спасибо огромное, просто не увидел. Ткнули носом - спасибо.

У меня такое чувство что я не могу правильно сформулировать вопрос. Говорят что для того чтобы правильно сформулировать вопрос надо знать как минимум половину ответа. Попробую задать вопрос совсем примитивно.

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

В общем-то всё должно быть очень примитивно.
делаем модель выборки данных из базы по критериям

PHP:

<?php

class GarantTools_Model_GarantTools extends XenForo_Model
{
  public function getNeedPosts($limit)
    {
//тут мы что-то строим выбираем сортируем собираем в кучу и
//Возвращаем
        return $posts;
    }
    protected function _getPostModel()
    {
//Не совсем понимаю зачем нужна эта функция но полагаю что для реализации работы
//с кэшем и она везде и всегда стандартна.
        //Возвращаем модель данных о постах из кеша
        return $this->getModelFromCache('XenForo_Model_Post');
    }
}

далее реализуем контроллер

PHP:

<?php

class GarantTools_ControllerPublic_Index extends XenForo_ControllerPublic_Abstract
{
  public function actionIndex()
  {
//тут мы получаем из модели данные перелопачиваем их как-то если надо и передаем шаблону.
  return $this->responseView('GarantTools_ViewPublic_Index', 'garanttools_index', $viewParams);
  }

  protected function _getGarantToolsModel()
  {
//Тоже нужно для вопросов кэширования я так понимаю.
  return $this->getModelFromCache('GarantTools_Model_GarantTools');
  }
}


Далее рисуем в ксене шаблон

PHP:

<xen:require css="garanttools.css" />

//Этот код выбираем выводить или не выводить контент в зависимости
//от обратившегося к странице пользователя.
<xen:if is="{xen:helper ismemberof, $visitor, $secParams}">
// Это инпут поля. Строка ввода и кнопка.
       <div class="primaryControlsGarant">
         <!-- block: primaryControlsGarant -->
         <h3>{xen:phrase Garant_search_label}</h3>
         <input type="search" name="keywords" value="" class="textCtrl" placeholder="{xen:phrase Garant_search_user}..." results="0" title="{xen:phrase Garant_enter_user_name_and_hit_enter}" id="QuickSearchQueryGarant" />       
         <!-- end block: primaryControlsGarant -->
         <input type="submit" value="{xen:phrase Garant_search}" class="button primary Tooltip" title="{xen:phrase Garant_find_now}" />
         <input type="hidden" name="_xfToken" value="{$visitor.csrf_token_page}" />
//Строка выше я так понимаю дает возможность обрабатывать безопасность на странице прозрачно 
//средстваим ксены и нужна в том случае если потом со страницы мы будем что-то передавать.
//Код реализует что-то типа антифишинга.
       </div>
     
     <ol>

     <xen:foreach loop="$likedPosts" value="$post">
//Тут мы в цикле формируем отображение собственно списка тех постов которые получили из модели 
//и обработали в контроллере.
     </xen:foreach>
<xen:else />

//Тут ставим код который отобразит для тех кому не надо видеть страницу, какое-то сообщение.
</xen:if>


Что-бы все заработало создаем в ксене паблик роут с именем к примеру likes-review и обработчиком GarantTools_Route_Prefix_GarantToolsBody
При создании есть поле с вариантами выбора Использовать класс для генерации ссылки. Я так понял что выбор надо делать никогда только если со страницы с этим роутером никаких данных передаваться назад в ксену не будет.
Собственно код роутера

PHP:

<?php

class GarantTools_Route_Prefix_GarantToolsBody implements XenForo_Route_Interface
{
  /**
  * Match a specific route for an already matched prefix.
  *
  * @see XenForo_Route_Interface::match()
  */
  public function match($routePath, Zend_Controller_Request_Http $request, XenForo_Router $router)
  {
  return $router->getRouteMatch('GarantTools_ControllerPublic_Index', 'index', 'likes-review');
  }
}


Переходим по ссылке http://127.0.0.1/likes-review
Почти Всё работает. И с этого места у меня начинаются вопросы.
Надо ли для обработки кнопки с сечьбаром в данном случае использовать отдельный префикс роута? Если не надо то как мне объяснить контроллеру что надо выполнять не Экшн индекс функцию, а другую. Или надо все варианты развития событий предусматривать в экшн индекс? Ну и самое главное, как именно мне получать данные от сечьбара и событие от кнопки? Через где идет передача данных, каким образом?
Может вопросы и слишком очевидные, но столкнулся с проблемой что эти очевидности концептуально никак и ни где не описаны. Да даже простых примеров не смог найти.
Простые учебники по пхп просто не заморачиваются описанием передачи данных от формы к серверу. В них описано только как на что реагирует тот или иной оператор. А учебники по бибилиотекам типа зенд в основним описывают какие классные и крутые функции есть в бибилиотеках и как эти функции удобно и легко использовать при разработке на пхп.

При разработке тонких клиентов ты всегда работаешь в единой объектной среде и вопрос передачи данных и событий просто не стоит. С вебразработкой всё как-то иначе.

 

На мой взгляд, один из самых шикарных примеров, как все должно работать - это префикс members. Посмотрите, как там все реализовано. Обратите внимание на то, как обрабатывается actionIndex, если путь был без параметра, и с параметром (будет перенаправлен путь на другой экшен в этом же контроллере).
По поводу различных экшенов для одного префикса. Они все описываются в одном контроллере. То есть actionIndex обрабатывает просто префикс пути. В вашем случае это likes-review. Если Вы в пути укажете likes-review/blablabla, то при нажатии такой ссылки в контроллере сработает такой экшен actionBlablabla. Регистр букв важен. При этом, если Вы будете работать с параметрами в пути типа likes-review/my-review.123/blablabla, то это также вызовет actionBlablabla, но при этом передаст ему 123 в качестве параметра. В общем, смотрите все, что связано с members в XenForo.
Если Вам потребуется работать с параметрами в контроллере, то нужно изменить match следующим образом:

PHP:

<?php

class GarantTools_Route_Prefix_GarantToolsBody implements XenForo_Route_Interface
{
  /**
  * Match a specific route for an already matched prefix.
  *
  * @see XenForo_Route_Interface::match()
  */
  public function match($routePath, Zend_Controller_Request_Http $request, XenForo_Router $router)
  {
     $action = $router->resolveActionWithIntegerParam($routePath, $request, 'здесь_ваш_review_id_или_что-то_в_этом_духе');
     return $router->getRouteMatch('GarantTools_ControllerPublic_Index', $action, 'likes-review');
  }
}

Также, если будете работать с параметрами типа review-id, озаботитесь написанием там же метода buildLink, который позволит в шаблоне использовать автоматическое построение ссылок.

 

Вроде уловил суть. Буду проверять и пробовать и смотреть. Но завтра.
@infis, Если не сложно можете дать мне на 5 минут консультацию голосом по скайпу если не сложно. Мне голосом легче воспринимается. Я задам пару глупых вопросов. Просто чтобы понимание в голове улеглось.