Старт грамотной разработки под MODX
Всем привет!
Хоть с MODX знаком с незапамятных времен и сделано на нем много сайтов, до сего момента серьезной разработкой под него не заморачивался (так, велосипедил и говнокодил, если была сильная нужда). Сейчас хочется разобраться в вопросе серьезно.
Какие использовать инструменты для разработки? Как связать IDE и MODX, чтобы среда разработки понимала, что это за ересь я там пишу и что за такие объекты использую? Как отлавливать баги? Как просматривать результат своего труда?
Расскажите пожалуйста, какие конфигурации вы используете в работе.
Всем заранее спасибо!
Хоть с MODX знаком с незапамятных времен и сделано на нем много сайтов, до сего момента серьезной разработкой под него не заморачивался (так, велосипедил и говнокодил, если была сильная нужда). Сейчас хочется разобраться в вопросе серьезно.
Какие использовать инструменты для разработки? Как связать IDE и MODX, чтобы среда разработки понимала, что это за ересь я там пишу и что за такие объекты использую? Как отлавливать баги? Как просматривать результат своего труда?
Расскажите пожалуйста, какие конфигурации вы используете в работе.
Всем заранее спасибо!
Комментарии: 15
О, спасибо!
Как-то пропустил эту информацию у Василия! Будем почитать :)
Как-то пропустил эту информацию у Василия! Будем почитать :)
Начало разработки — за пределами MODX. Вёрстка (БЭМ) шаблонов, чанков и страниц в Sublime Text 3 с использованием Gulp-задач для автокомпиляции с использованием пре- и постпроцессоров (ускоряют разработку в 4-5 раз), зависимости: bower, для UI-тестов адаптивности: BrowserSync. Минификация стилей и скриптов на клиенте (прекратите вешать эту задачу на MinifyX/сервер!). Кодстайл: CSScomb и JSCS + JSLint. В дальнейшем можно настроить автоматическую выгрузку по SFTP скомпилированных файлов прямо на сервер. Шаблонизация на клиенте легко настраивается с помощью gulp-rigger, gulp-file-include или gulp-include-source. За счет вотчеров скорость просто реактивная. Особенно удобно, если монитора два и больше — в одном мониторе код проекта, в остальных — мгновенный результат (страница обновляется быстрее, чем я успеваю перевести взгляд с одного монитора на другой или переключиться на новый раб. стол).
Инициализация сервера: ansible, установка MODX: Gitify, импорт настроек: Teleport. Импорт уже подготовленных чанков, tpl-ек занимает минуты, нет необходимости заниматься «клавадрочерством» с Ctrl+Tab (переключиться на фронтенд-вкладку), Ctrl/Cmd+R (обновить страницу), чтобы просмотреть результат — всё уже оттестированно на этапе вёрстки. Остаётся только настроить магию сниппетов и оформить Custom Forms. Дальше — оверлокинг с XDebug, debugParser, BloodLine и Chrome DevTools.
Инициализация сервера: ansible, установка MODX: Gitify, импорт настроек: Teleport. Импорт уже подготовленных чанков, tpl-ек занимает минуты, нет необходимости заниматься «клавадрочерством» с Ctrl+Tab (переключиться на фронтенд-вкладку), Ctrl/Cmd+R (обновить страницу), чтобы просмотреть результат — всё уже оттестированно на этапе вёрстки. Остаётся только настроить магию сниппетов и оформить Custom Forms. Дальше — оверлокинг с XDebug, debugParser, BloodLine и Chrome DevTools.
Вот это ответ! Спасибо за исчерпывающее разъяснение! :)
В общем-то, я спрашивал больше про написание компонентов, меня интересует, как сама разработка этих компонентов происходит.
Ну вот сижу я, скажем, за компом с 7 виндой. И как далее нужно все организовать, чтобы процесс разработки был комфортным? Я до этого всерьез программировал только на C# под MS SharePoint, там есть несколько неуклюжий, но вполне работоспособный процесс разработки, который очень неплохо интегрирует VisualStudio и сам SP (включая внушительные инструменты дебага, которые позволяют отслеживать реакцию чуть ли не на каждую строчку кода). Пишем код, потом одной комбинацией клавиш компилируем/копируем/устанавливаем решение на сервер SP, потом стоит только открыть нужную страницу — и там все уже есть. Гибкость этой процедуры позволяет внутри VisalStudio написать целый огромный портал, причем вместе со страницами, файлами, данными, связями и прочим. И потом всего одной строчкой в консоли всю эту красоту развернуть на девственно чистую инсталляцию SP, и все уже будет работать.
Понятно, что я не жду такого же функционала здесь, все таки MS — суровый пром, там свои задачи и своих недостатков хватает, но, собственно, меня интересует, как бы так интегрировать IDE с MODX, чтобы сама IDE понимала, что есть MODX и у него есть свои свои классы для работы с данными и самой CMS, что есть некоторые системные события и прочее.
До сего момента я писал код примерно так:
1. Пишу код прямо в окошке нового сниппета MODX;
2. Чертыхаясь, вспоминаю, что нужно писать на PHP, все написанное переписываю;
3. Обнаруживаю, что написанное не работает;
4. Начинаю отлаживать построчно, время от времени выводя прямо в текст страницы, где вызывается сниппет, содержимое нужных объектов или переменных;
5. Собственно, получается сниппет из 10 строк, на который было потрачено 3 часа.
Вот это как-то хочется оптимизировать. Чтобы редактор был с подсказками (PHPStorm? PhpED?), чтобы не приходилось из этого редактора код копировать вручную в окошко сниппета в админке modx, а потом вручную смотреть, что получилось, обновляя страницу, где вызывается сниппет.
В общем-то, я спрашивал больше про написание компонентов, меня интересует, как сама разработка этих компонентов происходит.
Ну вот сижу я, скажем, за компом с 7 виндой. И как далее нужно все организовать, чтобы процесс разработки был комфортным? Я до этого всерьез программировал только на C# под MS SharePoint, там есть несколько неуклюжий, но вполне работоспособный процесс разработки, который очень неплохо интегрирует VisualStudio и сам SP (включая внушительные инструменты дебага, которые позволяют отслеживать реакцию чуть ли не на каждую строчку кода). Пишем код, потом одной комбинацией клавиш компилируем/копируем/устанавливаем решение на сервер SP, потом стоит только открыть нужную страницу — и там все уже есть. Гибкость этой процедуры позволяет внутри VisalStudio написать целый огромный портал, причем вместе со страницами, файлами, данными, связями и прочим. И потом всего одной строчкой в консоли всю эту красоту развернуть на девственно чистую инсталляцию SP, и все уже будет работать.
Понятно, что я не жду такого же функционала здесь, все таки MS — суровый пром, там свои задачи и своих недостатков хватает, но, собственно, меня интересует, как бы так интегрировать IDE с MODX, чтобы сама IDE понимала, что есть MODX и у него есть свои свои классы для работы с данными и самой CMS, что есть некоторые системные события и прочее.
До сего момента я писал код примерно так:
1. Пишу код прямо в окошке нового сниппета MODX;
2. Чертыхаясь, вспоминаю, что нужно писать на PHP, все написанное переписываю;
3. Обнаруживаю, что написанное не работает;
4. Начинаю отлаживать построчно, время от времени выводя прямо в текст страницы, где вызывается сниппет, содержимое нужных объектов или переменных;
5. Собственно, получается сниппет из 10 строк, на который было потрачено 3 часа.
Вот это как-то хочется оптимизировать. Чтобы редактор был с подсказками (PHPStorm? PhpED?), чтобы не приходилось из этого редактора код копировать вручную в окошко сниппета в админке modx, а потом вручную смотреть, что получилось, обновляя страницу, где вызывается сниппет.
В общем-то, как я вижу, ответы на большинство моих вопросов есть в курсе Василия по разработке компонента. Там же и про IDE и про остальное :)
Но и за подробное объяснение о процессе разработке также большое спасибо, всегда было интересно, как организована работа с gulp и прочими инструментами, но все руки никак не доходили поковыряться как следует и разобраться.
Но и за подробное объяснение о процессе разработке также большое спасибо, всегда было интересно, как организована работа с gulp и прочими инструментами, но все руки никак не доходили поковыряться как следует и разобраться.
Для разработки компонента — PHPStorm. Лучше наверное и нет. Проект создается для компонента, рабочая папка с modx подключается как зависимость в настройках шторма. После индексации он умеет автодополнение и переходы вверх/вниз по наследуемым классам. Не все и не всегда работает идеально, так как в MODX нет автолоадинга и других удобных плюшек (код еще для версии 5.2 писался), но работать можно.
Что касается сниппетов — то писать их через IDE можно, но нужен еще доп. шаг, чтобы их синхронизировать. Так как элементы представлены как объекты xPDO, то они мапятся в БД, а значит нужно как-то связывать код в файле и поле в БД. В самой системе есть возможность указывать статический элемент или нет и указывать файл, где лежит содержимое. Работает нормально, но не для всех объектов. Я же использую Gitify, который умеет уже кучу всего. Но это к разработке компонента не относится.
Что касается сниппетов — то писать их через IDE можно, но нужен еще доп. шаг, чтобы их синхронизировать. Так как элементы представлены как объекты xPDO, то они мапятся в БД, а значит нужно как-то связывать код в файле и поле в БД. В самой системе есть возможность указывать статический элемент или нет и указывать файл, где лежит содержимое. Работает нормально, но не для всех объектов. Я же использую Gitify, который умеет уже кучу всего. Но это к разработке компонента не относится.
Вань вот насчет Gitify написал бы статью как, что, зачем… Интересно очень, думаю не только мне.
Спасибо!
Спасибо!
Перед отпуском такой завал, что поесть особо некогда, не то что статью писать ) Но напишу, материала уже много, воркфлоу обкатан, примеры есть :) Или в отпуске напишу или уже после будет.
жду с нетерпением!)
Подписываюсь — Gitify выглядит интересно, но разбираться, настраивать и обкатывать — времени не хватает. С удовольствием прочёл бы ваш подход)
Здравствуйте! А какой смысл минифицировать скрипты и стили на клиенте?
Если сервер (и браузер) не настроен на работу по HTTP/2 или Spdy, то каждый файл увеличивает общее время загрузки (и дальнейшего рендера, соответственно). Общая конкатенация позволяет продуктивнее использовать gzip за счёт общего анализа.
Таки да, понимаю, совершенно согласен.
Но вы написали:
И вот тут уже не понимаю. Ведь в этом случае клиент перед минификацией в браузере все равно загрузит исходные скрипты и стили по отдельности, потратив время на запросы + лишний трафик.
Но вы написали:
Минификация стилей и скриптов на клиенте (прекратите вешать эту задачу на MinifyX/сервер!)
И вот тут уже не понимаю. Ведь в этом случае клиент перед минификацией в браузере все равно загрузит исходные скрипты и стили по отдельности, потратив время на запросы + лишний трафик.
«Клиент» в этом случае — компьютер разработчика. Стили и скрипты правятся на этом «клиенте», не проблема сразу настроить и их правильную „сборку“, чтобы не делегировать их серверу.
Комментарий сохранил, заскринил, распечатал. Это вот подход!!!
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.