Справка
Принцип построения приложений
Приложение может состоять из одного или нескольких модулей. Разбивать на несколько модулей имеет смысл в том случае, если отдельные модули планируется использовать в других приложениях. Если функционал не подразумевает использование и хранение собственных данных, его следует выносить в компоненты.
Разработка приложения состоит из 3х этапов:
- Составление архитектуры
- Настройка обработчиков
- Наполнение данными
1. Составление архитектуры
Оперируемая модулем информация типизируется в виде набора таблиц. Каждой таблице задаётся нужное количество полей нужных типов. Для обеспечения связи между таблицами создаются поля-ссылки (один к одному или один к многим) и дочерние таблицы.
Основным принципом составления архитектуры является естественность.
Остановимся подробней на этом принципе. Любая задача, связанная с веб-разработкой предполагает известный набор данных, с которыми приложению предстоит работать. Если речь идёт о интернет-магазине, то предстоит работать с товарами, категориями и заказами. Если речь идёт о CRM, то работать нужно с сотрудниками, клиентами и проектами. Если это городской портал, то для работы нужны будут новости, компании, объявления и вакансии.
Задача фреймворка состоит в том, чтобы обеспечить бесшовный перенос необходимого набора типовых данных из головы клиента/разработчика в систему.
В идеале, этот процесс не должен быть сложнее зарисовки архитектуры приложения на бумаге.
Фреймворк берёт на себя следующие рутинные задачи:
- хранение данных в СУБД MySQL
- обеспечение экземплярности
- обеспечение взаимосвязи между объектами
- генерация табличного представления данных для административного кабинета
- генерация форм для административного кабинета
- генерация фильтров для административного кабинета
- индексация данных для дальнейшего морфологического поиска
- поддержка актуальности модулей и компонентов через генерацию схемы обновления
- генерация URL-роутинга (автоматическое определение нужных обработчиков и объектов по URL)
- обеспечение повторного использования структур за счёт интеграции модулей
- сбор статистики посещений по объектам и событиям
- уведомления нужных групп пользователей о событиях
- предоставление и обработка прав доступа для всех созданных структур
- работа с файлами, связь файлов с объектами
Если архитектура приложения предполагает связь между данными и пользователями, то создаются необходимые группы пользователей, на которые в последствии ссылаются нужные поля нужных таблиц.
Для этих групп предоставляются необходимые доступы и устанавливается корневой каталог для работы с файлами (если это необходимо).
2. Настройка обработчиков
На сегодняшний день существует много систем, довольно успешно реализующих 1ый пункт с архитектурой. Однако, когда дело доходит до подключения логики (т.е. написания кода) возникает масса рутинных действий. Объяснить это можно разным уровнем абстракции данных и кода. Для того, чтобы программисту получить доступ к данным из кода приходится использовать сложное API.
Абстрагирование кода до уровня данных поможет разработчику избежать рутины. Для этого предлагается использовать визуальный конструктор, который имеет тесную связь с построенной разработчиком архитектурой данных.
Разработка обработчиков начинается с определения возможных интерфейсов и их привязке к данным. После этого создаются вспомогательные части и виджеты.
Пример с интернет-магазином
Какие интерфейсы приходят в голову при мысли о интернет-магазине?
| Главная страница | Вызывается по / (корень URL) |
| Страница категории |
Связан с таблицей “Категория товара”
Вызывается по её полю URL с учётом иерархичности категорий. Например: /category/sub |
| Страница товара |
Связан с таблицей “Товар” по её полю URL, является дочерней для части “Страница категории” Например: /cat/item1 |
| Страница акций и спецпредложений | Вызывается по URL /actions |
| Корзина товаров | /cart |
| Оформление заказа | /order |
| Персональный кабинет | /personal |
Какие элементы можно вынести в отдельные части?
Анонс товара (для его использования в категории товаров, странице акций и корзине)
Какие виджеты будут необходимы?
- Топ популярных товаров
- Топ товаров по акции
- Виджет корзины
Далее для каждого обработчика пишется логика его работы.
Обработчик представляет из себя многоуровневый массив следующих элементов:
- Текст (как правило, используемый в вебе для HTML вёрстки)
- Команда шаблонизатора
- Настройка кеширования
- Цикл
- Условие
- Блок (аналог функции)
- Комментарий
Если составление архитектуры данных не должно вызвать затруднений для людей не знакомых с программированием, то разработка обработчика предполагает понимание циклов и условий. Однако можно обойтись и без них, если существует набор компонентов, способный выполнить необходимый функционал.
Команда шаблонизатора, а также аргумент условия и цикла представляет из себя набор (или одну) из следующих операций:
- Операции приравнивания переменных
- Логические операции: And, Or, ==, !=, <, <=, >=, >, !
- Математические операции: +, -, *, /
- Цепочка шаблонизатора / текст / число
Более подробно можно прочитать об этом в документации к шаблонизатору.
Цепочка шаблонизатора представляет из себя специально сформированную последовательность команд, связанных с архитектурой данных и текущими оперируемыми объектами обработчика.
Цепочки предполагается формировать с помощью специального визуального редактора, однако допускается и их ручное программирование.
Примеры цепочек для обработчиков интернет-магазина
Для части “Категория товаров”
Аргументом цикла вывода всех товаров категории будет цепочка:
[“Текущая Категория”.”Подтаблица Товары”.”Все активные элементы”]
Для части “Анонс товара”
[“Текущий товар”.”Поле Изображение”.”Компонент Вывод картинки с увеличением”]
[“Текущий товар”.”Цена”]
[“Текущий товар”.”Валюта” (ссылка на таблицу валют).”Краткое наименование”]
Для части “Корзина”
Аргументом вывода списка товаров в корзине будет цепочка:
[“Cookies”.”Товары в корзине”]
Цепочка в теле цикла:
Название: [“Текущий элемент цикла”[0].”Поиск объекта по его номеру”.”Название товара”]
Количество товаров: [“Текущий элемент цикла”[1]]
Некоторые команды могут иметь аргументы, описываемые в аналогичном формате.
Аргументы для компонентов и блоков указываются в следующем формате:
[компонент(аргумент 1=значение 1, аргумент 2=значение 2 …аргумент N=значение N)]
При создании цепочки из визуального редактора, разработчик выбирает один из 3х типов команд:
- Текущие данные
- Конструкции языка
- Компоненты
Текущие данные подбираются в зависимости от редактируемой части. Если редактируется часть модуля, то будут доступны к выбору текущие таблицы и переменные модуля. Если часть связана с конкретной таблицей, то будут доступны для вставки поля определённого объекта.
Вставив поле, связанное с объектом другой таблицей, пользователь может перейти к полям этой таблицы. Вставив поле “текст” пользователю предложат один из обработчиков текста (например разбивка, длинна или поиск). Если пользователь дошёл в цепочке до массива (например, выбрав поле “теги”, ссылаемое на множество объектов таблицы “теги”), то ему будет предложены обработчики массивов (первый элемент, последний элемент, количество элементов).
Таким образом, конструктор цепочек объединяет в себе статические и динамические конструкции. Статические определены ядром системы, а динамические напрямую зависят от той архитектуры данных, которую пользователь заложил в текущий модуль.
Идеальный процесс разработки обработчика выглядит как “накликивание” нужных конструкций из визуального редактора. В этом смысле с разработкой обработчиков способен справиться не только программист, но и обычный верстальщик. А если говорить о редактировании или добавлении функционала к готовым обработчикам, то можно смело заявить, что с этим справится совершенно неискушённый в программировании пользователь (например, клиент).
3. Наполнение данными
Этот этап разработки необязательный и заключается в наполнении созданных таблиц необходимыми данными. Интерфейс для этого генерируется автоматически фреймворком, при создании архитектуры данных.
Читать далее про "API"
