После прочтения вот этого поста: Убираем дублирование при добавлении роутинга, понял что эта проблема волнует не только меня. Хочу поделиться своими соображениями на этот счет.

Linch правильно заметил, что при добавлении нового роута приходиться дублировать информацию. Но, на самом деле здесь происходит более «серьезное» дублирование, чем копипаст из config/config.route.php в Viewer.class.php — мы дублируем функционал по составлению пути — один раз это делает программист, разрабатывая модуль, второй раз это делает верстальщик, когда делает шаблон. Большее неудобство не в том, как мы доставим константу во Viewer, а именно в том факте, что верстальщику этими константами нужно пользоваться.

Если нам вдруг понадобиться изменить принцип роутинга, то придется перелапачивать весь шаблон, исправляя ошибки адресов. Имхо, если Router, решает какой Action должен отработать, пусть сам нам скажет, как к этому Action нужно обратиться. Тогда необходимость в константах во Viewer`e вообще отпадет сама собой.

Как этого добиться? Под катом 20 строчек кода.

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

Уверен, из названия топика ясно чем мы будем заниматься. Для того, чтобы цель выглядела «материальнее»:

Скриншоты:
Автосохранение запрещено

Автосохранение разрешено

Сообщение об успешности или ошибке — стандартный Notice в правом верхнем углу.
Реализация.


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

Иногда бывает полезно выполнить на статической странице PHP код (различные сервисы, mini-tools, и т.д.). В WordPress для этого есть специальный плагин, а для полюбившегося LiveStreet сделал так:

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

Этот пост — совет/подсказка разработчикам, которые трудятся над модулями во имя развития проекта :)

Суть проблемы.

Работая над модулем «Объявления» я столкнулся с необходимостью сделать достаточно сложный запрос к базе данных. Сложный не в плане SQL, а в том, что мы заранее не знаем каким он получиться. Такая ситуация возникла при создании пользовательского фильтра.

Технически задача заключается в следующем — есть три таблицы: объявления, категории объявлений — отсюда мы получаем название категории, пользователи — отсюда мы «дергаем» логин пользователя. Необходимо реализовать выборку по следующим условиям:
— категория или массив категорий (дочерние),
— ID пользователя или логин,
— статус (опубликовано или нет — для администратора),
— актуально объявление или нет,
— минимальная и/или максимальная цена,
— есть привилегии или нет,
Учесть при этом составную сортировку (по одному или двум полям), а также не забывать, что результат фильтрации нужно показывать с разбивкой на страницы. Сложности в это все добавляет то, что логин пользователя тянется из другой таблицы, поэтому необходимо использовать HAVING, а не WHERE.

Решение проблемы.

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

Описание проблемы.

Создавая новый модуль или экшн, очень часто прибегаю к использованию сообщений Message_AddNotice() и Message_AddError(). Штука очень симпатичная и удобная. Но. Всегда есть одно но. И заключается оно в том, что модуль выводит сообщения только на «текущей» странице. Если же где-то в экшене выполняется редирект, то наше сообщение теряется.

Почему это неудобно? Давайте посмотрим конкретный пример. Я разрабатываю модуль «Гараж». По адресу /garage/user_login можно увидеть список машин пользователя, если просматривающий пользователь = текущему авторизированному, то у каждого автомобиля есть ссылка «Удалить». Эта ссылка указывает на /garage/user_login/del/car_id, где происходит обработка удаления. За это отвечает EventDeleteCar() и именно здесь удобно сказать пользователю «Парень, твоя машина успешно удалена», ну или «Сорри, не получается». Для этого используем стандартное Message_AddNotice(), Message_AddError().

Но, мы не можем оставить пользователя на этой страничке, и в конце реализации event`а перекидываем его назад к списку с помощью func_header_location(). И все. Никакого сообщения пользователь не увидит!

Идея решения.

В Zend Framework есть action-плагин FlashMessenger, который для тех же целей использует сессию. Мы поступим аналогично.


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