Новый микрофреймворк Rumba для PHP

Posted by: Maestro
Date: Sat, 16 Aug 2014 16:55:47
Tags: скачать создать сайт управление сайтом виджет плагин

PHP — это маленькое зло, созданное некомпетентными новичками, в то время как Perl — это большое и коварное зло, созданное умелыми, но извращёнными профессионалами. © Jon Ribbens

Говорят, хардкодить плохо. И длинную лапшу писать плохо. Да и имена транслитом опять же нельзя... Кто спорит, это всё так, хотя страсть как хочется. Да и привычно уже, чего уж там... Но. Раз уж прогресс не отрицаем, и на работу ездим на метро, а не на телеге, то будем стараться, т.е. соответствовать. Да чего уж там, костьми ляжем, но добудем, победим и обеспечим.

Такое странное вступление предваряет мысль, простую, как список технических требований Румбы, а именно: не смотря на полнейшую свободу пыха (РНР) в плане структурирования кода, нужно таки придерживаться некоторых негласных правил, сложившихся в индустрии. Т.е. писать код, понятный и легко читаемый не только автором и единомышленниками, но и сторонними разработчиками.

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

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

Изначально было несколько вариантов устройства фреймворка (буду иногда экономить буквы и называть его ФВ), и хотелось сделать его максимально простым. Однако слишком простой ФВ по моим прикидкам не даст разработчику необходимой гибкости. Простые приложения будет написать очень легко, если чуть сложнее, то надо уже сильно лезть в код фреймворка, и тогда зачем он, собственно говоря, нужен? Таким образом я склоняюсь к мысли, что для простых сайтов нужно использовать сайтовые движки, а никак не ФВ.

Посему фреймворк задуман как архитектура, позволяющая просто реализовывать довольно сложные приложения. Естественно, так или иначе его код впишется в какую-нибудь концепцию, уже сложившуюся в программистком мире. А как иначе, ведь даже для полного бардака придумана философия анархии, матери порядка. Так глубоко копать я конечно не буду, поэтому момент, когда Адам родил Каина всё дальнейшее пожалуй пропущу. Остановлюсь же на популярной и "широко известной в узких кругах" концепции MVC. Это модель, вью и контролёр.

Хоть Румба и не будет напрямую использовать подобную архитектуру, тем не менее её признаки в фреймворке есть: главный класс, это фронт-контролёр (Front), который руководит работой скрипта и пытается реализовать единую точку входа. В то же время более маленькие "кирпичики" приложения выполняются в формате MVP. Это родственная MVC концепция, в которой место контролёра занимает Presenter. Я его называю презентером, хотя и через букву С можно также - пресентер.

Отличие презентера от контролёра в том, что он на себя берёт больше ответственности. В классическом MVC должны быть толстые модели и тонкие контролёры. В MVP презентер (хотя я и старался избегать излишней толщины презентера), это в некоторм смысле ТТУК (толстый тупой контролёр). Кроме того, что важно, в MVP модель не общается с вью, и именно это свойство мной взято за основу формирования презентеров. На сегодня в демке отсутствуют как таковые View, и их функции переданы (хотя и временно), презентерам. Что несколько приблизило презентера к концепции MVVP.

Ну да ладно, выводить родословную архитектуры, это довольно флеймовое занятие, поэтому обратимся опять к фреймворку. Попробую описать алгоритм его работы, он хоть и не сложный, но требует ознакомления. Итак, вначале было слово... Э-э-э, опять Остапа понесло. Лучше напишу алгоритм списком:

В одной статье нет смысла описывать сразу всё, ибо это только усложнит восприятие текста, поэтому обобщу и упрощу описание. Главное, что нужно понять: на каждой странице может быть сколько угодно разных блоков (в концепции фреймфорка - презентеров), например в демке их на страничке по четыре штуки. Эти презентеры могут быть и удалёнными (!), для примера в демке в файле sys/Assembly/Line/Blog/Tape.php раскомментируйте 28-30 строки (если надо, раскомментируйте строку с инициализаией cURL в файле инициализации вашего сервера РНР), и при просмотре демки на локальном сервере на страничке со статьёй внизу увидите результат работы презентера, расположенного на сайте румбы (лишь бы интернет работал).

Вся информация о том, что и как должно быть на загружаемой странице сайта располагается в файле сборочной линии. Задача роутера - разобраться, какую сборочную линию (все они располагаются в sys/Assembly/) нужно использовать. Завод же запускает конвейер и раскладывает по нужному шаблону результаты работы презентеров (реализуя горизонтальный HMVC и давая ещё повод потроллить). Конечно, сборочные линии реализованы не через ООП, так что в перспективе это один из первых участков под рефакторинг.

Поскольку класс Registry, ведающий конфигурацией, оказался невелик, дополнительно на него возложены и функции фабрики объектов. Модель в демке выглядит довольно надумано, т.к. фактически дублирует методы класса StorageDbmsIni, который, как видно уже из названия, является примитивной СУБД, хранящей данные в ini-файле. Такая СУБД выбрана (сделана на коленке) для того, чтобы всё было достаточно прозрачно и понятно, поскольку правила и принципы функционирования фреймворка ещё только формируются (и серьёзную работу с БД реализовывать рановато), а демка должна работать уже сейчас.

Ещё немного пройдусь по удалённым презентерам. Сама идея очень похожа на Ajax версию HMVC. Т.е. загружается шаблон страницы и с неё запускаются автономные сценарии, которые выполняют каждый свою задачу и знать не знают о своих параллельных соседях. Если на сервере презентеры запускаются и выполняются последовательно, один за другим, то внешние сценарии запускаются в параллельном режиме, что может быть удобно в некоторых случаях. Например, у вас есть презентеры, которые работают с большой БД, или выполняют иные функции, которые достаточно ресурсоёмки.

Допустим, таких "тяжёлых" презентеров у вас три, ну и есть шесть лёгких. Время выполнения одного тяжёлого к примеру 0.08сек., а лёгкий выполняется за 0.001сек. Итого, общее время выполнения составит 0.08*3 + 0.001*6 = 0.246 сек. Как вы понимаете. это время генерации страницы немного великовато. Однако если запустить выполнение презентеров на стороннем хостинге, то время выполнения тяжёлых составит 0.08 + t(overhead). Здесь время накладных расходов t(overhead) составит к примеру 0.02сек. Итого, сумма 0.1сек. Тоже немало, но всё же значительно меньше. Важно учитывать и простое http кэширование, которое может существенно снизить величину времени генерации.

Другой интересный момент использования удалённых презентеров может быть в том, что вам неважно время генерации, но гораздо более интересно удобство компоновки презентеров. В этом случае вы можете каждый презентер разместить там, где вам удобно (можно даже на бесплатных хостингах с поддержкой РНР). На сайтах же вы просто манипулируете отображением презентеров посредством формирования сборочных линий. Вот пример, который не стоит использовать, но который наглядно всё это демонстрирует: вы размещаете в одном месте презентер гугловского адсенса и на всех остальных сайтах прописываете этот презентер в сборочной линии.

Не стоит использовать этот пример по причине того, что разместить такой презентер на родном сайте очень даже просто, и ресурсозатраты на это будут крошечными. В тоже время, когда у вас набежит не один десяток презентеров на разных сайтах, к описанной схеме вполне возможно, и надо будет присмотреться. Тут уж всё зависит от деталей. И ещё: в принципе функции презентера можно возложить и на сторонний софт, лишь бы он отдавал результат у нужном формате, который кстати очень простой. Для примера презентера, который не является продукцией Румбы в корень дистрибутива положен (покладен) файлик presenter.php

О составе дистрибутива: в каталоге data/ лежат ТОЛЬКО данные (там точно не лежат и не должны лежать php файлы). В каталоге lib/ лежат классы: Core - ядро фреймворка, Model - модели, Presenter - тут все презентеры, Storage - сюда помещаем вспомогательные классы, View - тут будут располагаться вьюхи (когда появятся). В каталоге sys/ Лежат сборочные линии и конфигурационные файлы презентеров (подкаталог Assembly), а также роуты (Routes) и автозагрузчик с конфигурацией скрипта. В ui/ помещаются картинки, css, и т.п. Правила размещения с подкаталогом модуля (тут в основном фигурирует Blog) видны на примерах, обычно они строго обязательны, но не описываю их, т.к. пока могут и поменяться. Сам код пока в простом состоянии, без проверок и обработки ошибок - эта часть буду делать уже после окончательной утряски архитектуры.

Пожалуй, для версии 0.3.2 я написал даже слишком много. Кроме того, дистрибутив фреймворка дополнен в каталоге doc/ справочником в формате html по классам и методам фреймворка (из-за чего дистрибутив вырос до мегабайта). Поэтому читайте код, анализируйте алгоритмы и критикуйте, на то есть форум.

Смотри также:


Оптимизация тэгов под поисковые запросы  Rumba Blank для новичков программирования сайтов  О вредных комментах замолвите слово  Комментарии и WYSIWYG редактор Rumba News 0.8a  Пример смены дизайна в Rumba XML 






    Сгенерировано
    Rumba News v.1.0a
    за 0.006647 сек.