Пришла пора исправить положение с документацией к DocLister'у — блог автора закрылся, посылать читать документацию стало некуда. Что-то, конечно, осталось в кэше гугла и закромах Wayback Machine, но удобство пользования там никакое.

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

Если есть какие-то замечания по документации, то пишите в комментариях, а еще лучше отправляйте правки сразу в docs (:

P.S. Делать документацию даже к своим дополнениям — дело унылое, что говорить про не свои, так что не откажусь от пива — R189925059228 ((:

Спасибо за поддержку: Agel_Nash , Fess .

В develop-сборке Evo Custom v1.1b-d7.1 появилось новое событие OnParseProperties, которое сразу вызвало у меня интерес.

Событие срабатывает при разборе параметров сниппетов и плагинов, что позволяет эти параметры подменять. И хотя параметры плагинов пока обрабатываются как-то криво, можно воспользоваться событием OnParseProperties для вмешательства в работу SimpleGallery.

Есть сайт, где реализовано две галереи с помощью SimpleGallery — в одной картинки с образцами продукции, а во второй хранятся фотографии сотрудников с их биографиями (по смыслу это не совсем галерея, просто удобно их хранить так, а не в документах). Логично было бы вкладки с галереями подписать по-разному, но в SimpleGallery название вкладки (в данном случае — «Галерея») задается в параметрах плагина, который может быть только один. Выход из положения — плагин на событие OnParseProperties:

$e = &$modx->event;
if ($e->name == "OnParseProperties") {
    if ($element == "SimpleGallery") {
        if (isset($args['template']) && $args['template']==6) {
            $out = array ();
	    //задаем новое значение параметра tabName
            $out["tabName"] = "Сотрудники";
	    $e->_output = $out;
        }
    }
}

Теперь для страницы «Список сотрудников» с шаблоном 6 вкладка будет называться «Сотрудники», а во всех остальных случаях — «Галерея». Можно проверять и $args['id'] — id страницы, на которой вызывается плагин.

Немного подумав, я решил сделать возможность подменять в onParseProperties не только параметры плагина, но и свойства соответствущего ему класса. Таким образом появляется возможность использовать произвольные списки загружаемых js- и css-файлов, что в сочетании с параметром controller позволяет (в теории) менять интерфейс и логику работы плагина для разных страниц. Например, для разных типов галерей можно использовать разные наборы дополнительных полей.

Аналогично можно изменить работу и других моих плагинов, тем более, что они все делаются из общей заготовки. Например в SimpleFiles теперь появляется возможность создавать разные типы файловых архивов (например, в одном документе храним только zip, в другом только doc и xls), меняя с помощью события OnParseProperties список разрешенных для загрузки файлов.

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

Читать дальше →

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

Читать дальше →

Раз такой вопрос все же возник, то покажу, как делать вывод. Ввод, я надеюсь, понятен интуитивно (:

Читать дальше →

В прошлой статье Grinyaha рассказал о простых примерах использования DocLister — по сути, как вместо Ditto вызвать DocLister. Я покажу пример тоже для новичков, но чуть сложнее — для понимания необходимо минимальное знание PHP.

Читать дальше →

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

Читать дальше →

Итак, в прошлой части мы создали структуру нашей базы со своими хитростями и всем прочим.
Теперь нас должны интересовать 3 основные вещи: запись в Базу данных, чтение данных из базы данных, и обновление.

Читать дальше →

Изначально я хотел описывать всё, включая разбор данных, но в итоге понял, что это будет просто громадная часть. Так что все эти статьи для тех людей кто хотя бы может преобразовать JSON строку, в нужную ему структуру.

Установка

Читать дальше →

Вступление(ленивым можно пропускать до следующего подзаголовка)

Я человек с не очень богатым опытом создания интернет магазинов: что-то около 10-15 штук. Чаще всего приходилось пользоваться уже готовыми решениями, кои перечислять здесь не буду, дабы не создавать рекламы.
Но вот внезапно возникла одна задача: нужно реализовать магазин с базой в 2-3 млн товаров, в перспективе, может, даже 5. После долгих размышлений было принято решение воспользоваться уже готовым решением — одной платной CMS. Сумма была уплачена, CMS развернули, начали лить туда товары, но тут возникла дилемма: эта CMS работает только с грубой структурой товаров и с ограниченным набором параметров во время загрузки. Стало очевидно, что нам необходимо переписывать загрузчик товаров в базу. Уже была дана отмашка, чтобы я начинал писать, но возникла идея протестировать эту CMS на стрессоустойчивость — посмотреть, как она будет работать на базе с 100 тысячами товаров. CMS себя проявила с худшей стороны, и стало понятно, что пришло время отказываться от нее и что необходимо вообще всё писать своими силами.
Отсюда один из главных выводов по разработке подобных магазинов: НИКОГДА НЕ ПОЛЬЗУЙТЕСЬ ГОТОВЫМИ РЕШЕНИЯМИ!
Вопрос о том, что лучше использовать для разработки подобных проектов, я поднял в уютном чате сообщества MODX в Беларуси. В процессе обсуждения мы пришли к мнению, что необходимо использовать NoSQL-базу для хранения товаров и их параметров. Послом MODX в Беларуси Иваном Климчуком Alroniks было предложено решение, используемое во многих проектах, а именно Redis. Изучив эту систему, я столкнулся с одной из проблем, а именно: отсутствие удобного способа получения данных для фильтра — хотя, возможно, я плохо изучил вопрос. И после этого внезапно мне подсунули под нос такую вещь как ElasticSearch — о том, что это за зверь, я и решил написать цикл статей, в которых будут описаны общие принципы, т.е. чисто PHP и запросы к ElasticSearch, но, возможно, будут и некоторые особенности, т.к. я использовал REVO-ветку.

Краткое описание последующего цикла статей
Я опишу этот цикл с точки зрения использования его для создания Интернет-магазина.

1. ElasticSearch — формирование базы товаров и общая информация по ElasticSearch (установка, настройка).
1. Общая архитектура.
2. Параметры и типы параметров.
3. Прочее.
2. Тонкости в формировании и парсинге файлов XML/CSV.
1. Пример структуры файлов на CSV и ее разбор для записи в ElasticSearch.
2. Пример структуры файла XML и его разбор для записи в ElasticSearch.
3. Мои личные наработки для разбора больших файлов.
3. ElasticSearch — выборка необходимых параметров товара.
1. Выбираем все параметры для формирования фильтров.
2. Выбираем необходимые параметры.
3. Сортировка товаров и прочие обобщённые операции.
4. Формирование категорий товаров на основе MODX и Wayfinder. Тонкости работы с многоуровневым каталогом.
1. Пример моего опыта использования Ресурсов для формирования каталога.
2. Особенности многоуровневого древа документов.
3. Решение проблем многоуровневого древа.
5. ElasticSearch — формирование поиска по всей базе.
6. Хранение заказов на базе ElasticSearch, обновление/удаление. Подведение общего итога.
7. Возможная статья: Особенность создания гибкого магазина с неограниченным количеством параметров.

p.s. Время написания последующих статей будет варьироваться от 7 до 10 дней, т.к. именно в данный момент происходит сдача в эксплуатацию этого сайта.