Сейчас мы позанимаемся образцово-показательным проектированием и планированием. Да и вообще, делать что-либо без идеи и цели не имеет никакого смысла, пустая трата времени. Итак, приступим.
Определим цели. Во фреймворке необходимо обеспечить:
- доступность понимания структуры и кода, чтобы начинающий программист мог его освоить
- некоторый уровень технологий, чтоб джыдаю было не скучно
- не изобретать велосипедов
- зы: совсем забыл! заложить в архитектуру максимально возможный уровень расширяемости и не заниматься преждевременной оптимизацией
Осмотревшись, мы находим PHP - достаточно распространённый скриптовый язык с очень (ОЧЕНЬ!) низким уровнем вхождения. В принципе, это проблема пхп, из-за которой он получил дурную славу. Попробуем вернуть языку его достоинство.
Внутренним (и внешним) единым форматом передачи данных примем XML. Что может быть проще и технологичней?
И в случаях затруднений будем руководствоваться принципом KISS Keep It Simple, Stupid - Не тупи, будь проще.
Маленькое лирическое отсутпление. Во время работы в %COMPANYNAME% в среде программистов был изобретён принцип JMS Just Make Simple - Просто сделай проще. От часто прозносимых фраз: "Давай сделаем это проще", "Я знаю как проще". Стали ли они продолжать линейку JMS CMS, я не в курсе.
Продолжаем. Пишем мы фреймфорк для веба, то бишь, чтоб делать сайты. Сайт, в конечном итоге, это текст, причём, текст структурированный. Понятию тега разметки практически идеально соответсвует понятие блока. Да и визуальное оформление обычно составлено из вложенных блоков.
Введём основное понятие фреймворка: модуль - основная и единственная структурная единица фреймворка. Хотя, на самом деле,)) модуль может быть и исполняемым кодом, и шаблоном, и чем-нибудь ещё.
Введём соглашение: каждый модуль обязан возвращать XML. Всегда. Пусть пару строк, но возвращать (как будет видно дальше, мы немного отсутпим от правила, самую малость). Обратно, всё, что не является модулем, не обязано возвращать XML и всё, что не возвращает XML, не является модулем.
Вспомним хитрое слово ReST, которое, в принципе, ничего конкретного не представляет, или, наоборот, представляет слишком многое. Это и технология, и способ, и принципы, и идея; остановимся на слове RESTful подход. Для нас это будет означать Человеко-Понятный Урл + принцип передачи параметров (формирования запросов) в модули + структурированность иерархии модулей, аналогичную URL.
Принцип работы сайтов, по большому счёту, заключается в получении данных, их сохранении и визуальном оформлении.
Основной единицей информации назначаем сущность - Entity. Сущность подготавливается по описанию. Это второй объект, который мы напишем. Первым будет, конечно, хранилище (Storage) сущностей. Хранилище должно реализовывать интерфейс CRUD Create Read Update Delete. Элементарно.
Введём второе соглашение: каждый объект, работающий с данными, принимает и\или возвращает объект типа "сущность".
Тут были упомянуты формы, хорошо бы объектик для работы с формочками по принципу принял-завалидировал-отдал, но об этом в следующей части.
Хм, теперь под выбранную идеологию подберём инструментарий. Это будет:
- уже упомянутый PHP в связке с Apache. Тип связи с веб-сервером и сам веб-сервер могут быть любыми, это пока не принципиально, но Apache + mod_php весьма распространены, будем ориентироваться на такой тип.
- т.к. XML клиенту (пользователю) не интересен, подключим XSLT и нагрузим преобразованиями клиента (браузер) - проверено, работает
- добавим к этому грамотный CSS и какой-нибудь javascript framework: не мудрствуя долго, остановим выбор на jQuery
- выбор физического воплощения хранилища представил некоторую проблему. Основное требование: нативное хранилище объектов. Но объектно-ориентированные базы весьма нетривиальны и не удовлетворяют требованию простоты фреймворка.
Ещё одно лирическое отступление. В процессе поиска наткнулся на одно интересное решение: база не имеет собственного клиента, доступ через http RESTful или через API, возвращает xml или json, обращаться можно хоть из javascript. Оригинальное решение и достаточно старое. Но я не поставил вовремя закладку, а название забыл! %( Но в этот фреймворк тоже не подходит в виду излишней оригинальности.
Остановился на PostgreSQL с дополнением для XML, кстати, прекрасно работает.
Не забываем переложить бизнес-логику на базу, это её прямое назначение.
Итак, что мы насобирали:
RESTful + modulability (гхм)
XML
Entity-Storage-CRUD
PostgreSQL
PHP
Apache
XSLT+CSS+jQuery
Всё!
Энжой :)
За два часа вроде бы уложился
зы: тру пхп-кодер спросит: где же шаблонизатор? а вот php и есть шаблонизатор, если кто не в курсе
Сообщения
