Sender
Новичок
ewgraFramework
Буду рад ответить на любые вопросы по поводу текста ниже. Хочу проверить на прочность и жизнеспособность свой framework. Так сказать развести дискуссию и попробовать отстоять свое решение перед судом общественности. Хотелось бы в целом услышать мнение, а также увидеть вопросы из разряда: "А можно ли..."
Основа
Данный framework я разрабатывал руководствуясь следующими желаниями:
1. MCV в том понимании, в котором представлял я его себе представлял. То есть мой продукт должен представлять собой три части: Model, Controller, View. При этом в идеале мы можем менять каждую часть и остальные две части не потребуют изменений.
2. Практически все сущности движка должны храниться в базе данных. То есть при изменении каких-то параметров, добавлении новых страниц и т.п. не будет необходимости менять программный код.
3. Организация страниц. Страница должна представлять из себя набор опубликованных на странице модулей. Странице назначается необходимый View, файлы, языкозависимые данные и т.п.
Исходя из этих трех желаний у меня получился следующий framework. Дальше перечислены основные столбы, на которых держится framework.
Событийно-ориентированный
То есть любое движение в системе происходит по событиям, которыми управляет EventDispatcher (диспетчер событий).
На событие может подписаться любой объект. Причем он может подписаться в трех «ипостасях». Первая – это подписывающийся объект выступает в качестве «Источника данных» (Provider). Вторая – «Приемник данных» (Receiver). Третья – «Простейший подписчик» (Easy).
Соответственно EventDispatcher при команде события Fire обойдет всех Providers и будет передавать результаты Receivers. Easy подписчики же просто выполняются EventDispatcher’ом без передачи результата куда-либо.
Если во время подписки объекта событие на данный момент не объявлено, то EventDispatcher будет подписывать на это событие как кандидата. Как только какой-то объект зарегистрирует событие, то EventDispatcher автоматически переведет всех кандидатов в разряд подписавшихся.
Единое хранилище данных
В системе присутствует DataCollector, который тесно связан с View. Он подписан на событие OnData как приемник данных. Нетрудно догадаться что он же подписан как источник данных на событие OnView. Все модули системы и особо важные классы (например Page) подписаны на OnData как источники данных. Таким образом все модули не зависят от конкретного View. А просто скидывают данные в коллектор. Который потом сам транспортирует их во View.
Различные View без смены кода модулей
На данный момент реализованы следующие связки View-DataCollector:
XMLDataCollector – XSLTView
ArrayDataCollector – JSONView, AjaxView, ExcelView, Native (в тесте)
RedirectDataCollector – RedirectView
Организация «Страниц, файлов и модулей»
Страница представляет из себя структуру к которой прикреплены различные файлы отображения (css, js, файлы отображения для модулей и т.п.). Каждый View сам знает как надо использовать эти данные и куда их необходимо вставить чтобы получить трбуемый результат. Также к странице крепятся языкозависимые фразы. На странице публикуются модули в различный секциях Layout’а. Каждый Layout сам знает где ему достать данные для секции. Например применительно к XSLT это будет следующим образом выглядеть:
<!-- [SECTION 2] Контент -->
<xsl:for-each select="/DOCUMENT/*[@section=2]">
<xsl:sort select="@position"/>
<xsl:apply-templates select="."/>
</xsl:for-each>
(применительно к NativeView и им подобным все немного сложнее, но страницу сформировать получилось).
Такой организацией достигается: «мы собираем страницу из блоков/модулей», не меняя по сути view-файлы
Буду рад ответить на любые вопросы по поводу текста ниже. Хочу проверить на прочность и жизнеспособность свой framework. Так сказать развести дискуссию и попробовать отстоять свое решение перед судом общественности. Хотелось бы в целом услышать мнение, а также увидеть вопросы из разряда: "А можно ли..."
Основа
Данный framework я разрабатывал руководствуясь следующими желаниями:
1. MCV в том понимании, в котором представлял я его себе представлял. То есть мой продукт должен представлять собой три части: Model, Controller, View. При этом в идеале мы можем менять каждую часть и остальные две части не потребуют изменений.
2. Практически все сущности движка должны храниться в базе данных. То есть при изменении каких-то параметров, добавлении новых страниц и т.п. не будет необходимости менять программный код.
3. Организация страниц. Страница должна представлять из себя набор опубликованных на странице модулей. Странице назначается необходимый View, файлы, языкозависимые данные и т.п.
Исходя из этих трех желаний у меня получился следующий framework. Дальше перечислены основные столбы, на которых держится framework.
Событийно-ориентированный
То есть любое движение в системе происходит по событиям, которыми управляет EventDispatcher (диспетчер событий).
На событие может подписаться любой объект. Причем он может подписаться в трех «ипостасях». Первая – это подписывающийся объект выступает в качестве «Источника данных» (Provider). Вторая – «Приемник данных» (Receiver). Третья – «Простейший подписчик» (Easy).
Соответственно EventDispatcher при команде события Fire обойдет всех Providers и будет передавать результаты Receivers. Easy подписчики же просто выполняются EventDispatcher’ом без передачи результата куда-либо.
Если во время подписки объекта событие на данный момент не объявлено, то EventDispatcher будет подписывать на это событие как кандидата. Как только какой-то объект зарегистрирует событие, то EventDispatcher автоматически переведет всех кандидатов в разряд подписавшихся.
Единое хранилище данных
В системе присутствует DataCollector, который тесно связан с View. Он подписан на событие OnData как приемник данных. Нетрудно догадаться что он же подписан как источник данных на событие OnView. Все модули системы и особо важные классы (например Page) подписаны на OnData как источники данных. Таким образом все модули не зависят от конкретного View. А просто скидывают данные в коллектор. Который потом сам транспортирует их во View.
Различные View без смены кода модулей
На данный момент реализованы следующие связки View-DataCollector:
XMLDataCollector – XSLTView
ArrayDataCollector – JSONView, AjaxView, ExcelView, Native (в тесте)
RedirectDataCollector – RedirectView
Организация «Страниц, файлов и модулей»
Страница представляет из себя структуру к которой прикреплены различные файлы отображения (css, js, файлы отображения для модулей и т.п.). Каждый View сам знает как надо использовать эти данные и куда их необходимо вставить чтобы получить трбуемый результат. Также к странице крепятся языкозависимые фразы. На странице публикуются модули в различный секциях Layout’а. Каждый Layout сам знает где ему достать данные для секции. Например применительно к XSLT это будет следующим образом выглядеть:
<!-- [SECTION 2] Контент -->
<xsl:for-each select="/DOCUMENT/*[@section=2]">
<xsl:sort select="@position"/>
<xsl:apply-templates select="."/>
</xsl:for-each>
(применительно к NativeView и им подобным все немного сложнее, но страницу сформировать получилось).
Такой организацией достигается: «мы собираем страницу из блоков/модулей», не меняя по сути view-файлы
