Главное меню админ. панели Joomla

Для нашего простейшего компонента потребуется создать всего пять файлов:

• hello.php - точка входа в компонент
• controller.php - содержит основное управление компонентом
• views/hello/view. html .php - обрабатывает данные и передает их в шаблон для вывода
• views/hello/tmpl/default.php - шаблон для вывода данных
• hello.xml- XML служит для передачи инструкций для Joomla по установке компонента

Joomla всегда обрабатывает ссылку в корневом файле index.php для страниц Front End (сайт) или administrator/index.php для страниц Back End (панель администратора). Функция обработки URL загрузит требуемый компонент, основанный на значении "option" в URL (метод GET) или переданных данных методом POST.

Для нашего компонента, URL выглядит так:

Index.php?option=com_hello&view=hello

Код для этого файла довольно типичен для всех компонентов.

Стоит заметить, что

JPATH_COMPONENT - это абсолютный путь к текущему компоненту, в нашем случае components/com_hello.

JPATH_COMPONENT_SITE - Для Front End

JPATH_COMPONENT_ADMINISTRATOR - Для Back End

DS - является автоматическим выбором слеша (разделителя директорий) "\" или "/".

После загрузки основного контроллера проверяется наличие определенного контроллера с последующей загрузкой. В данном случае у нас только основной контроллер. JRequest ::getVar() загружает значение переменной из URL или переданной методом POST. Допустим мы имеем адрес следующего вида:

Index.php?option=com_hello&controller=controller_name

Тогда можно определить название нашего контроллера следующим образом:

echo JRequest::getVar("controller", "default");

Мы имеем основной контроллер НelloController в com_hello/controller.php, так же загружаются дополнительные названия контроллера, к примеру: для HelloControllerController1 класс будет объявлен в файле com_hello/controllers/controller1.php

{Componentname}{Controller}{Controllername} - Такой стандарт упрощает схему многозадачного компонента.

После того, как контроллер создан, мы инструктируем его выполнить задачу, которая определяется переданными параметрами в URL (либо через POST):

index.php?option=com_hello&task=sometask.

Если переменная "task" явно не задана, то по умолчанию выполниться display(), задача которого просто вывести шаблон по умолчанию. Пример стандартных задач - save, edit, new и т. д.

На этом шаге контроллер переадресовывает страницу. Обычно используется для таких задач как save.

Главная точка входа (hello.php) по существу пропускает управление на контроллер, который обрабатывает выполнение задачи, которая была определена в запросе.

создание контроллера

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

Код основного контроллера:

Конструктор класса JController всегда будет регистрировать задачу display(). Этот метод сам определит необходимый шаблон и данные которые необходимо загрузить в него. Более того один шаблон может разделяться на уровни(layout) , каждый из которых отобразиться при запуске определенной задачи. В нашем случае мы явно не прописываем имя задачи, поэтому (как уже указывалось выше) используется default.

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

• Разметка входа по умолчанию
• Разметка по умолчанию для регистрации
• Напоминание по умолчанию
• Разметка по умолчанию для сброса
• Разметка по умолчанию для пользователя
• Разметка пользовательской формы

создание вида

Извлекаем необходимые данные и передаем их в шаблон. В этом нам поможет расширенный класс JView и его метод assignRef, с помощью которого мы передаем переменные в шаблон.

Пример кода вида:

создание шаблона

Наш шаблон очень прост, мы только отображаем приветствие, которое передавали в view:

создание файла hello.xml

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

• детали о компоненте и о авторе компонента.
• список файлов, которые должны быть скопированы.
• внешний PHP файл, который исполняет дополнительную установку и деинсталлирует операции.
• внешние SQL файлы, которые содержит запросы к базе данных, отдельно для установки и удаления

Формат XML файла следующий:

Hello 2007 02 22 John Doe [email protected] http://www.example.org Copyright Info License Info Component Version String Description of the component ... index.html hello.php controller.php views/index.html views/hello/index.html views/hello/view.html.php views/hello/tmpl/index.html views/hello/tmpl/default.php Hello World! index.html admin.hello.php

Также есть файл, который будет скопирован, это - index.html.

index.html помещен в каждый каталог, чтобы препятствовать пользователям получать список файлов каталога. Эти файлы содержат одну единственную строку:

Прикрепленные файлы:

Понравилось:
16

Не понравилось: 0

Недоступен ни один перевод.

Создание главного каталога компонента - com_megashop

Итак, создаем где-нибудь на локальном диске каталог com_megashop, а внутри него каталоги site , admin , media , а также два пустых файла - index.html и megashop.xml . В итоге получится вот такая картинка:

Создание файлов и каталогов для backend-части компонента

Теперь заходим в каталог admin и создаем следующие каталоги:

• controllers - тут будут храниться файлы с классами контроллеров back-end части
• css - для хранения файлов CSS-стилей, используемых для отрисовки элементов компонента внутри админки Joomla
• help - для хранения справки для нашего компонента (на разных языках). Понадобится, если мы захотим написать инструкцию по использованию компонента
• helpers - для хранения классов-помощников
• language - здесь будут размещаться языковые файлы компонента
• models - сюда будем помещать модели для административной части
• sql - в этом каталоге будут храниться файлы с SQL-запросами для создания всех таблиц компонента в базе данных Joomla
• tables - тут будут располагаться классы для работы с таблицами компонента
• views - тут будут храниться файлы представлений, которые будут рисовать всё, что мы увидим в админке Joomla - относительно нашего компонента

После создания каталогов создадим пустые файлы:

• access.xml - файл прав доступа для компонента для разных категорий пользователей
• config.xml - файл всех параметров нашего компонента
• controller.php - файл главного контроллера административной части
• index.html - индексный файл, который предотвратит отрисовку содержимого каталога, если умный пользователь напрямую пропишет путь к админ-каталогу компонента
• megashop.php - "входная" точка админ-части компонента. Его Joomla вызовет в первую очередь, когда мы будем обращаться через админку к компоненту

Созданные каталоги и файлы выглядят у меня вот так:

Создание файлов и каталогов для frontend-части компонента

Теперь переходим снова на уровень выше и заходим в созданный нами в начале каталог site. Там потребуется создать каталоги и файлы:

• css - для хранения файлов CSS-стилей, предназначенных для отрисовки компонента на сайте. Это все стили, которые и будут формировать внешний "облик" компонента - то, что увидит пользователь сайта.
• js - сюда будем помещать все JavaScript-файлы скриптов, jQuery-библиотеки, плагины jQuery и т.д., словом всё, что относится к скриптам. Они будут выполнять всю динамическую логику на стороне браузера, когда пользователь будет работать с частями компонента на сайте.
• language - сюда поместим файлы локализации - с сообщениями, которые будут встречаться в нашем компоненте.
• models - здесь будут храниться файлы моделей для frontend-части компонента
• views - тут будут размещены файлы представлений, которые отрисуют разные части нашего компонента на сайте
• controller.php - файл главного контроллера для frontend-части
• index.html - индексный файл, который предотвратит отрисовку содержимого каталога, если умный пользователь напрямую пропишет путь к frontend-каталогу компонента
• megashop.php - "входная" точка frontend-части компонента. С неё всегда начинается исполнение компонента, когда пользователь работает с частями компонента на сайте Joomla

У меня после создания всего вышеперечисленного вышло вот такое:

Создание каталога изображений - media/images

Снова выходим на уровень "вверх" и переходим к созданному каталогу media . Внутри него потребуется создать вложенный каталог images и пустой файл index.html. Получится следующее:

На этом этапе мы создали почти все основные каталоги и самые главные файлы компонента. Наполнение каталогов (например models , views и т.д.) будет осуществляться дальше по ходу текста статьи. Мне хотелось, чтобы мы вместе прошли этап создания всей файловой структуры компонента, чтобы далее, когда я буду ссылаться на какой-то файл, вам уже было понятно, где его создавать и редактировать.

Кодировка файлов

На данный момент, как вы заметили, мы создали просто "заглушки" - пустые файлы. Наполнять мы их будем позже. Но во избежание дальнеших проблем с кракозябрами я сразу хочу сказать вам, в какой кодировке вы должны набирать код всех классов и примеров, которые будут встречаться - это кодировка UTF-8 . Joomla является мультиязычной системой, т.е. CMS системой, поддерживающей множество языков - вплоть до китайского с его иероглифами. Кодировка UTF-8 (в отличие например от windows-1251) способна поддерживать наборы языковых символов, встречающихся во всех странах мира. Для того, чтобы явно указать кодировку, достаточно установить любой редактор кода (например, Notepad++). Лично я пользуюсь очень хорошим редактором EditPlus (он платный), однако вам подойдет любой, поддерживающий сохранение файлов в кодировке UTF-8

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

При разработке любого из расширений для CMS Joomla! всегда возникает вопрос его дальнейшей установки на рабочий проект. Именно для этого необходимо собрать расширение в установочный пакет, что может вызвать затруднения без соответствующего опыта. В CMS Joomla! создание установочного пакета для какого-либо его расширения имеет ряд особенностей, которые подробно рассматриваются в данной статье. Наиболее важные из них: создание файловой структуры расширения, файла манифеста, обновление расширения после установки и др.

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

Файловая структура расширения

Создать файловую структуру для уже готового расширения Joomla! достаточно просто, поскольку она в большинстве случаев будет совпадать со структурой файлов и папок самого расширения с некоторым набором исключений и дополнений.

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

Общая файловая структура расширения

Чаще всего все основные файлы существующего в CMS Joomla! расширения находятся в одной папке. Например, для плагина это может быть папка plugins/system/sef , для модуля modules/mod_articles_news , для шаблона templates/protostar и т.д. Для сборки инсталляционного пакета расширения необходимо скопировать все его файлы в отдельную папку. Желательно ее назвать в соответствии с именем самого расширения.

Также в корневой директории установочного пакета могут содержаться дополнительные файлы и папки. Например, media – папка, использующаяся для хранения css стилей, изображений, js скриптов и т.д., которые используются в расширении. Она может содержать соответствующие подпапки css , images , js и др. Содержимое media директории описывается специальным тегом в установочном файле манифеста расширения (см.) и копируется при установке в папку media/[имя_расширения] .

В папке language размещаются языковые файлы расширения, которые могут копироваться в системную языковую директорию. Языковые файлы в папке language необходимо размещать в подпапках с именами, соответствующими тегам их языков. Например, в папке language/en-GB размещаются языковые файлы для английского языка, в language/ru-RU – русского и т.д.

Папка sql чаще всего используется для расположения sql файлов, использующихся при установке и удалении расширения, а также для хранения обновлений базы данных для каждой из версий расширения в подпапке updates . Соответствующие sql файлы вносят изменения в базу данных сайта при установке, удалении или обновлении расширения.

Файловая структура компонента для CMS Joomla!

Главным отличием компонента от других расширений Joomla! является наличие отдельной пользовательской и административной части. При создании установочного пакета принято создавать в его корне папки admin и site для размещения в них файлов и папок административной и пользовательской части компонента соответственно. В папку admin копируется структура, которая расположена или планируется располагаться в папке administrator/components/[имя_компонента] в CMS Joomla!. Папка site при этом будет содержать все файлы и папки из components/[имя_компонента] .

Файл манифеста инсталляционной сборки компонента должен обязательно находиться в его корневой директории и называться [имя_компонента].xml , хотя после инсталляции он будет скопирован в административную директорию компонента. Также в корневую директорию помещается папка media, если она используется в компоненте.

Папка sql при сборке компонента обязательно должна находиться в директории admin , а папки language создаются отдельно в admin и site для административной и пользовательской части сайта отдельно. Их внутренняя структура аналогична той, что описана в общем случае.

Создание файла манифеста

Файл манифеста должен быть расположен в корне установочного пакета и иметь название manifest.xml или [имя_расширения].xml . Правильное описание тегов в файле манифеста позволит скопировать все файлы и папки расширения в соответствующие каталоги CMS Joomla!, выполнить обновление структуры в базе данных, добавить информацию о расширении в CMS, легко обновлять расширение в дальнейшем и т.д.

Корневой элемент

Корневым элементом файла манифеста является . Этот элемент заменил старый корневой элемент , который использовался в Joomla! 1.5. Корневой тег может содержать ряд атрибутов, список которых приведен ниже:

Атрибут Значение Тип расширения Краткое описание

type	component (компонент) file (файл) language (языковой пакет) library (библиотека) module (модуль) package (пакет из нескольких расширений) plugin (плагин) template (шаблон)	Все типы	Этот атрибут описывает тип расширения для инсталлятора. Основываясь на этом типе по разному могут формироваться внутренние теги в файле манифеста.
version		Все типы	Определяет версию Joomla!, для которой разрабатывается это расширение.
method	install upgrade	Все типы	Если атрибут имеет значение install, то установщик прервет свою работу, если обнаружит в Joomla! существующий файл или папку устанавливаемого расширения. Если же атрибут имеет значение upgrade, то при повторной установке расширения установщик заменит существующие файлы и выполнит другие действия по обновлению расширения, указанные далее в файле манифеста.
client	administrator	Модули	Этот атрибут позволяет определить в какой части сайта (клиентской или административной) будет доступен устанавливаемый модуль.
group	Строка	Плагины	Атрибут должен содержать название группы для устанавливаемого плагина (system, user, content и т.д.). Название должно совпадать с соответствующей директорией в папке plugins, в которую и будет установлен плагин.

Информация о расширении и разработчике

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

• – системное имя расширения с префиксом (например, com_banners , mod_login)
• – имя автора (например, BoxApp)
• – дата создания расширения или выхода новой версии (например, 22.11.2014)
• – заявление об авторском праве (например, © 2014 - 2015 BoxApp. Все права защищены.)
• – лицензионное соглашение (например, GNU General Public License version 2 or later)
• – e-mail адрес автора (например, info@сайт)
• – ссылка на сайт автора (например, http://сайт)
• – номер версии расширения (например, 1.2.0)
• – описание расширения. Этот параметр использует стандартный механизм Joomla! для перевода текста на разные языки, поэтому можно в качестве значения использовать языковую константу. Например, COM_EXAMPLE_XML_DESCRIPTION .

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

Файлы и папки расширения

Чтобы при установке были скопированы файлы и папки расширения, необходимо заполнить блок в файле манифеста. Например, для модуля Joomla! этот блок может иметь следующий код:

language tmpl [имя_модуля].php helper.php index.html [имя_модуля].xml

Если собирается установочный пакет для компонента Joomla!, то файлы и папки для пользовательской части сайта помещаются в директорию site корневой папки установочного пакета. При этом блок может иметь следующий вид:

controllers helpers models views [имя_компонента].php controller.php index.html metadata.xml router.php

Здесь в качестве атрибута folder тега указана директория site , соответственно в ней должны быть расположены папки, указанные во внутренних тегах (controllers , helpers , models , views) и файлы, указанные с помощью тегов ([имя_расширения].php , controller.php , index.html , metadata.xml , router.php). При этом внутренняя структура папок, указанных в тегах будет полностью скопирована вместе со всеми вложенными папками и файлами. В случае с компонентом вся указанная в теге структура папок и файлов будет скопирована в директорию components/[имя_компонента] .

Медиа файлы

В структуре CMS Joomla! для медиа файлов отведена отдельная папка в корне с названием media . Именно в нее инсталлятор производит копирование медиа файлов расширения, которые указываются в теге . При этом, расположение файлов в медиа папке расширения соответствует определенной структуре. В корневой директории установочного пакета создается папка media . В ней должны быть расположены подпапки, если в расширении используется соответствующий тип файлов: css (для css файлов стилей), images (для хранения изображений) и js (для скриптов, использующихся в расширении). Кроме этого в папке media могут быть расположены и другие подпапки и файлы, использующиеся в работе расширения. Блок с тегом в файле манифеста может иметь следующий вид:

css images js index.html

В примере выше атрибуты тега определяют:

• folder – имя папки в корневой директории инсталляционного пакета, в которой расположены подпапки и файлы из тегов и
• destination – имя папки расширения, в которую будет скопирована указанная ниже структура папок и файлов. Например, com_example для компонента, mod_example для модуля, plg_system_example для системного плагина.

В итоге медиа файлы и папки, указанные в теге будут скопированы из папки madia установочного пакета по пути media/[имя_расширения] .

Языковые файлы

В Joomla! 1.5 использовался подход, когда языковые файлы расширения при его установке копировались в системную папку CMS для хранения языковых файлов пользовательской части сайта language , или его административной части administrator/language . Поддержка работы этого подхода осталась и в следующих версиях Joomla! включая 3.x. Чтобы воспользоваться этим подходом, необходимо разместить тег в корневом теге файла манифеста, внутри которого нужно указать теги для каждого из языков, поставляемых вместе с расширением в инсталляционной сборке. Например, этот блок может иметь следующий вид:

en-GB.[имя_расширения].ini ru-RU.[имя_расширения].ini

При этом языковые файлы должны быть расположены в папке language , а их имена обязательно должны соответствовать названию расширения вместе с префиксом, соответствующим его типу (например, com_example , plg_system_example , tpl_example и т.д.). При установке расширения Joomla! эти файлы будут скопированы в один из подкаталогов папки language , название которого соответствует указанному в теге атрибуту tag . Например, файл из установочного пакета language/en-GB.[имя_расширения].ini будет скопирован в папку Joomla! по пути language/en-GB/en-GB.[имя_расширения].ini в корневой директории Joomla!.

Начиная с версии Joomla! 1.6 было предложено хранить языковые файлы непосредственно в папке расширения, а не копировать их в системные папки с языковыми файлами. При этом Joomla! автоматически загружает языковые файлы расширения при его использовании.

Новый подход с хранением языковых файлов внутри расширения имеет ряд явных преимуществ. Например, если администратор удалил один из языков в CMS Joomla!, то соответствующие языковые файлы расширения не будут затронуты. Они останутся в составе расширения и будут доступны, если язык снова будет установлен. Кроме этого, администратору сайта будет очень легко переопределить константы в языковых файлах расширения, если ему это понадобится. Достаточно просто скопировать языковой файл из папки расширения в системную директорию с языковыми файлами и переопределить нужные константы. При этом CMS Joomla! сама подключит в первую очередь файл из системной директории в соответствии с приоритетом, а при обновлении расширения изменения в языковом файле не будут перезаписаны.

Для автоматического подключения языковых файлов из папки расширения их необходимо расположить в соответствии с определенной структурой. Для пользовательской и административной части сайта эта структура одинакова, если речь идет о компоненте. Все языковые файлы размещаются в папке с именем, соответствующим языковому тегу (атрибуту tag) внутри директории language . Например, language/en-GB . И так для каждого из языков, поставляемых в установочном пакете расширения. Папка language должна быть расположена в корне инсталляционной сборки, а в теге манифеста нужно добавить тег для этой папки:

… language …

При установке расширения папка language будет скопирована в директорию расширения вместе с другими его папками и файлами.

Если необходимо, мы также можем добавить в файл манифеста и тег . В соответствии с созданной структурой папок он может иметь следующий вид:

language/en-GB/en-GB.[имя_расширения].ini language/en-GB/en-GB.[имя_расширения].sys.ini language/ru-RU/ru-RU.[имя_расширения].ini language/ru-RU/ru-RU.[имя_расширения].sys.ini

При этом языковые файлы будут также скопированы в системную директорию language и удалены из нее при удалении расширения администратором сайта. Изменения, внесенные в языковые файлы расширения в системной директории, будут иметь приоритет над значениями в папке расширения. При этом sys.ini файл подключается всегда из системной директории в административной части расширения, за исключение случая, когда расширение устанавливается и в его составе есть папка language с соответствующим sys.ini файлом. Только в этом случае будут использоваться значения языковых констант sys.ini файла из папки расширения. Эта особенность может быть использована, если разработчик расширения хочет иметь два варианта перевода для констант в sys.ini файле, которые используются, например, для показа сообщения о успешной установке расширения (при установке) и его обычного описания.

Настройки

Компоненты не поддерживают настройки в файле манифеста. Это устаревший подход, который присутствовал в Joomla! 1.5. Для добавления настроек в компонент используется отдельный файл config.xml . Он помещается в корень административной директории при установке компонента и указывается в теге внутри тега вместе с другими файлами и папками для административной части компонента.

Блок является дочерним для корневого тега файла манифеста и отвечает за описание настроек для расширения, которые можно указать в административной части сайта. Настройки расширений в основном расположены в менеджере для управления соответствующим типом расширений Joomla! (например, Менеджер плагинов, Менеджер модулей или Менеджер шаблонов). В официальной документации указывается, что настройки расширения могут быть указаны в отдельном файле расширения, который должен называться config.xml и иметь корневой элемент , но на практике этот подход работает только для компонентов. Для остальных типов расширений Joomla! блок нужно размещать в файле манифеста.

Первым дочерним тегом у должен быть (необязательно для компонентов), который в свою очередь может содержать один или более дочерних тегов , которые будут отображаться в виде отдельных вкладок в HTML коде станицы настроек данного расширения, и будут служить контейнерами для групп полей формы с настройками расширения. В атрибуте name тега можно указать имя вкладки. Атрибуты label и description используются для указания названия и краткого описания вкладки, и могут содержать языковые константы в качестве значений. Если атрибут label не указан, то языковая константа будет сформирована автоматически по шаблону COM_CONFIG_[имя_вкладки]_FIELDSET_LABEL (где имя_вкладки – это значение атрибута name) и достаточно будет лишь указать перевод в соответствующих языковых файлах расширения.

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

Приведем пример конфигурационного файла компонента com_example .

JSHOW JHIDE JYES JNO

В этом примере описаны две группы настроек в тегах с именами base и permissions . Стоит обратить внимание на то, что все языковые константы, имеющие префикс COM_EXAMPLE_ , необходимо определить в sys.ini языковом файле расширения. Остальные константы являются системными и их можно использовать в любом месте расширения без необходимости их описания в языковых файлах. Значения этих констант для текущего языка будут выводиться из системных языковых файлов, если соответствующий язык установлен в CMS Joomla!.

Приведем еще один пример блока для системного плагина sef .

Административная часть расширения

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

Для добавления пункта меню компонента в меню "Компоненты" главного меню Joomla! используется тег и . Например, этот блок может иметь следующий вид:

COM_EXAMPLE COM_EXAMPLE_SUBMENU_ANOPTION COM_EXAMPLE_SUBMENU_VIEWNAME

В результате после установки компонента в пункт меню Компоненты основного меню Joomla! будет добавлен новый пункт и его подпункты в соответствии с указанными параметрами.

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

Перечислим доступные в теге атрибуты:

• link – ссылка, по которой перейдет пользователь, нажав на соответствующий пункт меню
• img – относительный путь к файлу изображения, которое будет показано возле пункта меню (16x16 пикселей)
• [текстовый_параметр] – произвольный параметр, который будет добавлен к запросу при формировании ссылки пункта меню. Например, нажав на пункт меню COM_EXAMPLE пользователь перейдет посылке index.php?option=com_example&view=cpanel .

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

controllers helpers models sql tables views access.xml [имя_компонета].php config.xml controller.php index.html

Вся структура папок и файлов вместе с их вложенными элементами будет скопирована по пути:

Administrator/components/[имя_компонента]

Как и корневой блок файла манифеста, блок может содержать вложенный тег с дочерними тегами для описания языковых файлов для административной части компонента. Здесь логика размещения и подключения языковых файлов аналогична той, которая описана выше в разделе . Наиболее современным является подход, когда языковые файлы для административной части сайта также включаются в состав компонента. При этом директория admin в корне установочного пакета должна содержать папку language , в которой языковые файлы имеют аналогичные имена и так же расположены в подпапках с названием тега языка. Для копирования директории language соответствующий тег должен содержаться в родительском теге , а при описании языковых файлов в теге они также будут добавлены в системную директорию (для административной части это administrator/language).

Приведем пример описания и блоков внутри тега для копирования языковых файлов компонента:

... controllers helpers language models sql tables views access.xml [имя_компонета].php config.xml controller.php index.html language/en-GB/en-GB.[имя_компонента].ini language/en-GB/en-GB.[имя_компонента].sys.ini language/ru-RU/ru-RU.[имя_компонента].ini language/ru-RU/ru-RU.[имя_компонента].sys.ini …

В файле sys.ini при этом, чаще всего описываются следующие языковые константы:

• название и описание компонента из тегов файла манифеста и
• константы, содержащие названия пунктов меню
• константы с названиями и описаниями полей формы настроек компонента, которые содержатся в файле config.xml

Особенностью файла sys.ini является то, что он всегда подключается в административной части компонента вне зависимости от контекста. Соответственно в него имеет смысл помещать только те языковые константы, которые используются вне компонента (список выше). Остальные константы, которые используются непосредственно внутри устанавливаемого компонента, должны находиться в языковых ini файлах без суффикса sys (en-GB.[имя_компонента].ini).

Стоит также обратить внимание, что для компонента файл config.xml должен находиться в корне директории admin и участвовать в описании файлов в теге , находящегося внутри блока , как в примере выше.

Установочный SQL скрипт

Стандартный инсталлятор в Joomla! позволяет выполнить произвольный sql скрипт при установке или удалении расширения в Joomla!. Для этого нужно написать соответствующие файлы с расширением sql и поместить их в папку sql в корне расширения. Например, пусть это будут файлы sql/example.install.sql , который будет выполняться при установке расширения, и sql/example.uninstall.sql , для выполнения sql при удалении расширения. Содержание этих sql файлов может быть, например, следующее:

Для файла example.install.sql:

CREATE TABLE IF NOT EXISTS `#__example_extension_table` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `ordering` int(11) NOT NULL DEFAULT "0", `state` tinyint(3) NOT NULL DEFAULT "1", PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;

Для файла example.uninstall.sql:

DROP TABLE IF EXISTS `#__example_extension_table`;

Как видим, в инсталляционном файле создается новая таблица базы данных с именем #__example_extension_table , где префикс #_ будет заменен на префикс таблиц базы данных, указанный в настройках Joomla!, а при удалении расширения эта таблица будет удалена из базы данных.

Чтобы соответствующие скрипты были выполнены, необходимо добавить теги и в корневой тег файла манифеста и указать папку sql в дочерних элементах тега . Для этого в файл манифеста можно добавить следующий код:

sql/example.install.sql sql/example.uninstall.sql ... sql ...

Здесь элемент может содержать один или более дочерних элементов, каждый из которых описывает один sql файл. Его драйвер базы данных описывается в атрибуте driver , а кодировка в атрибуте charset .

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

... … sql … ...

SQL скрипт для обновления

Начиная с Joomla! 1.6 появилась возможность обновления расширений в соответствии с их версиями. Описание всех возможностей системы обновления расширений в Joomla! заслуживает отдельной статьи. Здесь же стоит упомянуть о том, что в корневой блок файла манифеста мы можем добавить тег , который в свою очередь может содержать дочерний тег с указание параметров для обновления базы данных. Например, этот блок может содержать код:

sql/updates

При этом в папке sql должна быть расположена подпапка updates , содержащая файлы обновления структуры и данных в базе данных приложения. Это должны быть sql файлы с названиями, точно соответствующими версии расширения. Например, если у пользователя установлено расширение 1.0.0 и он устанавливает расширение версии 1.1.0 , то в папке sql/updates должен находиться файл 1.1.0.sql с изменениями для этой версии.

Инсталляционный php скрипт

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

example.script.php

Этот файл должен содержать класс с именем [имя_расширения]InstallerScript . Для плагинов обязательно необходимо включать имя группы (например, plgsystempluginname). Установочные пакеты библиотек не поддерживают выполнения php скриптов. Приведем структуру этого класса ниже вместе с доступными для определения функциями:

Class [имя_расширения]InstallerScript { /** * Constructor * * @param JAdapterInstance $adapter The object responsible for running this script */ public function __construct(JAdapterInstance $adapter); /** * Called before any type of action * * @param string $route Which action is happening (install|uninstall|discover_install|update) * @param JAdapterInstance $adapter The object responsible for running this script * * @return boolean True on success */ public function preflight($route, JAdapterInstance $adapter); /** * Called after any type of action * * @param string $route Which action is happening (install|uninstall|discover_install|update) * @param JAdapterInstance $adapter The object responsible for running this script * * @return boolean True on success */ public function postflight($route, JAdapterInstance $adapter); /** * Called on installation * * @param JAdapterInstance $adapter The object responsible for running this script * * @return boolean True on success */ public function install(JAdapterInstance $adapter); /** * Called on update * * @param JAdapterInstance $adapter The object responsible for running this script * * @return boolean True on success */ public function update(JAdapterInstance $adapter); /** * Called on uninstallation * * @param JAdapterInstance $adapter The object responsible for running this script */ public function uninstall(JAdapterInstance $adapter); }

Краткое описание функций:

• __construct – конструктор класса
• preflight – вызывается перед выполнением какого-либо рода действий
• postflight – вызывается после выполнения какого-либо рода действий
• install – вызывается при выполнении установки расширения
• update – вызывается при выполнении обновления расширения
• uninstall – вызывается при выполнении удаления расширения

Сервер обновлений расширения

В файле манифеста расширения можно указать блок , являющегося наследником базового блока файла манифеста, который позволяет определить параметры обновления данного расширения Joomla!. Этот блок содержит элемент , который непосредственно определяет параметры обновления. Приведем список доступных атрибутов элемента :

Значением тега должен быть url адрес xml файла с описанием версий расширения, на основе которого CMS Joomla! сможет сделать вывод о необходимости обновления данного расширения. Приведем пример блока :

http://сайт/updates/joomla/plugins/plg_content_disqusforcontent.xml

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

Упаковка расширения

Зачастую установочный набор файлов и папок расширения распространяется в виде zip архива. Его нужно упаковать так, чтобы файлы и папки, расположенные в корневой директории инсталляционной сборки (например, файл манифеста [имя_расширения].xml) находились в корне архива, а не в его подпапках (файловая структура в архиве аналогична созданной корневой директории инсталляционной сборки). Хорошей практикой считается называть архив, как и расширение вместе с префиксом (например, com_example.zip , plg_system_example.zip , tpl_example.zip и т.д.) в нижнем регистре.

Инсталлятор Joomla! имеет внутренние механизмы, позволяющие предварительно распаковать инсталляционный архив во временную директорию сайта перед установкой, поэтому пользователь расширения может сразу использовать собранный архив для установки расширения. Исключение составляют расширения, которые требуют для работы другое расширение и поставляются вместе. Например, для работы компонента обязательно нужно установить вместе с ним плагин. В таких случаях установочный архив может называться com_example_UNZIPFIRST.zip или com_example_UNZIPME.zip . Перед установкой его нужно предварительно распаковать. Внутри такого архива часто расположены несколько других инсталляционных архивов других расширений и инструкция по их установке. Хотя более правильным способом выхода из ситуации, когда в составе инсталляционного пакета поставляется сразу несколько расширений Joomla!, считается сборка специального установочного пакета (package), который в свою очередь является расширением Joomla!, имеет отдельный файл манифеста, набор архивов расширений и устанавливается через Менеджер расширений Joomla!. Но про этот тип расширений и особенности их сборки стоит рассказать отдельно.

Примеры

Сообщество Joomla! очень большое, что позволяет найти большое количество готовых решений для данной CMS в виде расширений. Большое количество расширений Joomla! собрано и каталогизировано на официальном сайте extensions.joomla.org . Каждое из них может служить примером для сборки и оформления собственных расширения. К тому же много расширений поставляется непосредственно в составе CMS Joomla!, они также могут служить примерами для подготовки собственных сборок.

Команда BoxApp активно занимается разработкой бесплатных расширений для CMS Joomla!, которые можно скачать в разделе загрузок . Там же можно найти описания и документацию для наших расширений. Их тоже можно использовать в качестве образца для подготовки и оформления собственных установочных пакетов.

Для того чтобы иметь хороший рабочий пример для статей на тему разработки компонента для Joomla! 3.0 , я (David Hurley) выбрал вариант прохождения непосредственно по процессу написания реального расширения. Этот компонент будет доступен для обзора и загрузки с сопроводительного веб-сайта Lendr (сейчас сайт недоступен), на который я буду ссылаться в этой и будущих статьях. Моя цель – это написание полноценного компонента, а не примера вроде "Hello World", для того чтобы продемонстрировать ключевые моменты реальной разработки компонента .

Шаг 1: Опишите основную схему компонента

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

Детали компонента

Название: Lendr
Название компонента: com_lendr
Описание: Lendr – это компонент Joomla! 3.0 (использующий Bootstrap), который позволит пользователям создавать профиль, добавлять книги в коллекции своей библиотеки, просматривать библиотеки других пользователей, попросить книгу в долг, добавлять книги в списки желаемых (wishlist), а также подписываться на список ожидания определенной книги.

Основные функции

Новый компонент Lendr будет иметь следующий набор возможностей:

• Аккаунты пользователей / Профили
• Книги / Библиотеки для пользователей
• Списки для желаемых книг
• Одалживание / Заимствование книги
• Запросы на заимствование книги
• Списки ожиданий на уже заимствованные книги

Теперь мы должны написать базовую структуру необходимых нам файлов. Это точно не будет исчерпывающий список, и он, скорее всего, будет изменяться в процессе написания компонента. Однако, имея изначальную схему, мы сможем хоть как-то придерживаться нашего пути. Вот первоначальная схема ключевых файлов необходимых для Lendr:

Controllers Models Views Tables Misc.

Save List Add Edit Lend Delete Wish Review Request Default	Book Default Library Profile Review Waitlist Wishlist	Book Wishlist Library Profile Waitlist Review	Book Wishlist Library Waitlist Review	Install Router XML

Основные файлы

Теперь, когда мы все выписали, мы начинаем создавать эти файлы в нашей структуре папок.

Шаг 2: Создайте файлы базы данных

Мы начинаем с создания файлов базы данных. Мы сохраняем эти файлы в папке таблиц, которая расположена во фронтэнде нашего компонента. Мы создаем все файлы, которые описали в нашей схеме. Вот один из этих фалов /components/com_lendr/site/tables/book.php:

В нашей форме только одно поле с именем test. Нам нужно его удалить(или изменить) и сделать что бы у нас было 3 поля: Имя , E-mail и Сообщение

После добавления этих полей форма у нас будет выглядеть так:

Если обратить внимание у нас появилось несколько дополнительных атрибутов в полях field:

• required="true" - означает что поле будет обязательное, если его не заполнить будет ошибка!
• validate="email" - означает что выполнится проверка или в это поле введен E-mail адрес (проверка будет выполняться только на стороне сервера)

Теперь нам нужно вывести эти поля в форме!
Для этого откроем файл components/com_form/views/form/tmpl/default.php

Для вывода полей формы, которые мы перед этим создали в XML файле, используются строки:

//для вывода метки поля из атрибута "label" echo $this->form->getLabel("name"); //для вывода самого поля, название поля содержится в атрибуте "name" echo $this->form->getInput("name");

Теперь нам нужно вывести три наших поля в форме, и код шаблона нашей формы изменится на такой:

Форма обратной связи