Справка

Принцип построения приложений

Приложение может состоять из одного или нескольких модулей. Разбивать на несколько модулей имеет смысл в том случае, если отдельные модули планируется использовать в других приложениях. Если функционал не подразумевает использование и хранение собственных данных, его следует выносить в компоненты.

Разработка приложения состоит из 3х этапов:

  1. Составление архитектуры
  2. Настройка обработчиков
  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"