HMVC Введение


Что такое шаблон HMVC?

Чтение документации Kohana, я узнал, что основное отличие версии 3.0 заключается в том, что она следует за шаблоном HMVC вместо MVC, как версия 2.x. Страница об этом в документах Коханы и о том, что в Википедии действительно не дает мне четкой идеи.

Итак, вопрос: что такое шаблон HMVC и как он отличается от MVC?

Сэм де Фрейсинет (один из разработчиков Kohana) написал довольно подробную статью о HMVC что это такое и как это сделать могут быть использованы.

В настоящее время я занимаюсь разработкой собственной инфраструктуры PHP 5.3 HMVC под названием Alloy. Поскольку я сильно инвестировал и продавал на HMVC, я думал, что могу предложить другую точку зрения и, возможно, лучшее объяснение того, почему HMVC следует использовать и какие выгоды он приносит.

Самым большим практическим преимуществом использования архитектуры HMVC является «виджетизация» структур контента. Примером могут быть комментарии, рейтинги, показания RSS-ленты Twitter или блога или отображение содержимого корзины покупок для веб-сайта электронной торговли. Это, по сути, часть контента, которая должна отображаться на нескольких страницах и, возможно, даже в разных местах, в зависимости от контекста основного HTTP-запроса.

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

HMVC, или, в частности, возможность отправки суб-запросов Контроллеру для выполнения этих обязанностей является очевидным решением. Если вы думаете о том, что делаете, оно точно соответствует структуре контроллера. Вам нужно загрузить некоторые данные о комментариях и отобразить их в формате HTML. Таким образом, вы отправляете запрос в контроллер комментариев с некоторыми параметрами, он взаимодействует с Model, выбирает View, а View отображает содержимое. Единственное различие заключается в том, что вы хотите, чтобы комментарии отображались в строке ниже статьи блога, которую пользователь просматривает, а не полностью отдельной полной страницы комментариев (хотя с помощью подхода HMVC вы можете фактически обслуживать как внутренние, так и внешние запросы с одним и тем же контроллером и «убивать» две птицы с одним камнем «, как говорится). В связи с этим, HMVC — это действительно естественный побочный продукт для повышения модульности, повторного использования кода и обеспечения лучшего разделения проблем. Это пункт продажи HMVC.

Итак, в то время как Статья Сэма де Фрейсинеля TechPortal о масштабировании с помощью HMVC интересно обдумать, это не где 90% + людей, которые использование систем HMVC будет получать реальные, практичные, изо дня в день выгоды от него.

HMVC: Введение

Что такое JMX? Если вы думаете, что это еще один побочный фреймворк, не заслуживающий вашего внимания, то вы глубоко заблуждаетесь. Java Management eXtensions (JMX) – это фактически одна из самых основных функциональных частей современного процесса разработки и управления приложениями. Эту технологию сегодня используют такие производители J2EE-серверов, как JBoss, WebLogic и многие другие. Ниже мы рассмотрим структуру JMX и примеры использования этой технологии вместе с JSP. После прочтения этого материала вы без проблем сможете встраивать функциональность JMX в свои собственные приложения.

Технология JMX (Java Management eXtensions) – это сравнительно новый стандарт компании Sun Microsystems, который позволяет Java-разработчикам интегрировать свои приложения с существующими решениями сетевого управления. JMX определяет стандарт для написания JMX-объектов, так называемых MBean’ов. MBean’ы «живут» внутри своего контейнера. Таким образом, любой JMX-клиент (в качестве которого может выступать, например, удаленное или локальное приложение) имеет возможность вызывать методы и получать доступ к атрибутам этим MBean’ов с помощью контейнера, в котором они содержатся. Кроме того, приложение также может получать специальные уведомления от MBean’ов, если это приложение зарегистрирует соответствующие “слушающие” MBean’ы.

Управление конфигурацией любого сервера приложений может оказаться бренной задачей, и большинство проектов просто не включают в цикл разработки конфигурационный фреймворк. В этом случае JMX приходит на помощь: теперь в вашем распоряжении есть фреймворк многократного использования для внедрения в ваши приложения функций удаленных и локальных инструментов управления. JMX позволяет запрашивать конфигурационные установки и изменять их во время выполнения приложения. Кроме этого JMX предоставляет и другие сервисы, такие как, например, мониторинг, уведомления о событиях, таймер и динамическая загрузка классов из XML-файлов. Вы можете использовать JMX для загрузки, инициализации, изменения и мониторинга ваших приложений и их распределенных компонентов.
Подробная спецификация технологии JMX находится в документе JSR-000003 (www.jcp.org).

Предлагаемую вашему вниманию статью условно можно разделить на две части: в первой мы рассмотрим архитектуру технологии JMX, а затем обратимся к примерам использования JMX вместе с технологией JSP с помощью сервера приложений JBoss и сервлет-контейнера Tomcat.

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

Этот слой трактует приложение как один или несколько управляемых компонентов MBean’ов (Managed Bean). Каждый MBean предоставляет возможность управлять своим состоянием с помощью общедоступных public-методов. MBean’ом может быть любой Java-объект, который вы модифицируете так, чтобы он поддерживал интерфейсы и семантику, определенную в спецификации JMX. MBean’ы бывают четырех типов: standard, dynamic, open и model:
1. Standard MBean обеспечивает статический (static) интерфейс.
2. Dynamic MBean передает свой интерфейс JMX-агенту во время выполнения приложения с использованием метаданных.
3. Open MBean – это тот же dynamic MBean, но который использует предопределенные типы данных Java таким образом, что зависимости от других классов ослабляются, позволяя улучшить производительность и динамическое поведение этого компонента.
4. Model MBean – как следует из названия – это общий и настраиваемый MBean, который поставляется с каждой реализацией JMX. Вы можете создать экземпляр и использовать model MBean’ы вместо определения своих собственных MBean-классов.

Standard MBean – это наиболее распространенный тип. Например, предположим, что у вас есть класс с именем Logger, который формирует отладочные сообщения вашего приложения, при этом содержит в себе поля для имени журнального файла (в который будут заноситься эти сообщения) и уровня подробности сообщений. Мы может завернуть этот класс Logger в MBean типа standard, создав новый интерфейс с именем LoggerMBean. В этом интерфейсе мы добавляем общедоступные (public) getter- и setter-методы для установки и изменения значений имени файла и уровня подробности сообщений. Эти методы для изменения атрибута имени файла могут называться, например, setFilename() и getFilename(). И, наконец, классу Logger нужно реализовать интерфейс LoggerMBean так, чтобы агент JMX смог самостоятельно все проанализировать и сгенерировать метаданные о MBean’е класса Logger. Этот MBean управляется с помощью агента JMX вызовами методов, определенных в интерфейсе (в нашем случае интерфейсе LoggerMBean). В общем случае MBean – это связь между управляемым ресурсом (вашим приложением) и остальным фреймворком JMX.

Следующий наиболее интересный слой фреймворка JMX – это слой agent. Агент (agent) предоставляет удаленный доступ к управлению приложением всем своим зарегистрированным MBean’ам. Можно смело сказать, что это центральная часть фреймуорка JMX. Агент также обеспечивает дополнительные сервисы, типа мониторинга и динамической загрузки классов. Эти сервисы также являются зарегистрированными MBean’ами. Основной компонент агента называется MBean-сервером и определяется интерфейсом javax.management.MBeanServer. Для того чтобы создать сервер, вы должны вызвать статический метод createMBeanServer() класса MBeanServerFactory. Этот класс-фабрика хранит также ссылки на все MBean-серверы, которые были созданы раньше. Поэтому от вас не требуется кэшировать их. Найти ссылку на нужный MBean-сервер вы можете с помощью метода findMBeanServer().

cлой распределенных сервисов (distributed services)

Последний из рассматриваемых нами слоев – это слой распределенных сервисов управления. Этот слой обеспечивает интерфейс, который удаленные инструменты используют для взаимодействия с агентами.

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

В нашем примере мы будем использовать Tomcat и JBoss в качестве серверов приложений, поэтому вам необходимо сначала установить их. Просто следуйте следующим шагам:
1. Скачайте Tomcat и JBoss в одном дистрибутиве с веб-сайта SourceForge.net (сайт
2. Скопируйте файл tools.jar из директории lib вашей JDK в директорию lib сервера Tomcat. Это необходимо для компиляции JSP-страниц при работе сервера Tomcat интегрированного с JBoss. Альтернативный вариант – добавить библиотеку tools.jar в переменную окружения CLASSPATH.
3. Скопируйте файл jmxri.jar из директории lib установленного сервера JBoss в директорию lib сервера Tomcat. Это JAR-файл содержит JMX-классы, которые мы будем использовать для написания нашей JSP-страницы.
4. Протестируйте работу сервера, выполнив из командной сроки команду run.bat для Windows-систем или run.sh для Linux, находясь в директории bin сервера JBoss. Там вы должны будете увидеть консольное сообщение о запуске еще и встроенного сервера Tomcat, как части процесса запуска. Чтобы завершить запуск нажмите Ctrl-C.

Технология JMX может использоваться вместе с JSP, чтобы предоставить простой способ управления приложениями. Приведенный ниже пример, выполненный в виде кода JSP, работает с JMX-агентом (или MBean-сервером), который находится внутри сервера JBoss. Возьмите листинг этой программы и сохраните его под именем, например, JMXExample1.jsp и скопируйте его в директорию webapps/JMXExamples (предварительно ее создав) относительно корневой директории вашего сервера Tomcat (убедитесь, что вы запустили JBoss). И введите в вашем браузере следующий адрес:сайт

Листинг 1.

0) <
Attribute attr = new Attribute("LogName", newValue);
srv.setAttribute(objName, attr);
>


// Получаем последнее значение атрибута имени журнального файал
String value = (String)srv.getAttribute(objName, "LogName");
%>


Как результат работы этой JSP-страницы, в вашем браузере должно появиться что-то похожее на следующее изображение:

Рисунок 1. Результат выполнения кода JSP.

На рисунке 1 показан атрибут LogName класса org.jboss.logging.FileLoggingMBean. Этот атрибут представляет имя журнального файла сервера JBoss. Сейчас попробуйте изменить значение текстового поля на, например, “newlogfile” и нажмите на кнопку “Обновить”. Теперь зайдите в директорию dist/log относительно корневой директории установленного сервера JBoss. Там вы увидите новый журнальный файл с именем newlogfile.

Нажатие на кнопку “Обновить” вызывает метод setAttribute() MBean-сервера, который поручает этот вызов методу setLogName() интерфейса FireLoggingMBean. Следует учесть, что MBean-сервер, JBoss и JSP-страница работают внутри одной и той же виртуальной Java-машины (JVM). Используя этот же подход, вы без труда можете интегрировать JMX с вашими собственными приложениями. Все что вам нужно – это создать MBean- сервер, зарегистрировать в нем ваши MBean’ы и после этого написать свою JSP-страницу или любое другое приложение, которым вы хотите осуществлять управление. Это самый простой способ добавления функциональности технологии JMX в ваш, уже существующий проект.

Альтернативный подход состоит в использовании класса HtmlAdapterServer из стандартной реализации JMX, вместо разработки вашей собственной JSP- страницы. Этот класс находится в файле jmxtools.jar. HtmlAdapterServer – это тоже MBean-компонент. Пример того, как выглядит страница управления с помощью этого класса вы можете посмотреть, запустив сервер JBoss и введя в адресной строке вашего браузере адрессайт
как это все работает?

Итак, сейчас мы более подробно рассмотрим все операции, которые мы выполняли.
1. На первом этапе мы получаем ссылку на MBean-сервер с помощью вызова статического метода findMBeanServer(null) класса-фабрики
MBeanServerFactory. Передача значения null в качестве параметра этому методу означает, что вы хотите получить все серверы известные данному классу-фабрике. В нашем случае нам нужен только один единственный от JBoss. Когда вы используете интерфейс MBean-сервера, вам нужно определить какому MBean’у вы собираете посылать сообщения (т.е. чьи методы вы будете вызывать).
2. Далее мы создаем объект класса ObjectName. В качестве параметра его конструктору мы передаем каноническое имя нашего MBean’а. Шаблон имени состоит из домена (domain), который может быть либо DefaultDomain, либо какой-то свой домен. За доменом следуют пары , разделенные запятыми. Здесь нужно указать как минимум одну такую пару. Формат шаблона в общем виде выглядит следующим образом:

Цукерберг рекомендует:  Объектно-ориентированный PHP автоматическая загрузка классов, сериализация и получение информации

3. На третьем этапе мы обновляем FileLoggingMBean новым значением имени журнального файла, которое было передано JSP-странице. Для этого мы создаем объект класса Attribute фреймворка JMX и передаем его конструктору в качестве параметров имя атрибута и его значение. После этого мы вызываем метод setAttribute() MBean-сервера, передавая ему созданные нами ранее объекты классов Attribute и ObjectName, как параметры. Эти параметры помогают понять, с каким MBean’ом мы будем иметь дело, а также задают атрибут и его значение. Метод setAttribute() будет использовать метаданные MBean’а, хранящиеся на MBean-сервере, чтобы вызвать подходящий setter-метод этого MBean’а.
4. И, наконец, мы получаем с помощью метода getAttribute() значение атрибута из FileLoggerMBean. Этому методу мы передаем параметры: объект класса ObjectName и имя атрибута в виде строки String. Вам также нужно привести тип возвращаемого объекта к тому, что возвращает getter-метод. Этот тип определен, естественно, в интерфейсе FileLoggerMBean.

дополнительные возможности JMX

JMX позволяет выполнять гораздо больше функций, чем простой фреймворк удаленного управления. Он предоставляет дополнительные сервисы, которые вы можете сделать основной частью вашего процесса разработки. Ниже приведем небольшой список этих возможностей:
— Уведомления о событиях. Интерфейсы снабжены возможностью распространения уведомлений среди “слушателей” (listeners) событий. Событием может являться, например, изменение атрибута. Это позволяет MBean’ам взаимодействовать с другими MBean’ами или удаленным менеджером и оповещать друг друга об изменениях состояния.
— Мониторинг. Monitor MBeans могут посылать уведомления о событиях зарегистрированным у них “слушателям”. “Слушателем” может быть другой MBean или приложение. Целевыми объектами наблюдений за атрибутами могут быть: counter, gauge и string. Подробнее о них вы можете прочитать в спецификации.
— Таймер. Timer MBean будет посылать уведомления зарегистрированным “слушателям” по наступлению определенного времени или истечению заданного интервала.

JMX – это значимый и крайне полезный фреймуорк, который вы уже сейчас можете с минимальными усилиями интегрировать с вашими приложениями. Кроме этого JMX может легко интегрироваться с уже существующими технологиями управления, например, SNMP, а также технологиями будущего, например, CIM/WBEM.

HMVC в Kohana 3

У данной публикации есть спонсор (как им стать):

В связи с запуском новой площадки хостинг-компания Inferno Solutions предлагает 50% скидку на весь срок аренды любого Linux VPS в Эстонии тем клиентам, которые сделают заказ до 1 июля! Используйте код скидки EST50. Отзывы о компании.

Приветствую вас, уважаемый читатель, в свежей статье, посвященной программированию динамических сайтов на фреймворке Kohana 3.1.

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

Сегодня речь пойдет о технологии HMVC, поддерживаемой Kohana.

Технология HMVC (иерархический MVC) позволяет обратиться из вида или контроллера одной страницы сайта, к контроллеру другой страницы. В результате мы получаем возможность отображать стандартные блоки (блоки новостей, рекламные блоки), формируемые одним контроллером, на любой странице сайта, формируемой совершенно другим контроллером.

Плюсы HMVC-подхода:

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

Постановка задачи: блок новостей, формируемый контроллером news (kohana\www\application\classes\controller\news.php), необходимо встроить в главную страницу сайта (ну и во все те страницы, где нужен блок новостей, см. рис. 1).

Рис 1. Реализация поставленной задачи посредством HMVC.

Листинг 1. Контроллер News (kohana\www\application\classes\controller\news.php)


Пояснения к листингу 1

7-я строка. Создается экземпляр модели News, функционал которой мы опишем чуть позже.

8-я строка. В поле contentNews массива data методом get3news() записывается 3-и новости из таблицы news базы данных (функционал метода get3news() будет описан чуть позже).

10-я строка. Несколько иным способом формируется отображение, поскольку мы наследуем контроллер News от Controller (3-я строка листинга 1), а не от Controller_Template (как обычно я это делал в видеуроках). От Controller_Template нет смысла наследовать, т. к., в данном случае, мы не применяем сборку внешнего вида из базового шаблона и внутреннего шаблона, мы просто формируем внешний вид посредством единственного файла kohana\www\application\views\newsview.php.

Листинг 2. Модель News kohana2\www\application\classes\model\news.php

Пояснение к листингу 2:

Метод get3news() возвращает в виде ассоциативного массива три новости из таблицы news (структура таблицы news представлена на рис. 2).

Рис 2. Структура таблицы news.

Листинг 3. Файл вида kohana\www\application\views\newsview.php

Пояснение к листингу 3

В файле вида происходит вывод в цикле содержимого поля short-content таблицы news. Иными словами, произойдет вывод короткого описания трех новостей, которые мы достали из базы данных методом get3news() (см. листинг 2).

Последнее, что осталось сделать — это осуществить вывод получившегося блока с тремя новостями (листинг 3) в любой другой файл вида.

Предположим, я хочу вывести новости над формой авторизации (kohana/auth). Для этого в начало файла вида авторизационной страницы (kohana\www\application\views\authview.php) необходимо добавить код вызова контроллера News, представленный в листинге 4:

Листинг 4. Код вызова контроллера News

Результат представлен на рис. 3.

Рис. 3. Результат вызова контроллера News в виде авторизационной страницы.

Есть одна небольшая проблема — посетитель сайта запросто может набрать адрес kohana/news и увидеть голый блок новостей.

Эту проблему можно побороть в два счета:

  • Имеется возможность проверить первичный ли запрос поступил к контроллеру (под первичным мы понимаем запрос от пользователя, перешедшего по адресу kohana/news) или котроллер News запрашивается другим контроллером.
  • Если запрос первичен, то мы отобразим страницу 404 (как реализовать страницу 404 в Kohana 3).

Для этого в начало контроллера News добавим метод before, который осуществит проверку на первичность запроса перед обработкой экшена index (см. листинг 5).

Листинг 5. Метод before для проверки первичности запроса к контроллеру

MVC: что это такое и какое отношение имеет к пользовательскому интерфейсу


В последнее время я много общался об MVC (Model-View-Controller, «модель-представление-контроллер») с некоторым количеством программистов, занимающих позиции разного уровня в софтверных компаниях. Встретил много непонимания и теперь хочу поделиться соображениями по этому вопросу. MVC — штука очень абстрактная, и это основная причина недоразумения — недооценённая степень абстрактности. Она проявляется в следующем: программист, как правило, работает в рамках одной парадигмы (ООП наше всё) и смотрит на мир сквозь неё. И когда слышит, например, «контроллер» — представляет класс. А это частность — класс, или не класс, или совокупность объектов или процедур, это значения не имеет. Ещё бывает понимание искажено конкретным MVC-фреймворком. Попробую на это повлиять.

Что такое MVC?

Итак, MVC — это про пользовательский интерфейс (UI). Не обязательно графический, голосовое управление тоже годится. Не забудем, что программа может не иметь пользовательского интерфейса, может иметь программный интерфейс (API) или вообще никакого не иметь и всё ещё быть полезной.

Но если у нас есть пользователь, значит должен быть пользовательский интерфейс. Что же такое интерфейс? Это смежная граница между двумя системами. В нашем случае: с одной стороны — программа, с другой — пользователь. Вот они.

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

Юзкейсы

В качестве примера представьте терминал для торговли на бирже. Пользователь терминала выставляет заявку, в которой указывает, что он хочет купить акции компании «Светлый путь» в количестве 20 штук по цене 1500 рублей за акцию. Также указывает, что заявка действительна в течение четырёх часов, и с какого из его счетов списать деньги, в случае успешной сделки.

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

14–16 ноября, Санкт-Петербург, 7500–17 000 ₽

Но на бирже нельзя изменить заявку, в предметной области нет такого понятия. Заявку можно только выставить и отменить. Чтобы дать пользователю возможность в один клик менять заявку, надо запоминать старые значения, снимать заявку, давать редактировать то, что запомнили, и выставлять новую заявку. Такая комбинация. Но для пользователя она выглядит как одно простое действие: изменение заявки. Это называется — use case.

Дополним нашу диаграмму местом под юзкейсы.

Ещё пользователю надо дать возможность дёргать эти юзкейсы и получать результат. Это могут быть кнопки и другие графические элементы ввода-вывода, жесты, распознавание и синтез речи. Любой вариант обмена данными и командами. Вуаля:

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

Так где же тут все-таки MVC?

Все, что осталось — это только раздать знакомые имена образовавшимся компонентам.

Когда модель публикует изменения, её не волнует для кого, она ничего не знает про View. Вместо или вместе со View на том конце может быть другая подсистема.

Теперь немного частностей.

Это был классический вариант MVC — Active Model. Бывает и так, что модель не оповещает об изменениях. Тогда эту обязанность берёт на себя контроллер. Он знает, какие манипуляции производит над моделью, и, очевидно, знает, какие изменения в состоянии модели могут последовать. Это Passive Model.

И ещё один момент. Деление кода на предметный и не предметный — условное и зависит от того, насколько педантично мы хотим смоделировать предметную область. Иногда это рациональное решение — включить какой-то юзкейс в модель. Возможно, это уменьшит количество кода в целом и упростит его.

За материал благодарим нашего подписчика Станислава Ильичева

Создание движка на CodeIgniter 3 + HMVC. Часть 2 — пишем модули settings и common.

Создание движка на CodeIgniter 3 + HMVC. Пишем модули settings и common.

В прошлой статье мы с вами установили новую версию старого и надежнейшего фреймворка codeigniter, расширили наш codeigniter модульным расширением и настроили фундамент нашего будущего приложения. Теперь давайте создадим первые два модуля: один системный для хранения общей библиотеки с функциями доступными любому модулю. Второй модуль — settings — позволяющий выбрать и передать библиотекам все данные нашего сайта. В этом уроке подготовимся к созданию модуля page, который отвечает за генерацию,проверку и отображение страниц сайта. Так же в этой статье мы сделаем очень многое для нашего нового движка. Поехали.

Модуль settings. База данных настроек и контроллер выборки значений настроек


  • Создаем папку settings в папке modules
  • Создаем в папке common каталог — controllers
  • В папке с контроллером(controllers) создадим новый файл файл settings.php
  • Открываем phpMyAdmin и созданную ранее базу CI3
  • Добавляем таблицу settings со следующей структурой
  • Далее наполняем таблицу данными(настройками и описанием сайта)

Давайте немного разберемся что мы сделали с таблицей. Структура следующая: в одной строке — одна настройка для сайта, следовательно можно расширять настройки всего сайта а не использовать отдельные ячейки для отдельных настроек. У нас будет name — название настройки на латинице, value — значение ячейки и description — описание настройки(данная ячейка не обязательна)

В дампе таблицы выше я уже добавил заготовленные за ранее настройки для будущего проекта. И так что мы имеем:

  • Sitename — название сайта. Можно выводить как название сайта в шаблоне, или указывать данное значение в роли отправителя письма с сайта.
  • email — указываем email на сайте, что бы вывести в контактах например.
  • email_sender — указываем ящик отправителя писем с сайта(понадобится при настройке отправки писем с сервера, нужно будет указывать реальный ящик созданный на хостинге и прикрепленный к домену)
  • tel1 — телефон для контактной информации
  • tel2 — еще один телефон для контактной информации
  • adress -адрес для контактной информации
  • yandex_metrika — код счетчика яндекс метрики или любой другой
  • google_analytics — код аналитики гугл
  • email_order — в этом поле указываем почтовые ящики получателей системных писем сайта и заявок
  • Captcha — устанавливаем использовать ли на сайте капчу или нет
  • title_suffix — задаем суффикс ко всем заголовкам страниц сайта
  • send_mail — отправляем заявки с сайта на указанные почтовые ящики или нет
Цукерберг рекомендует:  Создание сайтов и их продвижение - Ищу разработчика сайта под ключ

Как видим ни чего сложного — минимум настроек необходимый для любого приложения. Теперь стоит написать функцию выборки всех данных настроек для удобной передачи и работы с ними на всем сайте. Открываем файл /modules/settings/controllers/Settings.php

В конструкторе мы подключаем еще не созданную библиотеку main_lib чуть ниже рассмотрим код и создадим и ее. Две функции — одна для выборки всех настроек, вторая для выборки настройки сайта по ее названию. function get_settings() выбирает все строки из таблицы settings. Создаем пустой массив $data. По выбранным данным из базы мы проходим циклом foreach и записываем в новый массив все данные по типу имя => значение. Зачем нам так делать? Во первых что бы можно было обращаться к настройкам с любого модуля проверяя наличие элемента в массиве по имени самой настройки и выводя лишь его значение. Возвращаем собранный массив. Теперь можно обратиться и вызвать любую настройку сайта просто — echo $data[‘sitename’]. C функцией выборки единственного параметра вы разберетесь сами, ничего сложного.

Модуль common и библиотека main_lib

  • Создаем папку common в папке modules
  • Создаем в папке common каталог — libraries
  • В папке с библиотеками(libraries) файл main_lib.php

Открываем файл main_lib.php и создаем класс с именем Main_lib. В конструкторе включим встроенный бенчмарк codeigniter

Теперь создадим несколько жизненно важных для будущего проекта методов(функций), которые помогут нам работать со всеми модулями движка. Поехали: функция render_main_page($data)

Необычный код для человека, впервые столкнувшимся с иерархической структурой модели-вид-контроллер. Функция уже принимает и обрабатывает данные при вызове. $data — это массив с содержанием всех данных для последнего шага — рендера и отображения главного шаблона со всеми данными. Так что принимаем наш массив и добавляем в него элементы — переданные, недавно созданной функции — выбрать все настройки. Выборку всех настроек мы повесим на наше расширение HMVC. Подробнее о работе функций echo modules::run(‘module/controller/method’, $var_1, . $var_n) или $this->load->module(‘module’) вы можете почитать на странице разработчика по ссылке указанной в первой статье либо на этом сайте на русском языке Вызвав метод класса settings модуля setttings — мы вернули массив со всеми значениями настроек и объединили его с массивом, который передал нам модуль вызвавший функцию render_main_page — в нашем уроке это будет модуль Page.


Далее с помощью встроенного парсера codeigniter выведем наш шаблон из папки /themes/site/index.tpl передав весь массив с данными.

Для данного урока и всех последующих статей данного цикла мы создадим простенький шаблон на основе бутстрапа. Возьмем уже имеющуюся заготовку блога на сайте http://bootstrap-3.ru/examples/blog/

Описывать код верстки мы не будем. А обратим внимание на то, как изящно мы выводим наши данные. В тело шаблона выводим переменную $content — простым заключением в фигурные скобки. Для примера так же выведем несколько настроек — информацию о сайте в футер, так же заключив название переменных в фигурные скобки. Codeigniter парсит название переменных и выводит содержание. — аналогично можно вызвать echo $content. Позже мы будем записывать в эту переменную всю верстку сгенерированную нашими модулями.

Вызов библиотеки и функции render_main_page из модуля welcome.

Итак мы перешли к главному — тестированию наших новых функций. Давайте сперва зададим несколько настроек в конфигурации нашего codeigniter для дальнейшей полноценной работы движка.

Открываем файл /application/config/autoload.php из названия вы наверное догадались что речь пойдет о библиотеках и помощниках, которые загружается в нашем приложении автоматически при работе любого контроллера. Добавляем библиотек session parser и database в строке 61 заменим значение
$autoload[‘libraries’] = array();
на наше:
$autoload[‘libraries’] = array(‘session’, ‘parser’, ‘database’);

Они понадобятся нам для работы с базой данных, и вывода шаблона.

Настало время подключить уже все библиотеки и запустить рендер страницы, передав некоторые данные нашей функции. Правим файл /modules/welcome/controllers/welcome.php

Как вы видите — мы подключаем в конструкторе класса библиотеку main_lib из модуля common, передавая в с именем content данные для вывода. Запускаем.

Введение в функцию визуализации Vue (с примерами)

В этой статье, я хочу рассказать о функции рендеринга Vue, чтобы вы могли лучше понять как работает Vue.js в целом.

Что такое функция рендеринга?

Каждый компонент Vue реализует функцию рендеринга. В большинстве случаев функция создается компилятором Vue. Когда вы определяете шаблон (template) для вашего компонента, содержимое этого шаблона обрабатываться компилятором Vue (Vue.compile()), который возвращает функцию рендеринга. Функция рендеринга по существу возвращает виртуальный узел DOM, который будет визуализирован Vue в DOM вашего браузера.

Хорошо, а что такое виртуальный DOM?

Виртуальная объектная модель документа (или «DOM») позволяет Vue визуализировать ваш компонент в его памяти перед обновлением браузера. В виртуальном DOM это делается быстрее, потому что, в нем нет прямого взаимодействия с DOM браузером. Когда Vue обновляет DOM вашего браузера, он сравнивает обновленный виртуальный DOM с его предыдущим состоянием и обновляет в реальном DOM только те части, которые были изменены.

Функция рендеринга возвращает виртуальный узел DOM, обычно называемый VNode в экосистеме Vue, который является интерфейсом, который позволяет Vue записывать эти объекты в DOM вашего браузера. Они содержат всю информацию, необходимую для работы с Vue. Следующая версия Vue будет включать в себя совершенно новую виртуальную реализацию DOM, которая будет еще быстрее, чем сейчас. React, Riot, Inferno и многие другие также используют концепцию Virtual DOM.

Это изображение было найдено и изменено из статьи Майкла Галлахера Low Verbosity i18n

Более подробно о виртуальном DOM можно почитать тут

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

Есть некоторые встроенные компоненты, которые используют все мощь функций рендеринга, таких как transition и keep-alive. Эти компоненты управляют VNodes непосредственно в функции рендеринга.

Вы также можете почитать официальную документацию Vue здесь.

Как компилятор Vue вписываются в функции рендеринга?

В большинстве случаев функция визуализации Vue будет компилироваться компилятором Vue во время сборки вашего проекта (например, с помощью Webpack). Функцией компилятора является Vue.compile(). Однако, если вам необходимо вы можете задействовать функцию компилятора в своем коде. Это может быть очень удобно. Пример того, как вы можете использовать компилятор для компиляции строки шаблона в функцию рендеринга:

Как видите, Vue.compile возвращает объект, который содержит готовую к использованию функцию рендеринга.


Важность привязки событий в функциях рендеринга Vue

Это подводит нас к привязке событий. Функция createElement может принимать параметр, называемый объектом данных. Этот объект может иметь несколько свойств, которые эквивалентны директивам типа v-bind:on которые вы используете в своих стандартных шаблонах. Вот пример простого компонента счетчика с кнопкой, которая увеличивает количество кликов.

Но объект данных не ограничен привязкой событий! Вы также можете применять классы к элементу, как если бы вы делали это с помощью директивы v-bind: class.

Вы найдете больше информации об объекте данных создаваемым createElement в этом разделе документации Vue.

Реальный сценарий использования переопределения шаблонов

Я думаю, что очень интересно понять, как Vue работает под капотом. Как говориться, единственный способ узнать, используете ли вы инструмент наиболее эффективно, – это точно знать, как он работает.

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

В приведенном примере я покажу вам, как использовать пользовательскую функцию рендеринга в компоненте.

Сначала давайте создадим нашу начальную разметку.

Внутри нашего div, где будет монтироваться приложение Vue, мы определим пользовательский шаблон. По сути, мы хотим, чтобы шаблон переопределял heading по умолчанию.

Первое, что мы сделаем, это просканируем пользовательские шаблоны и предварительно скомпилируем их с помощью компилятора Vue:

Затем давайте создадим компонент heading:

Это просто простой компонент, который имеет входящее props с именем title. Шаблон по умолчанию будет отображать тег h1 с title. Этот компонент будет состоять из компонента overridable, который мы создадим.

В нем мы будем использовать пользовательскую функцию рендеринга.

Затем смонтируем наше приложение Vue:

В этом примере мы видим, что используется шаблон по умолчанию, поэтому это стандартный тег h1.

Если мы добавим пользовательский шаблон в div#app, то увидим, что компонент heading теперь будет отображать пользовательский шаблон, который мы указали.

Yii Framework

Организация иерархического представления (HMVC)

Организация иерархического представления (HMVC)

Добрый день, сообщество.

Имеется представление, которое содержит большое количество виджетов (внутри которых GridView, форма для добавления новых записей и для редактирования существующих). Каждый виджет связан со своей сущностью из агрегата.
Для простоты понимания представим следующий агрегат:

На странице информации о клиенте содержатся виджеты непосредственно для отображения и редактирования модели Customer, а также по одному виджету для каждой сущности CustomerEmail, CustomerPhone и т.д.


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

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

Было рассмотрено решение HMVC, но, к сожалению, не совсем понятно, как это использовать в Yii2.
Может быть есть какие-то рекомендации или практики по организации подобных иерархических интерфейсов?
Я хочу добиться такой организации кода, при которой для работы с одной сущностью (например, пагинация таблицы телефонов или добавление нового телефона) не придется инстанцировать десяток совершенно не нужных провайдеров и фильтров.

На ум приходит только организация отдельных контроллеров для каждого виджета, но я не нашел, как это можно реализовать в Yii2.

HMVC: Введение

10 февраля 2011

В последнее время часто всплывает тема иерархического MVC или HMVC. Штука довольно интересная, но по-простому почти нигде не описана, что и исправим.

HMVC отличается от классического MVC лишь тем, что из любого контроллера, представления или компонента можно запустить действие другого контроллера.

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

В большинстве реализаций, таких как HMVC в Kohana 3, CodeIgniter Modular Extensions, Zend Framework Action View Helper и runController в Yii, при этом, отдельного HTTP-запроса не происходит.

Kohana 3 также умеет запускать контроллеры по HTTP, хотя, кроме весьма неплохой интеграции с её роутингом, ничего нового тут нет: использовать CURL или сокеты для дополнительного запроса не сложно.

Комментарии RSS по email OK

Kohana v3.1 умеет делать подзапросы (в том числе и внешние) также через CURL и PECL_HTTP :)

по-простому почти нигде не описана, что и исправим.

Не исправили :) Вроде бы на Хабре недавно был перевод статьи про HMVC в ko3

Sam Dark, большая просьба. Не мог бы написать статью, с примером реализации такой схемы на Yii. Хотелось бы посмотреть как это делается правильно и избавить себя от говнокода. Спасибо.

biakaveron, я упомянул про Kohana 3 и вызов действий контроллера по HTTP. Что-то забыл?

В статье ( http://habrahabr.ru/blogs/kohanaphp/113117/ ) вроде та же самая мысль, что и у меня, но описано подлиннее и с применением именно к Kohana.

Diolektor, при использовании Yii особого смысла в HMVC нет: есть виджеты.

Sam, Diolector А еще есть модули.

Мне в свое время вот эта статья помогла нормально разобраться с HMVC: techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/

Вот, блин, на Хабре перевод этой же статьи оказывается ..

В cakePHP это реализуется методом requestaction, только не в курсе происходит ли при этом HTTP-запрос.

Не понравилось в кохане то что эту вобщем-то старую фичу (уже года 3 как юзаю) распиарили как абсолютно новую вещь. И кстати в кохане нельзя в экшен передать что-то кроме строк. С учетом того что мы не привязаны к строке запроса, то как-бы могли бы сделать передачу всего что можно. (Опять-же 2 года как юзаю передачу массивов — например та-же менюшка, с подсвеченным текущим пунктом)

Цукерберг рекомендует:  Интерпретатор BASIC на Java за 2 часа


Да, сам уже использую HMVC. в некоторых проектах очень сильно облегчает жизнь

По поводу вашего куска кода:

куда его вставлять, а то ругается на константу.

Структура модулей кодеков HMVC

Я работаю над системой управления контентом в Codeigniter с расширением Datamapper и HMVC. Мой вопрос в том, как обращаться с подмодулями.

Пример. Я хочу создать пользовательский модуль, который существует от пользователей, групп пользователей, прав и модулей. В codeigniter я теперь создаю его вот так:

Правильно ли это исправить, или я делаю это неправильно?

Вы не можете иметь подмодули в HMVC без расширения класса MY_router.

Здесь вы найдете хороший учебник: HMVC: введение и приложение

HMVC: Введение

Что такое JMX? Если вы думаете, что это еще один побочный фреймворк, не заслуживающий вашего внимания, то вы глубоко заблуждаетесь. Java Management eXtensions (JMX) – это фактически одна из самых основных функциональных частей современного процесса разработки и управления приложениями. Эту технологию сегодня используют такие производители J2EE-серверов, как JBoss, WebLogic и многие другие. Ниже мы рассмотрим структуру JMX и примеры использования этой технологии вместе с JSP. После прочтения этого материала вы без проблем сможете встраивать функциональность JMX в свои собственные приложения.

Технология JMX (Java Management eXtensions) – это сравнительно новый стандарт компании Sun Microsystems, который позволяет Java-разработчикам интегрировать свои приложения с существующими решениями сетевого управления. JMX определяет стандарт для написания JMX-объектов, так называемых MBean’ов. MBean’ы «живут» внутри своего контейнера. Таким образом, любой JMX-клиент (в качестве которого может выступать, например, удаленное или локальное приложение) имеет возможность вызывать методы и получать доступ к атрибутам этим MBean’ов с помощью контейнера, в котором они содержатся. Кроме того, приложение также может получать специальные уведомления от MBean’ов, если это приложение зарегистрирует соответствующие “слушающие” MBean’ы.

Управление конфигурацией любого сервера приложений может оказаться бренной задачей, и большинство проектов просто не включают в цикл разработки конфигурационный фреймворк. В этом случае JMX приходит на помощь: теперь в вашем распоряжении есть фреймворк многократного использования для внедрения в ваши приложения функций удаленных и локальных инструментов управления. JMX позволяет запрашивать конфигурационные установки и изменять их во время выполнения приложения. Кроме этого JMX предоставляет и другие сервисы, такие как, например, мониторинг, уведомления о событиях, таймер и динамическая загрузка классов из XML-файлов. Вы можете использовать JMX для загрузки, инициализации, изменения и мониторинга ваших приложений и их распределенных компонентов.
Подробная спецификация технологии JMX находится в документе JSR-000003 (www.jcp.org).

Предлагаемую вашему вниманию статью условно можно разделить на две части: в первой мы рассмотрим архитектуру технологии JMX, а затем обратимся к примерам использования JMX вместе с технологией JSP с помощью сервера приложений JBoss и сервлет-контейнера Tomcat.

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

Этот слой трактует приложение как один или несколько управляемых компонентов MBean’ов (Managed Bean). Каждый MBean предоставляет возможность управлять своим состоянием с помощью общедоступных public-методов. MBean’ом может быть любой Java-объект, который вы модифицируете так, чтобы он поддерживал интерфейсы и семантику, определенную в спецификации JMX. MBean’ы бывают четырех типов: standard, dynamic, open и model:
1. Standard MBean обеспечивает статический (static) интерфейс.
2. Dynamic MBean передает свой интерфейс JMX-агенту во время выполнения приложения с использованием метаданных.
3. Open MBean – это тот же dynamic MBean, но который использует предопределенные типы данных Java таким образом, что зависимости от других классов ослабляются, позволяя улучшить производительность и динамическое поведение этого компонента.
4. Model MBean – как следует из названия – это общий и настраиваемый MBean, который поставляется с каждой реализацией JMX. Вы можете создать экземпляр и использовать model MBean’ы вместо определения своих собственных MBean-классов.

Standard MBean – это наиболее распространенный тип. Например, предположим, что у вас есть класс с именем Logger, который формирует отладочные сообщения вашего приложения, при этом содержит в себе поля для имени журнального файла (в который будут заноситься эти сообщения) и уровня подробности сообщений. Мы может завернуть этот класс Logger в MBean типа standard, создав новый интерфейс с именем LoggerMBean. В этом интерфейсе мы добавляем общедоступные (public) getter- и setter-методы для установки и изменения значений имени файла и уровня подробности сообщений. Эти методы для изменения атрибута имени файла могут называться, например, setFilename() и getFilename(). И, наконец, классу Logger нужно реализовать интерфейс LoggerMBean так, чтобы агент JMX смог самостоятельно все проанализировать и сгенерировать метаданные о MBean’е класса Logger. Этот MBean управляется с помощью агента JMX вызовами методов, определенных в интерфейсе (в нашем случае интерфейсе LoggerMBean). В общем случае MBean – это связь между управляемым ресурсом (вашим приложением) и остальным фреймворком JMX.

Следующий наиболее интересный слой фреймворка JMX – это слой agent. Агент (agent) предоставляет удаленный доступ к управлению приложением всем своим зарегистрированным MBean’ам. Можно смело сказать, что это центральная часть фреймуорка JMX. Агент также обеспечивает дополнительные сервисы, типа мониторинга и динамической загрузки классов. Эти сервисы также являются зарегистрированными MBean’ами. Основной компонент агента называется MBean-сервером и определяется интерфейсом javax.management.MBeanServer. Для того чтобы создать сервер, вы должны вызвать статический метод createMBeanServer() класса MBeanServerFactory. Этот класс-фабрика хранит также ссылки на все MBean-серверы, которые были созданы раньше. Поэтому от вас не требуется кэшировать их. Найти ссылку на нужный MBean-сервер вы можете с помощью метода findMBeanServer().

cлой распределенных сервисов (distributed services)

Последний из рассматриваемых нами слоев – это слой распределенных сервисов управления. Этот слой обеспечивает интерфейс, который удаленные инструменты используют для взаимодействия с агентами.

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

В нашем примере мы будем использовать Tomcat и JBoss в качестве серверов приложений, поэтому вам необходимо сначала установить их. Просто следуйте следующим шагам:
1. Скачайте Tomcat и JBoss в одном дистрибутиве с веб-сайта SourceForge.net (сайт
2. Скопируйте файл tools.jar из директории lib вашей JDK в директорию lib сервера Tomcat. Это необходимо для компиляции JSP-страниц при работе сервера Tomcat интегрированного с JBoss. Альтернативный вариант – добавить библиотеку tools.jar в переменную окружения CLASSPATH.
3. Скопируйте файл jmxri.jar из директории lib установленного сервера JBoss в директорию lib сервера Tomcat. Это JAR-файл содержит JMX-классы, которые мы будем использовать для написания нашей JSP-страницы.
4. Протестируйте работу сервера, выполнив из командной сроки команду run.bat для Windows-систем или run.sh для Linux, находясь в директории bin сервера JBoss. Там вы должны будете увидеть консольное сообщение о запуске еще и встроенного сервера Tomcat, как части процесса запуска. Чтобы завершить запуск нажмите Ctrl-C.

Технология JMX может использоваться вместе с JSP, чтобы предоставить простой способ управления приложениями. Приведенный ниже пример, выполненный в виде кода JSP, работает с JMX-агентом (или MBean-сервером), который находится внутри сервера JBoss. Возьмите листинг этой программы и сохраните его под именем, например, JMXExample1.jsp и скопируйте его в директорию webapps/JMXExamples (предварительно ее создав) относительно корневой директории вашего сервера Tomcat (убедитесь, что вы запустили JBoss). И введите в вашем браузере следующий адрес:сайт

Листинг 1.

0) <
Attribute attr = new Attribute("LogName", newValue);
srv.setAttribute(objName, attr);
>

// Получаем последнее значение атрибута имени журнального файал
String value = (String)srv.getAttribute(objName, "LogName");
%>


Как результат работы этой JSP-страницы, в вашем браузере должно появиться что-то похожее на следующее изображение:

Рисунок 1. Результат выполнения кода JSP.

На рисунке 1 показан атрибут LogName класса org.jboss.logging.FileLoggingMBean. Этот атрибут представляет имя журнального файла сервера JBoss. Сейчас попробуйте изменить значение текстового поля на, например, “newlogfile” и нажмите на кнопку “Обновить”. Теперь зайдите в директорию dist/log относительно корневой директории установленного сервера JBoss. Там вы увидите новый журнальный файл с именем newlogfile.

Нажатие на кнопку “Обновить” вызывает метод setAttribute() MBean-сервера, который поручает этот вызов методу setLogName() интерфейса FireLoggingMBean. Следует учесть, что MBean-сервер, JBoss и JSP-страница работают внутри одной и той же виртуальной Java-машины (JVM). Используя этот же подход, вы без труда можете интегрировать JMX с вашими собственными приложениями. Все что вам нужно – это создать MBean- сервер, зарегистрировать в нем ваши MBean’ы и после этого написать свою JSP-страницу или любое другое приложение, которым вы хотите осуществлять управление. Это самый простой способ добавления функциональности технологии JMX в ваш, уже существующий проект.

Альтернативный подход состоит в использовании класса HtmlAdapterServer из стандартной реализации JMX, вместо разработки вашей собственной JSP- страницы. Этот класс находится в файле jmxtools.jar. HtmlAdapterServer – это тоже MBean-компонент. Пример того, как выглядит страница управления с помощью этого класса вы можете посмотреть, запустив сервер JBoss и введя в адресной строке вашего браузере адрессайт
как это все работает?

Итак, сейчас мы более подробно рассмотрим все операции, которые мы выполняли.
1. На первом этапе мы получаем ссылку на MBean-сервер с помощью вызова статического метода findMBeanServer(null) класса-фабрики
MBeanServerFactory. Передача значения null в качестве параметра этому методу означает, что вы хотите получить все серверы известные данному классу-фабрике. В нашем случае нам нужен только один единственный от JBoss. Когда вы используете интерфейс MBean-сервера, вам нужно определить какому MBean’у вы собираете посылать сообщения (т.е. чьи методы вы будете вызывать).
2. Далее мы создаем объект класса ObjectName. В качестве параметра его конструктору мы передаем каноническое имя нашего MBean’а. Шаблон имени состоит из домена (domain), который может быть либо DefaultDomain, либо какой-то свой домен. За доменом следуют пары , разделенные запятыми. Здесь нужно указать как минимум одну такую пару. Формат шаблона в общем виде выглядит следующим образом:

3. На третьем этапе мы обновляем FileLoggingMBean новым значением имени журнального файла, которое было передано JSP-странице. Для этого мы создаем объект класса Attribute фреймворка JMX и передаем его конструктору в качестве параметров имя атрибута и его значение. После этого мы вызываем метод setAttribute() MBean-сервера, передавая ему созданные нами ранее объекты классов Attribute и ObjectName, как параметры. Эти параметры помогают понять, с каким MBean’ом мы будем иметь дело, а также задают атрибут и его значение. Метод setAttribute() будет использовать метаданные MBean’а, хранящиеся на MBean-сервере, чтобы вызвать подходящий setter-метод этого MBean’а.
4. И, наконец, мы получаем с помощью метода getAttribute() значение атрибута из FileLoggerMBean. Этому методу мы передаем параметры: объект класса ObjectName и имя атрибута в виде строки String. Вам также нужно привести тип возвращаемого объекта к тому, что возвращает getter-метод. Этот тип определен, естественно, в интерфейсе FileLoggerMBean.

дополнительные возможности JMX

JMX позволяет выполнять гораздо больше функций, чем простой фреймворк удаленного управления. Он предоставляет дополнительные сервисы, которые вы можете сделать основной частью вашего процесса разработки. Ниже приведем небольшой список этих возможностей:
— Уведомления о событиях. Интерфейсы снабжены возможностью распространения уведомлений среди “слушателей” (listeners) событий. Событием может являться, например, изменение атрибута. Это позволяет MBean’ам взаимодействовать с другими MBean’ами или удаленным менеджером и оповещать друг друга об изменениях состояния.
— Мониторинг. Monitor MBeans могут посылать уведомления о событиях зарегистрированным у них “слушателям”. “Слушателем” может быть другой MBean или приложение. Целевыми объектами наблюдений за атрибутами могут быть: counter, gauge и string. Подробнее о них вы можете прочитать в спецификации.
— Таймер. Timer MBean будет посылать уведомления зарегистрированным “слушателям” по наступлению определенного времени или истечению заданного интервала.

JMX – это значимый и крайне полезный фреймуорк, который вы уже сейчас можете с минимальными усилиями интегрировать с вашими приложениями. Кроме этого JMX может легко интегрироваться с уже существующими технологиями управления, например, SNMP, а также технологиями будущего, например, CIM/WBEM.

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих