Основы архитектуры

Материал из Smart Core Wiki

Перейти к: навигация, поиск

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

Т.к. движок изначально спроектирован на логическую структуризацию, то такое понятие, как ЧПУ (человеко-понятный URI) является присущим явлением. Предположим пользователь запросил страницу, по адресу:

http://site.ru/about/company/blog/first.html

В случае если бы веб сервер небыл настроен на динамическую обработку запросов и отдтавал контент нативным способом, то клиент получил бы файл first.html, который находится по пути /about/company/blog/ относительно корня куда настроен домен site.ru.

Разумеется в Smart Core CMS для каждого запроса нету папок и файлов, которые располагаются на файловой системе ОС, но концепция папок заложена, они реализованны как бы в виртуальном формате. Это означает, что структура сайта строится именно также, как будто создаются папки в ОС. Такое устройство «роутинга» позволяет легко манипулировать структурой сайта т.е. можно в любой момент переименовать папку или переместить в другое место, притом пути изменятся, но все модули продолжат корректно работать находясь в другом местоположении.

Но как и в файловой системе, папки являются всего лишь средством структуризации данных, которые нужны пользователю. В операционных системах полезными данными являются «файлы». В Smart Core полезные данные, которые выводятся на запрошенных страницах сайта, называются «узлы» или «ноды».

Например страница некоторого сайта http://site.ru/ будет иметь следующий макет, где head, menu, content и footer — являются «блоками».

<!DOCTYPE html>
<html>
<head>
    <title>{{ html.title }}</title>
    <style type="text/css">@import url(screen.css);</style>
</head>
<body>
    <div id="head-wrapper">
        {{ head }}
    </div>
 
    <div id="menu-wrapper">
        {{ menu }}
    </div>
 
    <div id="content-wrapper">
        {{ content }}
    </div>
 
    <div id="footer-wrapper">
        {{ footer }}
    </div>
</body>
</html>
Рис.1 "Макет"

А вместе со стилями будет схематично выглдеть примерно как на Рис.1.

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

Рассмотрим пример, какие ноды могут располагаться в каждом блоке нашего примера. В блоке head будет нода с текстовым блоком (модуль Texter), в котором будет помещен html фагмент, например с логотипом, заголовком и небольшим вступительным словом компании. Далее в блоке menu будет модключен модуль Menu, который отобразит навигацию сайта. В блоке content предположим будет 2 ноды, сначала будет следовать некое приветственная текстовка со вступительным словом (модуль Texter), а за ней нода с блоком последних новостей. В футере будет тоже подключен модуль Texter и там будут например контакты, копирайты и т.д.

В отличие от операционных систем, на сайте запросив ресурс по адресу http://site.ru/about/ пользователю надо отдать почти такую же страницу, как на главной, но с 2-мя изменениями: 1) содержимое блока content для каждой папки уникально, по этому в нашем примере по адресу http://site.ru/about/ в контенте не будет нод привязанных на главной странице, а будет например просто текстовка на тему «О компании». 2) в блоке с меню, изменится стиль отображения пункта меню, который ведет на страницу, которую мы запросили. А вот хеадер и футер должны остаться без изменений. Такой результат достигается при помощи кофигурирования блоков, в нашем случае следует указать в свойствах блоков head, menu и footer, что им следует наследовать ноды, которые они включают начиная с корневой папки сайта, а блок conent не будет обладать такими свойствами, по этому на каждом разделе сайта его содержимое будет уникальным, это означает, что если подключить ноду в контенер контент и какую-то определённую папку, то эта нода будет отображаться только в заданной папке.

Вернёмся к нашему примеру и рассмотрим как поступит движок, при получении запроса http://site.ru/about/company/blog/first.html. Здесь разумеется первым делом будут просмотрены, существует ли, такая структура папок т.е. папка about должна находиться в корне сайта, папка company должна находиться в папке about, ну и разумеется папка blog должна находиться в company. Но когда дело доходит до разбора последнего фрагмента части УРИ «first.html», то движок уже не будет искать его в папке blog потому, что в свойствах этой папки будет указано значение router_node_id равное ID ноды модуля блога, которая подключена в папку blog (также можно добавить, что эта нода будет подключена в блок content т.к. содержимое будет выводиться именно в эту область сайта) и именно этому модулю будет передан этот фрагмент запроса и будет ожидаться от него ответ, если модуль ответит утвердительно (т.е. да действительно запись first.html в блоге есть), то движок продолжит свою работу.

Что будет происходить после того, как парсер движка распарсил всю строку запроса, а именно «/about/company/blog/first.html» и закончил работу с положительным результатом. А далее движок начнёт собирать весь список нод, которые надо собрать для этого запроса. В нашем случае он найдет 4 ноды:

  1. Текстовка в шапке
  2. Меню
  3. Текстовка в футере
  4. Блог, притом модулю блога сразу бует передан результат парсинга фрагмента URI first.html, скорее всего это будет ID некой записи, которая находится в блоге под техническим именем «first» и в данном режиме модуль блога выдаст только текст запрошенной записи.

После получения данного списка, движок опросит каждый из этих модулей с параметрами, которые указаны в свойствах соответствующих нод, а результат работы всех этих модулей, ядро поместит в общий массив данных (объект класса ЕЕ).

После того как получены все данные, которые надо отобразить, запускается механизм шаблонизации. Принцип его работы достаточно прост, в общем массиве данных, для каждой ноды, помимо данных для отображения, указывается также и имя шаблончика, который знает как правильно отобразить предназначенные для каждой конкретной ноды данные в виде HTML. Таким образом шаблонизатор как конвеер собирает итоговую HTML страницу, на основе полностью готовых для отображения данных.


Алгоритм в более сжатом виде отписан на странице -> Алгоритм.

Личные инструменты
Пространства имён
Варианты
Действия
Основные разделы
Ссылки
Навигация
Инструменты