Недавно мне было поручено разработать некое веб-приложение. Не буду вдаваться в подробности, а лишь скажу, что приложение связанно с планированием перевозок. Есть общедоступная часть, воспользоваться которой может любой посетитель сайта. Есть внутренние интерфейсы для операторов системы. Есть информеры для размещения на сторонних сайтах. С технической точки зрения это несколько десятков экранов, множество различных форм, табличек. Часть экранов используют ajax, кастомные компоненты, написанные на javascript, и всякие красивости типа drag-and-drop. Данные, как обычно, хранятся в реляционной БД в виде полутора десятков таблиц. В общем не совсем примитивное приложение, но и очень сложным назвать его тоже не могу.

По работе мне, мне достаточно часто приходится проектировать или лично кодить подобные приложения. Однако в данном проекте было одно важное требование. Приложение должно быть разработано на базе серьезной и проверенной платформе, а именно на Zend Framework. Использование самописных “велосипедов” — недопустимо. Скажу честно, опыта реальной работы с Zend Framework у меня до сих пор не было. Но платформа известная и за ней стоит известный разработчик. Многими разработчиками Zend Framework вообще рассматривается как стандарт веб разработки. Так что, тем более, есть повод освоить что то новое и солидное. Поэтому я с энтузиазмом взялся за этот проект.

Далее пойдет описание моих личных эмоций и впечатлений, поэтому, возможно, не стоит их воспринимать слишком близко. Это именно некий эмоциональный остаток, оставшийся после завершения работы над проектом. Zend Framework в коммерческом проекте был использован мной впервые.
Читать дальше →

Из-за того, что приходится использовать различные фреймворки, но писать, по сути, одно и то же рано или поздно начинает преследовать дежавю. Для php это особенно актуально, часто приходится как выбирать платформу под заказчика, так и допиливать уже имеющийся проект. Вроде бы, нет ничего проще — написал один раз код и таскай его за собой. Но различные API и организация файлов не дают это сделать естественным образом. Очевидное решение — организация своего «багажа» в виде классов. Тогда конкретное приложение (модуль, компонент) как раз будут связывать API фреймворка (или CMS) с вашим классом. Проблема организации файлов имеет также вроде бы очевидное решение — инклудишь нужный класс и всё. Но не зря же все активно пользуются различными фреймворками, а не пишут все с нуля — лучше сосредоточиться на новых задачах, а не думать как «подцепить» уже готовое. Посему я и написал небольшой класс, фабрику-загрузчик.
Читать дальше →

В этой статье я расскажу о некоторых новшествах, появившихся в проекте AMatch с момента написания первой статьи.

Напомню, что AMatch — класс, с помощью которого валидация входных параметров из большого набора if-ов превращается в удобную, лаконичную запись. К примеру:

Example: simple

$match = AMatch::runMatch($params)
	->doc_id(0, '<') // Левое значение меньше
	->subject_id(0, '!=') // Не равен нулю
;
$result = $match->stopMatch();
if (!$result) {
	die(var_export($match->matchComments(), true)); // для наглядности умрём
}

Новые возможности под катом

Товарищи! Эта статья не для high-high-highload систем. Скорость работы представленных решений определённо меньше простейших проверок. На многотысячных или очень глубоких структурах применять предлагаемый подход крайне не рекомендуется. В этом топике побеждает быстрое кодирование, а не быстрый код.

Без длинных

Давайте без длинных вступлений, но всё же с предысторией. Однажды в рамках создания очередного очень важного компонента веб-сервиса нам понадобилось проверять уйму очень разных входных параметров (в данном случае, пришедших через $_REQUEST). Компонент был очень сложный, внутренняя и внешняя логика вызывала ежедневный баттхёрт между всеми участниками, а отдуваться приходилась немногим «избранным» программистам, которые писали, переписывали, выпиливали и запиливали заново. Когда на вход в систему с фронтенда падают десятки разных переменных, в том числе массивов, программисты при этом делают перекрёстные задачи (меняя логику) и мешают друг другу — код очень быстро разрастается, количество цепочек if-ов начинает занимать не одну страницу. Возвращаться к такому коду всё более и более чуждо ранимой душе. Тесты уже не очень помогают, т. к. каждое изменение логики приводит к изменению тех же тестов, в которых ещё надо вспомнить, понять и простить. Вот тогда и встал вопрос о создании удобного способа проверять весь входной поток каким-то приятным глазу способом, да чтоб всегда и везде получать фидбек про ошибки в однотипном виде. Акцент тут изначально стоял именно на удобстве для разработчиков, строго прошу в дальнейшем иметь.
Дальше много php

Вдохновившись статьей Еще раз о каррировании и частичном применении в PHP, в голову пришла реализация частичного применения метода, именно метода, а не функции.
Каррируем!