Начинающим: удобный инструмент для верстки, создание и понимание работы плагинов в MODx.

Sass — правильный CSS

Многое (если не всё), чего не хватало старому доброму CSS (вплоть до CSS3), реализовано в расширенном формате написания каскадных таблиц стилей — Sass. Не зря приверженцы Ruby on Rails (откуда берет корни Sass) ласково называют его «синтаксический сахар».

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

Не отстаем от тенденций современности

Для тех, кто программирует на PHP в условиях CMS MODx, предлагается создать плагин, который будет следить за наличием и изменениями в sass-файлах и автоматически (ре)генерировать соответствующие css-файлы, подключаемые в шаблоне.

Введение

Странно, но поискав на Хабре упоминания текстового редактора Sublime Text 2 я почти ничего не нашел. Спешу исправить положение и рассказать хабраюзерам об этом прекрасном инструменте. Вначале очень коротко расскажу о том чем же он так хорош, потом напишем простой но полезный плагин.

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

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

Как и у всех программистов, недавно у меня возникло желание изобрести собственный “велосипед”. Так как изобретать свою CMS, Framework, и т.д. уже не актуально, то мой взор обратился на каптчу. Казалось бы, что тут можно придумать оригинального, каких только каптч не существует: 2D-картинка, 3D-картинка, звуковая каптча, выбор “правильной” картинки. Но мне пришла в голову мысль, что создатели каптч думают как-то однобоко, то есть все хотят получить однозначно правильный ответ от пользователя (и обычно в тестовом поле), причем в простом виде, серверу лишь остается сравнить ответ с исходными данными! Вот я и решил исправить это дело и создать собственную “умную” каптчу.

Vala — это язык программирования, который создавался как замена языка C при разработке приложений для Gnome. При этом язык на мой взгляд удался, в своем синтаксисе взял многое из C# и Java. Прочитать подробнее о нем можно на Хабре или сайте Gnome. Захотев попробовать этот проект в деле столкнулся с тем, что по текущий момент для него не существует качественного IDE или плагина для IDE, которая позволила бы комфортно на нем разрабатывать.

В результате был создан плагин для NetBeans IDE, которая на мой взгляд является одной из лучших open source IDE (наряду с Eclipse). Тем не менее информация о том, как именно разрабатывать модули и плагины для NetBeans Plaform довольно разрознена, а на русском языке практически ничего нет.

Статья посвящена плагину, который упрощающает жизнь client-side программиста.

При заполнении формы случается так, что учитывая введенные данные, форму нужно менять (прятать и показывать поля). Простейший пример: при заказе доставки товара пользователь выбрал «самовывоз», значит поля про адрес доставки можно спрятать, зато было бы здорово показать карту проезда для самовывоза.

И что дальше

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

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

Второй подход это писать «портянки» javascript'а который всю эту логику реализует на стороне клиента. Особенно грустно писать «каскадную» логику типа «если ввели a в поле A, показать B, если ввели c в поле B, то показать D. Если в A ввели что-то другое, спрятать B, а потом D».

Оба варианта нельзя назвать удобными. Прежде всего потому что логика реализуется императивным стилем вместо уместного для таких случаев декларативного. Но выход есть!