ertaquo Apr 27 2011 at 16:06

Мини-фреймворк своими руками

11 min

13K

PHP*

+46

Comments 67

mark_ablov Apr 27 2011 at 16:30

для своей хоумпаги писал что-то подобное, только там было 2 возможных модели урлов — /controller/action и произвольные роуты, ну и немного другая модель переменных, без всяких ассертов, сразу в маршруте пишем регулярку.
Примерно так:

    require_once('../framework/Main.php');
    require_once('../application/config/config.php');

    $routes = array(
        '/blog/get/(\d+)' => array('controller' => 'blog', 'action' => 'get', 'params' => array(1 => 'id')),
    );

    Main::setRoot(dirname(__FILE__) . '/../');
    Main::setRoutes($routes);

    arr2obj($config);
    Registry::set('config', $config);

    try
    {
        Main::run();
    } catch (Exception $e)
    {
        header("HTTP/1.0 404 Not Found");
        include('404.html');
    }

/updates/get попытается вызвать updatesContoller->getAction
/blog/get/123 blogController->getAction, и сиглтон Request будет содержать параметр id = 123.

А в ваш код неплохо было бы добавить autoload.

    private function __construct()
    {
        spl_autoload_register(array($this, 'loader'));
    }

    private function loader($class)
    {
        $incPath = get_include_path();
        $end_ptr = strlen($class) - strlen('controller');
        if ($end_ptr != 0 && strcasecmp(substr($class, $end_ptr), 'controller') === 0)
            set_include_path($this->_root . $this->_controllerPath . PATH_SEPARATOR . $incPath);
        else
            set_include_path($this->_root . $this->_modelsPath . PATH_SEPARATOR . 
                             $this->_root . $this->_libraryPath . PATH_SEPARATOR . $incPath);
        $filename = $class . '.php';
        $f = fopen($filename, 'r', true);
        if (!$f)
        {
            set_include_path($incPath);
            throw new Exception('Class not found.');
        }
        fclose($f);
        include $filename;
        set_include_path($incPath);
    }

RiderSx Apr 27 2011 at 16:35

Чтоб /controller/action/smth/ приравнять к /controller/action/smth можно же просто trim($path, '/') :)

ertaquo Apr 27 2011 at 16:39

В моем варианте если кто-то введет /controller/////////action/////////smth/, то оно спокойно обработает это так же, как и /controller/action/smth :-)

-1

RiderSx Apr 27 2011 at 16:42

Я в том плане что это можно делать изначально, чтоб тупо унифицировать урлы))

YAAP Apr 28 2011 at 15:03

К тому же, если кто введет /controller/////////action/////////smth/, надо этого кого-то послать на… главную с рекомендацией воспользоваться меню.

+1 за унификацию урлов. Плохо, если по 500 разным урлам у вас будет одна страница, еще и с ответом 200 и без canonical.

VolCh Apr 29 2011 at 03:43

>К тому же, если кто введет /controller/////////action/////////smth/, надо этого кого-то послать на… главную с рекомендацией воспользоваться меню.

Одна из причин использования «красивых» урлов это как раз возможность использовать адресную строку для навигации внутри приложения.

YAAP Apr 29 2011 at 12:30

То, что по структуре ЧПУ можно проследить структуру сайта — понятно, но я не о том. Я говорю о том, что /controller/action и /controller//action — два разных урла.
Если брать во внимание ПС — некоторые время у вас будет 100% одинаковый контент на разных страницах (урлах). А этих вещей надо избегать. Один из вариантов — canonical, но вообще — лучше не доводить до такого.

1 урл = 1 страница

VolCh Apr 29 2011 at 17:24

У меня не будет :) Второй у меня выдаст 404. А вот с /smth/ и /smth (или / и /index.php) проблемка: с одной стороны формально, как вы правильно заметили, это разные страницы, с другой — фактически это внутренний редирект. По хорошему надо делать внешний редирект, с другой стороны — это лишние проверки/действия не дающие, имхо, какого либо профита для пользователя, а время ответа увеличивающие.

YAAP Apr 30 2011 at 08:55

На счет времени ответа — согласен, но, как мне кажется, это экономия на спичках. Проверки у вас в начале работы всех скриптов идут, ресурсов (а вместе с ними и времени) ушло мало. Вы же не будете бить тревогу лишь потому, что время загрузки увеличилось на 0.001с, я надеюсь.
Но, согласен, можно обойтись и без этого, тут-то как раз canonical и решает.

VolCh Apr 30 2011 at 17:25

Проверки это одно, но для внешнего редиректа это плюс, как минимум, один пинг.

Yeah Apr 27 2011 at 16:36

Если уж сильно хочется сделать создание объекта Request в одну строчку, то лучше не в функцию оборачивать, а делать фабрику. Вместо:

function Request($method, $path, $callback)
{
	return new Request($method, $path, $callback);
}

делать


class Request {

    public static function factory($method, $path, $callback)
    {
	return new self($method, $path, $callback);
    }

    ...

}

ertaquo Apr 27 2011 at 16:38

Спасибо, просто не знал о подобном.

Yeah Apr 27 2011 at 16:43

Еще я не понял зачем в конструкторе Request нужна строчка:

global $application;

И зачем свойства класса объявлены как public? Лучше используй getters/setters. __construct в классе Application вообще какой-то страшный. Ты, наверное пытался реализовать Singleton, но он реализуется совсем не так.

ertaquo Apr 27 2011 at 16:56

Да, мой косяк. Синглтон поправил, а $application удалил — оно осталось, когда я прикидывал варианты реализации. А для чего нужно использовать здесь getters/setters?

Yeah Apr 27 2011 at 17:00

А зачем у тебя свойства класса объявлены публичными? Сокрытие свойств не реализовано. А если я в коде напишу $request->callback = 'ololo'. Будет fatal error. Лучше ведь сделать getCallback/setCallback, в котором проверять is_callable и бросать исключение — его по крайней мере проще отлавливать.

ertaquo Apr 27 2011 at 17:17

В таком случае лучше делать проверку прямо перед вызовом call_user_func_array. Потому что если делать ее при присвоении, будет неправильно работать, если кэллбек создать с помощью create_function дальше по коду.

Yeah Apr 27 2011 at 17:24

Может и так, но в любом случае свойства класса не следует делать публичными.
Кроме того, конкретно этот момент я бы сделал так:


if ($callback  !== null) {
    if (!is_callable($callback)) {
        throw new Exception('Not callable');
    }
}

Тогда если параметр callback не передан, то ничего выполняться не будет.

Yeah Apr 27 2011 at 16:58

Singleton, совершенно определенно, работает неправильно. Вызов Application::getInstance() не работает, если не вызван new Application перед этим

Yeah Apr 27 2011 at 16:56

Вот же ж жесть. Я только что открыл для себя новое в ПХП. Оказывается, что приватные методы класса можно вызывать из уже созданного объекта, если вызов происходит в контексте класса (статический метод). Автор, признавайся, откуда это узнал и главное — зачем так сделал?


class Application 
{
        private function i_run() 
        { 
            ....
        } 

        public static function run() 
        { 
            return Application::getInstance()->i_run(); 
        } 
}

ertaquo Apr 27 2011 at 16:58

Открыл методом тыка. ООП в PHP сам плоховато знаю :( Сделал так исключительно для красоты, чтобы вместо длинной строчки:
Application::getInstance()->run();
можно было написать короткую:
Application::run();

Yeah Apr 27 2011 at 17:03

Ну, как бы такое поведение ПХП совсем неочевидно, и не факт, что это не баг, и оно сохранится в следующих версиях.
Вообще, как насчет залить на github? Так проще смотреть.

ctajiuh Apr 27 2011 at 18:53

Если не ошибаюсь, здесь мы получаем нормальный такой инстанс синглтона, на котором потом вызываем его метод. Меня тоже удивило такое решение, но мне оно кажется далеко не багованным — ведь статический метод доступен всегда, инстанс создать можно когда угодно, значит и метод не статический на нем вызвать можно. А выглядит хорошо. Этакая вещь в себе — сам создался, сам себя задействовал =)

ctajiuh Apr 27 2011 at 18:59

Ага, нашел:

Статические методы не определяются через переменную $this, поскольку они не должны быть ограничены определенным объектом.

То есть статические члены изначально не ограничены определенным классом => могут использоваться и таким способом.

P. S.: Выше абзац там тоже интересное решение описывает. Учитывая, что подобные решения вводятся, оно сохранится в следующих версиях (скорее всего).

PHP.SU

mark_ablov Apr 27 2011 at 19:08

как бы вроде стандартное решение, особенно в синглтонах.
только удобнее использовать не Application::getInstance(), а self::getInstance(), тогда не забудем поменять имя класса при рефакторинге возможном :)

rumkin May 20 2011 at 14:40

Почитайте про scope и наследование в PHP там все описано подробно про доступ к свойствам/методам из потомков и прочего. В общем… матчасть!

everzet Apr 27 2011 at 16:47

Даже больше. Фактори можно использовать со старым синтаксисом: www.php.net/manual/en/language.oop5.magic.php#language.oop5.magic.invoke

ertaquo Apr 27 2011 at 17:00

This feature is available since PHP 5.3.0.

У меня на хостинге 5.2, поэтому использовать не получится :(

pro100tak Apr 27 2011 at 16:58

Охохо.
1. Что делать при количестве возможных активити Ю 10(100(1000(и т.д.)))?
2. Как разделить его на функциональные части (user/shop/updates...) — что по-идее должно быть контроллером
3. Добавка нового роута да и сам роутинг сомнителен

П.С. Такое впечатление, что Вы смотрели ещё и на Kohana :)

pro100tak Apr 27 2011 at 17:00

Ю = ">"

ertaquo Apr 27 2011 at 17:24

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

Request('get', '/user/{username}/profile', UserProfile)->assert('username', '|^[\w\d]+$|');

Request('get', '/shop/{id}/rating', ShopItemRating)->assert('id', '|^\d+$|');

3. Так я и не утверждаю, что надо писать именно так. Это просто пример ;)

Yeah Apr 27 2011 at 17:08

Если действительно ставилась цель написать вызов фреймворка в одну строчку, то вместо неочевидных фишечек с auto_prepend_file и auto_append_file лучше было бы добавить в Application::run() параметр Request.
Тогда вызов бы свелся к следующему коду:


Application::run(Request::factory('/user/{id}', UserProfile)->assert('|^\d+$|')->run())

Конечно для этого нужно будет изменить метод run класса Request и возвращать из него this.

-1

ozzycv Apr 27 2011 at 18:26

извините, а «callback» читается «кэллбек»?? я просто все время думал «коллбек»

UFO just landed and posted this here

MarcusAurelius Apr 27 2011 at 19:00

Советую перед тем, как начинать кодить, сделать себе список задач, корыте будет решать Ваш фреймворк. Вот все что решает он сейчас — это маршрутизация при вызове разных урлов в разные обработчики. Все это же пишется ровно в 3 раза меньше кода без придумывания лишнего. Но задайтесь вопросами посложнее: а можно ли наследовать и переопределять функциональность и от одного обработчика в другой. То есть, чтобы вложенные урлы могли наследовать часть объектов и шаблонов от родительского урла и переопределять, когда это нужно, а потом, в дальнейшем ветвлении урлов, опять возвращаться к функционалу предка (inherited). Наличие Application, возможно продиктовано Вашим Дэлфийским прошлым, так? Тогда Вам не нужно объяснять, что такое inherited, я надеюсь. Потом еще фреймворковые задачи для развития идеи: доступ к базам, сессии и куки, кеширование, и т.д. Я понимаю, что оно у Вас называется «мини-двиг» и это хорошо, но начинайте проектирование систем с требований.

ertaquo Apr 27 2011 at 19:34

Я ориентировался на Silex и писал это просто для примера (Application пришло оттуда же, а не с дельфей). Специализация узкая, но если делать нормальный фреймворк/cms, то это будет лишь один из модулей. Доступ к базам и прочее будут реализовываться другими модулями. Собственно, сейчас еще попутно пишу для себя небольшую cms со всем этим и в этом мне здорово помогает хабр — отсюда я узнал о существовании PDO, работе с постоянными соединениями и многое другое.

rumkin May 20 2011 at 14:45

Можете направить где посмотреть реализацию или почитать про наследования по УРЛ. Или можете предоставить свой пример.
Интересно кто как это делает.
Заранее спасибо.

rumkin May 20 2011 at 14:53

* в первом предложении вопросительный знак потерялся.

MarcusAurelius May 20 2011 at 20:30

Выслал в личку бета версию. Если еще кто-то хочет бетатестить, то могу выслать. Через пару недель выложу в свободный доступ, когда доки подготовлю.

rumkin May 20 2011 at 23:53

Даже так? Спасибо!

Winchester Apr 27 2011 at 19:45

Делал подобный велосипед, только по пути вида

/controller/action/param1/param2/.../paramN

запускается метод %имя_действия%Action класса %имя_контроллера%Controller с массивом параметров.

Это, конечно, топорно, но большинство простых задач охватывает.

pewpew Apr 30 2011 at 16:47

У себя сделал довольно гибкий метод:

// Parse query

// host/dir/subdir/../subdirX/?param1=1&param2=2&...&paramX=x

// $url_array[]

// $url_array[0] = "dir";

// $url_array[1] = "subdir";

// ..

// $url_array[X] = "subdirX";

// $_GET["param1"] = "1";

// $_GET["param2"] = "2";

// ..

// $_GET["paramX"] = "X";

$url = "http://localhost".$_SERVER['REQUEST_URI'];

$temp_url = parse_url($url);

$dirs = explode('/', $temp_url['path']);

isset($temp_url['query']) && parse_str($temp_url['query'], $_GET);

А уже дальше логика зависит от задач. Из плюсов — можно делать любое ЧПУ и комбинировать со стандартными правилами формирования переменных в GET.

impwx Apr 27 2011 at 20:21

Вопрос: а URL вида /hello_{name} оно распознает? Или параметр обязательно должен быть окружен косыми чертами? И как с этим обстоит дело в Silex?

ertaquo Apr 27 2011 at 20:25

Увы, пока не распознает и параметр должен быть окружен косыми чертами. Как в Silex с этим — не знаю.

impwx Apr 27 2011 at 21:20

Посмотрел — нет, Silex такого тоже не понимает. Наверное, и правильно :)

Melz Apr 27 2011 at 20:27

Мне кажется, что чпу и роуты нужно делать не в первую очередь.

Лучше сделать удобную систему ввода-вывода с валидацией единую для всего приложения.

Дальше делаем на пример:
class Meat implements iListView
он и любой другой класс с интерфейсом может быть представлен как список.

Делаем контроллер для списка
class ListView()

передаем ему объект с интерфейсом, делаем привязку переменных, названия переменных, тип списка

$ListView->option('type', 'ul');
$ListView->with_var(array(a => 'var a'));

Основной вывод это или текст или список или таблица. Прийдется реальзовать (или наследовать) несколько методов, но зато будет меньше писать потом.

UFO just landed and posted this here

ertaquo Apr 27 2011 at 20:54

Здесь — просто для примера, с объяснением принципа работы. Я ведь не утверждаю, что у меня оно особенное или лучшее.

vooD Apr 27 2011 at 21:24

Зачем вам callback для array_filter? Чем вам плох array_filter($array)? Более того, откуда у вас будет false в $array после explode()?

ertaquo Apr 27 2011 at 21:41

Ту функцию просто скопировал из другого исходника (сейчас тут поправил, спасибо за заметку). array_filter без подобного кэллбека плох тем, что оставляет те элементы массива, значение которых после приведения к типу bool не равно false. Однако по правилам преобразования в булевый тип строки "" и «0». Так что если не написать кэллбек, будет ошибка при разборе пути "/some/0/info".

-2

shaelf Apr 27 2011 at 22:43

Ох уж эти велосипедисты… Увидел и как маленький «хочу такое же». Не лучше ли «увидел что-то и улучшил это»?

YAAP Apr 28 2011 at 15:14

Порой лучше написать свой велосипед, чем допиливать чужой.

Труъ кодер не будет читать Войну и Мир. Проще новую написать, чем разбираться в 4 Мб чужого кода. © Баш

VolCh Apr 29 2011 at 03:58

Форкать и/или патчить чужой проект не самая интересная задача, особенно если тебе нужно 10% функциональности «оригинала», которые решают 10% твоих задач.

shaelf Apr 29 2011 at 10:49

Конечно, кто же спорит то… Вот только если он решает 10% твоих задач + 10 мегабайт ненужного кода. Но тут небольшое НО.
1. Мотивация была выражена словами: «Недавно, прочитав про мини-фреймворк Silex, я подумал: а что в нем сложного? Попробовал написать нечто подобное и получилось довольно легко.». Т.е. это не решение задачи, а просто написать свой велосипед и потом с ним бороться.
2. Пых тормозит в развитии именно из-за того, что тут много велосипедистов и нет ничего более менее де факто. Возьмите Java, там под каждый чих есть фреймворк, 1 — 2, а не 100500. Возьмите Ruby. Что касается веба, то почти все проекты поднимаются на рельсах. Люди пишут плагины и выкладывают. Возьмите JS, основная масса давно пересела на JQuery и вместо своих велосипедов стараются просто написать плагин и выложить. Давайте посмотрим на PHP, что мы видим… ZF, symfony, kahona, CI и пару миллионов велосипедов. Много ли кто знает плагинов для них?

VolCh Apr 29 2011 at 18:31

1. Для аналогичных своих действий могу предложить следующие мотивации на выбор или в комплексе:
— лень разбираться с чужим кодом, который не находится под моим контролем, а значит может уйти куда-то куда мне не нужно, а куда нужно не уйти и, как следствие, усилия по изучению и использованию будут потрачены зря (показательна ситуации c Silex+Doctrine или просто Symfony 2 и 1.x — человек прислал push реквест на расширение для ORM и DBAL — приняли только DBAL, ORM не «sylex-way», а Symfony2 несовместима с Symfony 1.x), в общем Not Invented Here в чистом виде.
— заведомый оверхид чужого кода, если все его возможности не использую. Возможно это можно считать преждевременной оптимизацией, а возможно нет — гвозди микроскопом забивать тоже как-то не тру.

2. Отчасти согласен, но, во-первых, сам PHP для веба де-факто находится на уровне мини-фреймворков или библиотек для языков изначально общего назначения — средства абстрагирования HTTP являются средствами языка, а не сторонних продуктов или даже стандартных библиотек — грубо говоря, PHP это что-то вроде Ruby+Rack. Для создания типичных приложений не нужно писать или использовать чужой код, абстрагирующий взаимодействие с веб-сервером, а, тем более, с сетью. Для других языков нужно или писать такой код (что больше относится к системному, а не веб-программированию — сокеты, треды/потоки и т. п.), или использовать чужой, после чего использовать ещё кусок чужого уже психологически проще — одна внешняя зависимость или две, кроме собственно языка, уже не так принципиально. А если ещё вспомнить, что и шаблонизаторы для других языков если не необходимы, то крайне желательны, то две или три зависимости ещё менее важно. Плюс менеджеры пакетов, говорят, намного удобнее и эти зависимости контролировать проще.

Во-вторых, почему-то для PHP нет лёгких (и в смысле ресурсоемкости, и в смысле изучения/использования), гибких и расширяемых/конфигурируемых full-stack фреймворков. Как-то или монстры, регламентирующие всё и вся с жёсткими зависимостями и большим оверхидом для простых приложений, или минимальная функциональность, которую сначала нужно расширить до привычного уровня, а лишь потом можно начинать писать что-то сложнее «Hello world». Золотой середины, с которой можно было бы и быстро сделать прототип, и развить его до легкомасштабируемого приложения, обслуживающего миллионы клиентов в сутки я не знаю. Возможно это свойства языка и/или его единственной (практически) реализации, раз даже автор многообещающего, но заведомо громоздкого Symfony2, не закончив работу с ним, создаёт второй, на этот раз относительно легковесный, микро-фреймворк Sylex, основанный на компонентах первого.

Veterinar Apr 27 2011 at 23:42

<?php

include($_REQUEST['page']); // fuck yea!

?>

seriyPS Apr 28 2011 at 00:22

ппц какой-то…

mukizu Apr 28 2011 at 00:30

кэллбеков -> коллбэков

хорошо хоть не калл…

Winchester Apr 28 2011 at 07:50

Кстати, вместо той мороки удалению пустых частей массивов, можно было вместо explode() воспользоваться preg_split с флагом PREG_SPLIT_NO_EMPTY.

icegreenberry Apr 28 2011 at 09:45

Интересно, конечно.
Но Вы же понимаете, что Silex все-таки сложнее и элегантней?:)

ertaquo Apr 28 2011 at 12:54

Конечно. У меня его простенькое подобие, написанное для примера :-)

akalend Apr 28 2011 at 10:17

как учебное пособие HOWTO — то что надо.
не хватает проверки на «отсутствия класса» и «отсутствия метода».
к сожалению практически не увидел, как используются исключения.

Для имплементации класса советую все же использовать Reflection а не return new Request($method, $path, $callback); Это неопходимо при использовании акселератора. Если вы его не используете и вам плевать на производительность, то можете ни чего не поправлять.

Данный пример описывает упрощеннную работу контроллера. Остается сделать развернутое описание View и Model: Придумываем красивое название диреректорий и правила, где что лежит. На основании этого описываем правила для автолоадера.

Не забываем отделять код, данные и представление.

А так в целом все даже очень не плохо.

akalend Apr 28 2011 at 10:24

if (!class_exists('Application'))

{ ...

 class Request {...}

 

 class Application {...}



Application::init();

 }else 

 Application::run();

жуткий Хардкод!!!
Кто предложит вариант получше?

ertaquo Apr 28 2011 at 12:55

Пардон, я сам ООП в PHP знаю плоховато и поэтому написал подобное. Если объясните, как сделать лучше, то сделаю.

akalend Apr 28 2011 at 14:12

чуть позже объясню обязательно,
просто интересно как думает большинство.

akalend May 3 2011 at 18:53

к сожалению пост исчерпал потенциал, большшинство не думает ничего :)

1) использование статики — ни есть хороший тон ООП
статику надо использовать в крайних случаях. Было время, статику использовали как немспейсы. Это время уже прошло.

2) используем автолоадер, писалось об этом ранее

3) Данный код должен выглядить как-то так

01 $app = new Application( );
02 if ( $app->isInit() )
03 $app->run();
04 else
05 $app->init( new Request());

При инициализации должны в Приложение передаться все внешние данные, будь то конфиги, коннекции, запросы, классы мемкеша и пр… А лучше это делать и в самом методе инициализации.
строка 5 может быть такой: $app->init(); а сам метод таким

public function init() {

    $this->request = new Request();



    $this->config = new Config();

    $this->config->load('main');



    $this->db = new Db( $this->config->db );

// и тд

}

Далее, делаем так, чтоб инициализация была всегда, а если что-то по какой-то случайности не проинициализировалось ранее — то используем «ленивую модель », т.е строки 2-5 заменяем на один метод: $app->run();, а в методе run() вызываем private function init();

public function run() {

    $this->init();

...

}



private function init() {

// используем ленивую проверку

    if (! $thid->db)

        $this->db=new Db( $this->config->db );

}

В общем должно выглядеть как-то так…

ertaquo May 4 2011 at 16:55

Спасибо :-)

akalend May 5 2011 at 15:56

если что не очень понятно
то задавай вопросы — не стесняйся

вот пример моего фреймворка github.com/akalend/quickly
приблизительно к такой или похожей OOП структуре надо стремиться.

Show the best of all time