Создание сайта

При создании сайта, закладывается некий смысл. Т.е. кроме тематики определяется структура сайта, его основной функционал.

Возможно, я что-то пропущу, но перечислив основные типы сайтов, Вы сможете понять о чем я.

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

Общая мысль у всего этого — каждый сайт имеет основное назначение. Каждый из них умеет хранить, к примеру, статические страницы, но всегда есть основной модуль который доминирует при использовании сайта.


Таким образом наша система должна иметь модуль по-умолчанию. Который будет использоваться для разрешения большинства запросов. Этот модуль не будет фигурировать в строке адреса.

При наличии модуля по-умолчанию становиться возможным создавать урлы которые максимально дружественны для понимания. Например http://domain/ru/multimedia/video/skazka/ говорит нам о разделе, подразделе и конкретной странице (или более глубоком подразделе), нам не нужно при этом строго описывать модуль ответственных за данный запрос. Это свойственно для сайтов визиток, где основной контент — статические страницы.

Обработка урла при разборе запроса.
Самое логичное, что можно предположить, что если вызывается модуль не по-умолчанию, то какой именно модуль вызывается, можно определить по первому сегменту запроса. Например http://domain/ru/catalog/view/skovorodka.

Так же, ядро может руководствоваться некоторым набором соответствий. Или же все внештатные ситуации могут предусматриваться в роутинге сайта.
Но конфиги роутинга, согласитесь, штука не из простых хоть они и предпочтительнее по гибкости использования. Я для себя решил, что ядро будет использовать одну таблицу в БД для хранения разноплановых переопределений. Такие определения могут помочь для случая перевода сайта с другого движка или даже с html-версии. При этом будет важно, что при этом делать — или делать правильный редирект на новый урл страницы, или же выдавать нужный контент.

---

Эта короткая статья подводит нас к началу обсуждения деталей ядра. На данный момент, нам уже нужен механизм работы с хранением и обработкой параметров системы.

Так же, здесь я опишу основные моменты которых будет придерживаться мое дальнейшее повествование.

• Ядро и основной код модулей (контроллеры, модели, библиотеки, отображение админ-части) хранятся отдельно от сайта.
• Система должна быть построена таким образом, что ядро и модули, будучи подключенными к конкретному сайту (по средствам симлинков для *nix систем) могли работать сразу на нескольких сайтах. Таким образом студия сможет поддерживать на всегда актуальном коде сразу несколько сайтов. Это не подразумевает непосредственное управление несколькими сайтами из одной админки, но и не запрещает это в будущем.
• Каждый сайт должен обладать возможностью иметь собственные особенности работы.
• Модули должны иметь возможность вмешиваться в ход работы системы на уровне как стандартных hook’ов фреймверка, так и других моментов работы системы. Нужны механизмы которые позволят подключать динамически плагины к чужим модулям и производить взаимодействие между модулями и между ядром и модулями.
• Для модулей должен существовать четкий и продуманный механизм работы с обновлениями для этих модулей. Разработчик модуля не должен тратить время на изобретение собственных механизмов обновлений своего модуля.
• Весь исполняемый на сервере код должен храниться за пределами видимости из вне. Думаю, здесь пояснения излишни.
• Added: Ядро должно помогать гибко формировать адреса ссылок в системе. Но и не мешать сформировать адрес основываясь, только на своих правилах.

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