Первый раз вижу, что pyha.ru лежит, а pyhapyha.ru здравствует. Видимо SMF умер.
Уж не новая ли уязвимость на преобразованиях чисел виновата?

Думки
Я хочу написать не набор компонент на все случаи жизни, а скорее набор правил по склеиванию цельного легко управляемого продукта. Готовые компоненты будут как иллюстрации к нужным интерфейсам. Фреймворк должен становиться все проще и проще.
Про «звездные объекты»: (цитата с agiledev)

В любом проекте существует набор объектов, которые требуются большому количеству клиентов. К таким можно отнести соединение с базой данных, объекты конфигурации, пользователь, система прав, запрос(request) или ответ(response) системы, логгер, кеш – этот список можно продолжать. Раз они требуются большому числу клиентов – значит, они должны быть как минимум легко доступны практически в любой точке приложения. Для приложения средних размеров этот список уже большой – все через конструктор не передашь. Кроме этого, иногда возникает необходимость в том, чтобы сменить, скажем, метод обработки ошибок, драйвер базы данных, механизм кеширования и т.д. Идеально, если наше приложение потребовало бы при этом минимальных модификаций, не затрагивая при этом кода, реализующего бизнес-логику.

В Qb явной звездой выступает класс Qb :) Но, как мне кажется, эта уступка оправдана. Все прочие компоненты могут и должны добываться через реестр (Service Locator).

Чтиво
agiledev.ru: Управление зависимостями в PHP-коде

Последние изменения в репозитарии Qb
* Отказался от геттеров/сеттеров в компонентах. Казалось бы так красиво писать
$this->router->route()
вместо
Qb::getComponent('router', 'IQbRouter')->route()
но на самом деле длинный вариант информативнее.

Convention over Configuration

Пришел к убеждению, что надо снижать требования к конфигурированию приложения. В итоге переделал систему событий. Ядро перекроил, дема publicate временно от него отстала и не будет работать. А вот мой Hello world:

Точка входа index.php

<?php

require '../../framework/qb.php';

Qb::init()->request()->end();

1. Как видите, применил технику fluent.
2. Теперь приложение способно работать вообще без файла конфигурации. Минимально необходимые действия будут выолнены по-умолчанию.

Класс приложения в файле {appDir}/protected/application.php:

<?php

class Application extends QbCustomComponent
{
	public function request()
	{
		echo $this->baseUrl . "<br /><br />\n";
		echo 'Hello world!';
		return $this;
	}
}

$this->baseUrl реально вызывает Qb::get('baseUrl')
return $this необходим для поддержки цепочек fluent (см. выше)

Этот код уже работает, но будем потихоньку усложнять.

События через магию
Теперь события могут происходить в любом компоненте, а не в глассе Qb. Реализовано через магический метод __call — когда мы обращаемся к методу $foo->bar() будут вызваны события
beforeBar, onBar и afterBar. С оговоркой: yfcnjzobq метод bar должен отсутствовать, иначе магия не сработает. Вместо него в классе компоненты мы можем описать onBar()

Снова заглянем в наш стартовый скрипт
Qb::init()->request()->end();
Ядро фреймворка в методе init выполняет некую начальную инициализация и возвращает ссылку на объект-приложение. У этого приложения мы по цепочке вызываем методы request и затем end. Вот на end мы и протестируем события. $app->end() будет вызван как при нормальном завершении, там и при аварийном после ошибки/неперехваченного исключения. Это хорошее место для обязательных действий в конце.

Мой новый механизм событий настроен так, что вместо отсутствующего реального end() будут по возможности вызываться события beforeEnd, onEnd, afterEnd.

Для простоты я описал обработчик в этом же классе. Можно было забиндить сторонние обработчики через $foo->wrap()

Перед окончанием работы выведем на страницу текст ошибок, если они были.

class Application extends QbCustomComponent
{
	public function request()
	{
		1/0; // warning
		echo $this->baseUrl . "<br /><br />\n";
		echo 'Hello world!';
		return $this;
	}

	public function beforeEnd()
	{
		$log = Qb::getLog(array(E_ERROR, E_WARNING));
		foreach ($log as $l) {
			list(, $message, $file, $line, , ) = $l[0];
			echo '<p>' . ($l[2] == E_ERROR ? 'ERROR' : 'WARNING') . ' <em>"'
				. $message . '"</em> in module <strong>' . basename($file, '.php')
				. '</strong> line <strong>' . $line
				. "</strong></p>\n";
		}
	}

Новости с полей:
Документы теперь реально можно редактировать.
Прикрутил простой валидатор.



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

Написал простую демку для испытания каркаса. Лежит в репозитории trunc/demos/publicate/



Всё, что делает — по шаблону мастрячит странички из mardown-файлов.



( Читать дальше )

Let it be!

Я стартую свой проект на PHP: веб-фреймворк Qb. Находясь под влиянием отличного фреймворка Yii, всё-таки хочу получить что-то более компактное и простое, где бы я мог применить свои идеи и наработки без лишнего мусора.

В своём личном блоге я уже писал цикл статей по «минимальному фреймворку». Этот проект будет более «взрослой» версией. Начинается он с Coding Standard, списка минимально необходимого набора классов и диаграммы последовательности работы приложения. Документация на русском лежит в репозитарии.

Как оно работает

Схема типичного приложения вот:




( Читать дальше )

Я решил не дописывать этот шедевр потому что:
1. Настоящий шедевр должен быть слегка незавершенным (шутка)
2. Потому что созрел для написания реального, а не воображаемого мини-фреймворка
… и начну с правильного: с Issue Tracker под этот проект. И первые тикеты в нём: кодинг стандарт и список минимально необходимого.

Список вырисовывается такой:
* суперкласс приложения, он же конфигурация
* аутентификация пользователя
* понастоящему универсальный и быстрый роутер
* протоколирование и профайлинг
* простой менеджер шаблонов

И сразу тестовое приложение — CMS на файлах с парсером Markdown и принципом создания страниц как в Wiki: нет страницы по адресу — можешь её создать (если сил хватит).

Да прибудет с вами сила!

В мозгу многих веб-разработчиков укоренилась мысль, что перерисовка части страницы — это дело AJAX. На самом деле всё не так однозначно. Если использовать мозг, то во многих случаях можно обойтись без AJAX и вообще без JavaScript!

Посмотрите на эти примеры от CssPlay (Stu):


( Читать дальше )

(статья в процессе придумывания)

(См. также
Часть I: Планирование
Часть II: Пригодность для тестирования
Часть III: Элементарный шаблонизатор
Чпсть IV: Маршрутизация)

Предварительные итоги

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

Новый план под катом.


( Читать дальше )

(См. также
Часть I: Планирование
Часть II: Пригодность для тестирования
Часть III: Элементарный шаблонизатор
Часть V: Новые планы)

Приступаю к реализации следующего этапа плана — маршрутизация и представление.
Очередная мазня:


Термины и соглашения

Идентификатор Маршрута однозначно указывает на контроллер и действие. В нашем фреймворке ид. маршрута записывается как строка вида 'ControllerId/ActionId'.

Компонент Роутер разбирает URI сравнивая его с Таблицей Маршрутизации и возвращает приложению разобранный маршрут (или признак неудачи). Описание маршрута приводится ниже с методом control().

Роутер работает в обоих направлениях:

• разбирает входящий запрос и находит соответствующий Ид. Маршрута


• строит URL по указанному Ид. Маршрута и параметрам

Рассмотрим как происходит разбор входящего запроса и передача управления Контроллеру:


( Читать дальше )