Разбор структуры компонента, зачем нужны assets, core и \_build

Загружаем modExtra

• Если вы не знакомы с Git, или он еще не установлен у вас на компьютере - просто скачиваем и распаковываем архив с файлами

• Если Git у вас уже установлен - клонируем репозиторий:

git clone https://github.com/bezumkin/modExtra.git

и удаляем из него директорию ./modExtra/.git - она нам не нужна.

Структура компонента

• _build - скрипты для сборки компонента в транспортный пакет

• assets - файлы, которые должны быть доступны снаружи, из интернет

• core - файлы, которые нужны для внутренней логики компонента

• README.md - файл с общим описанием компонента, нужен для будущего репозитория на GitHub

• rename_it.php - новый скрипт переименования заготовки на php

• rename_it.sh - старый скрипт переименования заготовки на perl

Директория core

- core
-- components
--- имя_компонента
---- здесь уже всё нужное

• controllers - файлы для подготовки страниц админки. Загружают нужные скрипты и стили.

• docs - история изменений, инструкция и лицензия. Эти файлы участвуют в описании пакета.

• elements - устанавливаемые чанки, сниппеты и прочие возможные наследники modElement

• lexicon - словари компонента, обычно только en и ru

• model - директория с объектами компонента и моделями таблиц для баз данных, обычно только для MySql. Здесь же находится и сновной рабочий класс компонента.

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

Директория assets

Директория _build

Конфигурация

• data - список сниппетов, чанков и других modElement, которые будут установлены

• includes - вспомогательные функции для работы сборщика

• properties - список свойств сниппетов. Базовове имя файла должно совпадать с таковым у сниппета.

• resolvers - вспомогательные скрипты, запускающиеся на конечном сайте при установке пакета

• Имя компонента

• Версия

• Нужно ли сразу устанавливать компонент, при сборке?

• Определение рабочих директорий

• Настройка устанавливаемых объектов

• Катеогория, к которой относится объект

• Его первичный ключ, чтобы определить дубликаты?

• Что делать, если такой ключ уже существует: перезаписывать или нет? (обновлять чанки и сниппеты?)

• Свойства дочерних объектов (если есть)

1. Не нужно залезать в build.transport.php вообще

2. Нужно ли упаковывать объект указывается объявлением константы BUILD_имяобъекта_UPDATE

3. Обновление объекта указывается в BUILD_имяобъекта_UPDATE

4. Статичность объекта указывается в BUILD_имяобъекта_STATIC

5. Скрипты, которые будут выполнены при установке пакета (ресолверы) указываются в массиве $BUILD_RESOLVERS

1. Добавляем нужные объекты в _builв/data/transport.типобъекта.php (про это чуть ниже)

2. Указываем, как их устанавливать в конфиге

3. Добавляем ресолверы в _build/resolvers/resolve.любоеимя.php

4. Указываем, имя ресолвера в конфиге

Устанавливаемые объекты

$tmp = array(
    'tpl.modExtra.item' => array(
        'file' => 'item',   // Имя файла в /core/components/имя/chunks/
        'description' => '',    // Описание - будет видно в соотв. поле в админке
    ),
);

Вспомогательные скрипты (ресолверы)

if ($object->xpdo) {
    /* @var modX $modx */
    $modx =& $object->xpdo;

    switch ($options[xPDOTransport::PACKAGE_ACTION]) {
        case xPDOTransport::ACTION_INSTALL:
            // Действия при первой установке пакета
            break;

        case xPDOTransport::ACTION_UPGRADE:
            // Действия при обновлении пакета
            break;

        case xPDOTransport::ACTION_UNINSTALL:
            // Что делать при удалении пакета
            break;
    }
}
return true;

Заключение