Массовое улучшения ряда компонентов

Разработана серия классов поддержки работы с сетью

Был стабилизирован Util\Communication\Connection, и более пригоден для стандартного использования везде где это возможно.

Так-же посредством потоков мы доработали давнюю идею Заранее определяемых "Последовательностей Поточных Команд", В виде Спецификации - которая определяет возможные команды, опознание кодов и реакции на желаемые коды. Так-же есть возможность в Спецификации, определить Описания для каждого отдельного кода, как глобально так и на уровне определенной команды. Команды определяются в виде строки в которую можно заключать плейсхолдеры, значения которых подставляются из аргументирующих параметров команды, которые в свою очередь могут задаваться в управляющей "Последовательности" Sequence(Последовательность) - определяющаяся пользователем комбинация указанных команд, параметры потребуются только в момент выполнения "последовательности"

Компонент построен таким образом что можно составить спецификацию любого API с которым взаимодействие происходит через сокеты.

Корректирование Гипертекстового процессора

Был изменен компонент поддержки Гипертекста, во первых он был переименован с TextTrasfer > Htt > Hypertext, В него интегрирована поддержка потоков, раньше работа была только со строками, теперь вся работа идет через специальные потоки которые можно замещать разными способами реализовав или использовав наследников StreamInterface | StreamInteractionInterface (Которые так-же были сформированы в этом рефакторинге)

Гипертекстовый документ использует Процессоры (Чтение и Запись), с помощью которых он рендериться куда либо или парситься откуда либо, процессоры помимо потока также используют еще и свой внутренний или замещаемый буфер, куда и записывается сырой текст определения документа - буфер можно отключать для экономии. Так-же класс Гипертекстового Документа поддерживает Пул Заголовков, которые были реализованы еще ранее и так-же выполняют работу поведения (encodeContents & decodeContents). Документ реализован дополнительно с возможностью наследования, данная возможность уже используется в HTTP агенте(клиенте) (Util\Communication\HttpClient)

Реализован HTTP-Client (Возможность имитации работы браузера)

Компонент http-клиента, Основанный на интерфейсах Util\Communication\HttpFoundation и спецификации Util\Communication\Hypertext, компонент был задуман с целью достижения максимально удобного и совместимого взаимодействия с удаленными API, по принципу эмулирования работы браузера (Поддержка редиректов, реакция на заголовки и коды ответа, переходы referrer, Cookies и Кеширование страниц)

Устройство этого HTTP-Клиента при работе подразумевает пучок без разрывных соединений(KeepAlive).

Контроль Доступа: ABAC был внедрен в структуру MCA-системы приложения.

Контроль доступа и ответное поведение на запреты можно производить на любом звене MCA системы. По умолчанию контроль доступа производится перед выполнением MCA-Действия

Реализован компонент Верификации личности пользователя через сторонние источники/сервисы.

Это позволяет без лишних хлопот верифицировать определенные действия в системе (На уровне MCA-Системы и так далее). Верификацию можно связывать с Объектами ORM и другими

Улучшена работа MCA-системы

Работа Process::forward() и реакция на ошибки теперь происходит предсказуемо

Добавлен компонент EventManager для связывания всех компонентов которые используются на уровне с MCA-Системой, В связи с этим теперь поддерживаются Плагины(Слушатели множества событий) с помощью которых можно внедрить особый функционал в ваше приложение. В данный момент подобный подход ограничивается MCA системой но в будующем будет и на уровне ORM в целях синхронизации с удаленными сервисами через HttpApiInteracting (Компонент взаимодействия с удаленными API)

Работа с ORM Коллекциями на уровне MCA-Системы Декорирована в спец класс Data Distributor

Который позволяет настраивать Фильтры и Постраничность при работе с MCA-Действиями которые по семантике относят себя к отдаче Коллекции объектов определенной Модели, так-же работа дистрибутора не ограничивается MCA-Действием и может работать в глобальном скопе без привязки к MCA - в глобальных шаблонах View

Также в числе этого обновления расположились множественные изменения стандартов вспомогательных Утилитарных средств

Обновление инфраструктуры приложения

Предварительные состояния MCA

Реализована реакция MCA системы и Отображений на ошибки при обработке Действия.

Задачи(Process)

Для процесса могут быть указаны задачи по ключу, которые в любом случае распознаются перед выполнением действия, если задачи присутствуют, то отображение будет отрисовывать предварительное состояние действия(Инструкции для ввода с указанием на задачи перед отправкой формы серверу)

Чтобы поставить определенную Задачу, можно выбросить исключение которое обрабатывается и распознается модулем в обработчике исключений, как Задача, там и произойдет добавление задачи и информации по ней, в таком случае это будет сам объект исключения.

Поддерживаемые исключения порождаемые Задачи:

• AccessDenied(Задача: 'access') - Проблемы прав доступа
• AuthenticationMissed(Задача: 'authentication') - Промах при указании пары логин пароля.
• ValidationCollector(Задача: 'validation') - Исключение порождаемое в логике ORM, Валидатором. Содержит указания на названия полей и их правила, по которым проверяется значение каждого поля
• NeedIntroduce(Задача: 'introduce') - Исключение распознается MCA как требование к вводу данных, по логике системы, это исключение выбрасывается когда в Действии из Процесса был затребован параметр которого там нет, а это означает что параметр не был введен в поля - в первую очередь, а уже магия задает что при первом обращении к контроллеру, поля так или иначе не будут введены и должна отобразится форма(инструкции для клиента о параметрах требуемых на вход), NeedIntroduce задает Задачу которая автоматически отправляет Отображение на Предварительное состояние

Обработка задач в Отображении

Если Процесс получил какие-то задачи, это автоматически задает Отображению, Режим предварительного состояния при отрисовке, которое запускает соседний Целевому, Шаблон,(Шаблон предварительного состояния действия ({template_name}#prepare.phtml)) в котором по смыслу должна находится структура предварительного состояния: Это Форма, ошибки и т.д.

Целевой Шаблон отрисовывается только в случае если задач или ошибок в Процессе нет, что равносильно успешно выполненному Действию.

Как известно, в отображениях доступен объект Process, в нем мы и можем узнать какие задачи были поставлены, и отреагировать на них, разобрав их структуру.

Валидация

Добавлена система валидации данных в Jungle\Util, компонент представляет собой основу для обеспечения или реализации функционала валидации и проверки правильности данных как при вводе так и внутри системы.

Детализированная система Правил проверки и Грамотная система ошибок (сообщений) которая работает на основе исключений (Элементы EDD), дают возможности обрабатывать ошибки на клиенте, отображать их генерируя на сервере и отправлять запакованный вариант в формате JSON.

Важным качеством с точки зрения внутренней инфраструктуры является то, что при внедрении в ORM Валидация может проходить в системном режиме (Выбросить исключение в глобальный скоп) и в режиме Сборщика - этот режим позволяет обрамлять валидацию отдельно и собирать ошибки всего спектра работы валидации (Присвоение значений полям, сохранение) в отличие от единоразовой тревоги с системным режимом.

Кроме того для правильной и удобной работы валидации, был интегрирован класс TransientState который обеспечивает локальный контроль версий данных объекта, с помощью снимка изменений stateCapture() и отката изменений stateRollback() и stateRecover() stateShift()

Это позволяет нам в данный момент начать реализацию Обработки ошибок в MCA архитектуре, т.к теперь у нас есть элементарные ошибки в виде детализированных стеков ошибок по полям (для объектов, CRUD).

Система валидации поддерживается предварительным состоянием отрисовки, где и можно контролировать правильность ввода данных.

Распределение прав доступа

Дополнительно был доработан и переформирован компонент Распределения прав доступа, который работает базируясь на Атрибутах (Attribute Based Access Control)

Обновления инфраструктуры приложения

Упрощение определения Приложения в целом

Упрощены способы определения и инициализации конфигурации приложения.

Стратегия запроса

Была изменена Стратегия Запроса, её инфраструктура и применение изменилось в лучшую сторону, теперь все специфичные сервисы и возможности определяются по Стратегии Запроса, а не в методах Application.

По аналогии с Модулями стратегии запроса хранятся в унаследованных классах в соответствующей стратегиям папке Strategies(Опционально), помимо этого не ограничивается способ инициализации и добавления стратегий в приложение. В методах класса так-же как и в Модулях могут определятся сервисы соответствующие только данной Стратегии.

Контейнер зависимостей

Для достижения удобной схемы работы контекстного перекрытия сервисов был переработан компонент Di который нацелен на удобное переопределение сервисов. Цепочки приоритетов наложения которые представлены в виде класса Di\HolderChains , с помощью его объекта можно подменять и изменять динамически поведение переопределения сервисов по цепочке.

С помощью рефакторинга Di, мы реализовали в Модулях тот же механизм переопределения сервисов, все это совместно воплощает картину целевого контекста вызова сервисов
поэтому в целевых MCA действиях будут актуальные для текущего "контекста" сервисы.

Слово "контекст" в данном случае рассматривается только как описывающий термин явления совокупности переопределения сервисов по цепочке в нужной точке приложения (там где вызываются сервисы).

В будущем ожидается реализация достаточной функциональности MCA и реакции Отрисовки на состояние Процесса контроля MCA, по этому добавятся Этапы отрисовки действия, Этапы функциональности действия (PRE-STAGE, TARGET-STAGE) и связанные с ними контрольные точки в MCA системе приложения.

Также помимо этого будут производится работы по внедрению в систему "Уровня-Слоя подготовки параметров в действие контроллера" опираясь на стратегию запроса и схему Маршрутизации.
Слой будет внедрен между изъятием параметров из Маршрутизации и самим вызовом действия контроллера, разработка будет с уклоном на максимальную работу в контексте по уровням переопределения от Приложения до MCA Действия включительно.

v0.0.1-beta

Подготовлен к тестированию.
Возможность реализовать что то похожее на приложение ;)