mooFrame
Доброго времени суток, уважаемые!
По известным причинам (по большей части - Magento и фриланс) написал фреймворк на похапэ (блин, как последний школьник! (да простят меня последние)). В чем же преимущество да и вообще уместность данного средства? mooFrame - прост, как дубина, но при этом достаточен для написания приложений чуть быстрее, нежели на голом похапэ или при использовании различных фреймворков вроде Magento, CodeIgniter, Cake PHP и иже для людей, не желающих в них разбираться (к последним я сам и отношусь - далее - подробнее). Как-то давно; очень давно; очень-очень давно мне предстояло написать очередной сайт. С нуля и на похапэ (выбора хостинга у меня небыло). Поглядел на один фреймворк, поглядел на второй - ни один не радовал отсутствием необходимости разбираться менее часа. И тогда я написал сайт на "голом" похапэ, проект завалился, мне не заплатили, в общем все было плохо. Но не так давно я увидел Magento и по сей день с ним работаю. Если быть точным, то дорабатываю рашпилем известного калибра. Но как же радует глаз картина, когда любая страничка, практически статического контента содержанием грузится минуту а то и две!.. И вот тогда-то мне в голову начали заползать мыслишки навроде "надо сделать свое, теплое да уютное сЪредство". Прошло несколько недель и наконец я закоммитил на гитхаб ветку под названием "Alpha" (и даже гордо ей логотип прилепил, по-быстрому врезанный в Gimp'е под конец рабочего дня). В чем же соль сего эпического творения? Ну вот создаете, к примеру, вы приложение на том же Cake PHP или Code Igniter. Что вы первым делом пишете из кода? Верно, что-то вроде `class MooController extends FooFrameworkControllerAbstract...`. А вот контора, которая вас попросила сделать ей сайт, сказала, что окромясь страничек "контакты", "о нас", "прайс-лист" да "главная" им ничего и не нужно. И вот для таких случаев у меня в голове ползало мыслишко "А зачем обязательно иметь класс для одностраничного контроллера?". И таким образом и появилось два правила у mooFrame: "если в файле контроллера есть класс - хорошо. Ну а если нету - не вопрос! Тогда мы просто выполним код этого файла!" и "не нужно ничего наследовать! Достаточно уже иметь обычный класс!". Следующим нововведением стала система рендеринга. Дело в том, что в Magento, дабы вывести надпись "Hello, World!", вам необходимо создать блок, определить его в XML-файле, создать в нужном месте темплейт, унаследовать класс блока от Mage_Core_Block_Template (или как-то так) и в тимплейте вывести надпись любым доступным методом. Вот у меня и возникло теплое такое воспоминание о тех временах, когда я баловался RoR. И был произведен на свет класс Renderer с двумя методами (идентичными с виду) - render и partial. Оба работают совершенно одинаково (пока) и рисуют указанный файл с указанными параметрами (которые не нужно передавать из класса блока в темплейт посредством довольно-таки странного средства как "реестр Magento"). Но в отличие от моего стажерского подобия фреймворка, равно как и в отличие от RoR, в mooFrame не будет рендериться файл с именем вызванного Action или Controller - здесь вы сами хозяин того, что вы рендерите, а что - нет. Связующим звеном стал роутер - класс, который принимает запросы пользователя/браузера и передает управление конкретному приложению, контроллеру или Action'у. В DocumentRoot сервера, по правилам mooFrame (по большей части из соображений безопасности) должен находиться лишь один файл - index.php, который передает управление роутеру в две строки кода. Роутер, в свою очередь, рассматривает запрос пользователя и переходит к выполнению одного из двух действий: выдаче содержимого файла и заголовка с его META-info или же поиску необходимого приложения или контроллера/действия (повторюсь, в mooFrame контроллер без класса - это то же, что и контроллер без действий - достаточная единица для передачи управления). Стоит отметить и "множественность приложений" mooFrame: вы можете иметь несколько приложений с множеством своих собственных контроллеров. Указав в настройках орутинга конкретного приложения, на какие из запросов пользователя и как должно откликаться ваше приложение, вы можете запустить цепочку контроллеров/действий. Причиной сего стала схема роутинга Magento: дабы реализовать подобное у них (разработчиков Magento) есть два пути - определить роутинг "хардкодом" - явно указав, на какие запросы какой контроллер/блок будет вызван или же создав класс-listener (есть некоторое сходство с Java, как я понял) и "слушать" события, которые происходят. Проблемма лишь в том, что далеко не всегда будет "слышен" сигнал о выполнении какого-либо действия. Последней плюшкой которую я отмечу в данном посте (по крайней мере - последняя, которую я сейчас способен вспомнить и описать) будет работа с базами данных. Для этого во фреймворке предназначен один класс с тремя методами - connect (соединяется с СУБД и возвращает локальное, уникальное, независимое имя соединения, которое и должно использоваться в двух других методах), query (выполняет запрос к указанному именем соединению; в запросе запрещено использовать строки в "чистом" виде - что-либо, указанное меж кавычек одинарных или двойных будет завершать работу метода) и forceQuery (в котором эти самые строки и разрешены). Все хапросы возвращают стандартные массивы стандартных хешей, у которых ключ - имя столбца таблицы. Работа с БД возложена на PDO. Изврат со строками был создан во избежание SQL injections. PDO - во избежание труда. Конечно же, Active Record - привлекательный, весьма даже привлекательный паттерн, но Magento с его реализацией оного моментально отбросила всякое желание реализовывать любые абстракции и модели для БД. На этом пока закончу описание mooFrame. Детали по установке на Apache и исходные коды можно взять на GitHub. В данный момент идет бурное обдумывание вопросов реализации модульности ядра, системмы и Store расширений и тестирования системмы (папочку test пока не глядите - файлы там очень уж out-of-date). Из требований у mooFrame:
На этом пока все. Всем (и себе - в том числе) желаю спокойной ночи. |
Ответ: mooFrame
Бл*, я даж не знаю чо сказать по этому всему поводу. Старания - это всегда похвально. Но...
В случае магенты одностраничность легко решается через CMS Pages и блоки или модули. В случае моего любимого Yii пишется шаблон для генератора. Если надо чо-то по быстрому, берём вордпресс/джумлу. Нахуа этот велокостыль? Если есть желание и силы, лучше направить их в какой-нить открытый проект типа того же Yii, пользы в разы будет больше. Или наследие Болконского работает? :) --- Тем не мнее. 1. Почему в коде автор и дата не проставлены? 2. Почему говностиль написания кода? 3. Почему нет комментов и тегов для PHPDoc, не говоря уже о самой документации? 4. Зачем тебе тут ООП, если у тебя чисто процедурный подход? |
Ответ: mooFrame
Цитата:
Код документировать вроде и не собирался. По поводу остальных вопросов - RTFM, еды я вам не дам. |
Ответ: mooFrame
Цитата:
Да никто троллить не собирается. Мне реально интересно узнать ответы. |
Ответ: mooFrame
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
|
Ответ: mooFrame
Цитата:
Database и Application должен быть синглтоном. Log, Router, Renderer - либо обычными классами как адаптеры, либо тоже синглтонами. И если это нужно ТОЛЬКО тебе фо персонал пурпосес, то нафига было писать? Цитата:
|
Ответ: mooFrame
Цитата:
а) он морально устарел б) используется в основном (если не исключительно) необразованными разработчиками в) имеет множество недостатков (так, коль будет определена функция log(), возникнет довольно-таки хороший конфуз у интерпретатора; а коль называть функции logErrorMessageIntoFile() и иже - тогда возникает сомнение в необходимости разработки фреймворка; с другой стороны, глобальные переменные имеют точно такой же набор проблемм) Синглетонами Log, Renderer и Router быть смысла нету - это static classes (жаль, что похапэ не имеет понятия о таком). У них и объектов-то быть не должно. Зато благодаря сему имеем два профита: 1) избавляемся от юродливых неймспейсов похапэ 2) разрешаем конфликты имен Database и Application - два совершенно разных класса. Первый имеет сугубо абстрагированный функционал, посему он, как и Log, тоже статичен. А Application - наоборот, работает с внутренностями конкретного приложения, посему есть "обычный класс". Я ж просил почитать исходные коды, а не имена файлов... Цитата:
И все равно - благодарю за дискуссию! |
Ответ: mooFrame
Цитата:
|
Часовой пояс GMT +4, время: 07:46. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot