[Релиз] Разработка расширения "Developer Helper" (Страница 1 из 2)

Предлагаю посмотреть как это работает: http://punbb.ru/downloads/development.zip
Архив содержит два расширения Developer helper и Developer test для его демонстрации.
Пример добавляет пункт навигационного меню средствами хелпера, обработка пункта осуществляется хелпером, т.к. ссылка построена на соглашении роутинга. Так же реализована автозагрузка классов и пример демонстрирует это тоже.
Смотрите код примера. Высказывайтесь.

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

if ($action = 'blablabla')
{
} 
elseif  ($section = 'blabla') 
{
...
}
else
{ }

Эта сумасшедшая лапша накладывает отпечаток на сознание разработчиков, в результате и расширения получаются такие же. В случае с ЛС все немного лучше, там есть много функций
К появлению такого "склеивающего" расширения меня подтолкнула разработка системы оплаты и расширения платных услуг. Если каждое расширение будет своим способом решать задачу быстрого доступа к глобальным переменным и обработки входящих запросов, то получится дублирование действий. Каждое расширение в misc.php добавит свое условие, $actions начнут повторяться, конфликтовать и т.п.
Ктстати ООП в процедурном ядре присутсвует в виде абстрактного слоя работы с БД. Вещь очень удобная и мощная.

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

Добавлено спустя 8 минут 6 секунд:

Нет. Класс в автолоадинге будет подключен в момент первого обращения к нему.

Добавлено спустя 8 минут 49 секунд:

Насколько я понимаю документацию к пхп...

Ты совершенно прав, если использовать какое-то соглашение об именовании, то регистрация не нужна.

Добавлено спустя 6 минут 55 секунд:

Но при таком подходе становится затруднительно использовать короткое название класса.

Посмотрел повнимательней и вспомнил настоящую причину отсутствия дефолтовых контроллеров и экшенов.
Мы можем захотеть поместить контроллер глубже в папке controller, например в папку user:
my_extension/user/controller/action
А то  и глубже. В таком случае у нас контроллером станет имя папки, а экшеном имя контроллера, что задачу не решает. Я не думаю, что принуждение указывать контроллер и экшн, даже если он дефолтовый, негативно скажется на разработчике и процессе разработки. Максимум пострадает внешний вид ссылки, но как правило на рабочих форумах включен реврайт, поэтому такая ссылка будет скрыта (если того пожелает разработчик). Дополнительный плюс - при просмотре ссылкив процессе разработки понятно что это и куда ведет, т.е. поведение ожидаемое, не нужно тратить лишнюю эээ психическую энергию и время на интерпретацию.

Подпапки просто способ структуризации хранения файлов. Если это и есть модульная структура, то пусть модульная структура. Логично же контроллеры относящиеся к админке расположить например в подпапке admin? Исключительно с целью структуризации и отделения мух от котлет.
Конечно можно обойтись соответствующими названиями файлов классов, типа amin_index.php, user_index.php и т.д
А какое единое правило для реврайта ты предлагаешь?

Убедил

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

• контроллеры

• модели

• еще может что-то понадобится

и как вариант разделить имя расширения и имя класса типом класса, например: My_extenstion_Controller_My_class, отлавливая его в названии класса, и разделяя по нему части, однозначно определяя путь к my_extension/controllers/my_class.php, правда придется наложить вето на использование некоторых слов в названиях классов

По ссылке сверху код не изменился.
На сколько я понимаю модель MVC, основная работа со всем чем можно идет внутри контроллера, а точнее внутри конкретного экшена, который был вызван, соответственно чаще всего ты будешь использовать конструкции аля $this->do_something, $this->do_something_else и тому подобные. Ну а зачем тебе понадобились статические методы, да еще и так часто что бы запариваться по поводу длинны названия функции, я пока догадаться не смог если честно

Обновил версию: http://punbb.ru/downloads/developer_helper.zip
1. Реализовано соглашение об именовании:
Названия классов, претендующих на автоматическую загрузку  должны именоваться
Имя_расширения_Имя_папки_Имя_класса, где Имя_папки может быть одним из:
Controller, Model, Module, View
Имя_класса должно совпадать с именем файла, в котором этот класс находится.
2. Добавлена загрузка языковых файлов. Языковой файл немного отличается от обычного и должен возвращать массив, а не объявлять:

return array (
'lang string' => 'перевод'
);

Загрузка файла может происходить где угодно и сколько угодно раз таким образом:

App::load_language('Имя_расширения');

При такой записи будет загружаться файл Имя_расширения/lang/English.php
Если языковых файлов у расширения несколько и они сгруппированы в папке с именем языка, то загрузку делать так:

App::load_language('Имя_расширения.Имя_файла');

Имя_файла - без расширения.
Загружать можно сколько угодно языковых файлов, доступ к языковым переменным:

App::$lang['lang string']

3. Введено 3 вида роутинга - к админ-центру, к профилю, ко всему остальному.
Сделано это потому, что для профиля шапка и меню формируется в profile.php, для админки шапка и меню -  во вложенной папке admin (в нашем случае для админки обработчик находится в admin/settings.php),  а для других случаев все стандартно иоднотипно, поэтому обработчик в misc.php.
С точки зрения формирования ссылок это выглядит так:

profile.php?section=route&id=$1&r=расширения/класс/действие
admin/settings.php?section=route&r=расширения/класс/действие
misc.php?section=route&r=расширения/класс/действие

Обратите внимание, что для профиля мы должны передать ид пользователя ($1)
Если придерживаться такого разделения, то  для профиля хелпер подготовит crumb :

Имя форума> Имя пользователя

для админки:

Имя форума> Администрирование

в контроллере останется только доформировать свои крошки, например:

App::$forum_page['crumbs'][] = array(App::$lang['Section billing'],forum_link(App::$forum_url['profile_billing'], App::$forum_user['id']));

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

Примера пока нет, извиняйте.

Модули нужны для модулей. Не могу пока объяснить, я же этот хелпер делаю не абстрактно и оторванно от жизни, а совместно с расширением от него зависимого. Вкратце, там есть классы, не имеющие отношения к контроллерам. Логично их отделить.
По языку, загружается тот язык, который в профиле.
Фактически это аналог такой конструкции, которую прописывают в хуках:

        if (file_exists($ext_info['path'].'/lang/'.$forum_user['language'].'/'.$ext_info['id'].'.php'))
            include $ext_info['path'].'/lang/'.$forum_user['language'].'/'.$ext_info['id'].'.php';
        else
            include $ext_info['path'].'/lang/English/'.$ext_info['id'].'.php';

Эту тему надо прилепить, а моё сообщение удалить.