В прошлой статье я рассматривал один из способов быстрого доступа к переводимым атрибутам. Для того что бы понять о чем вообще идет речь, настоятельно рекомендуется прочитать укзаную статью перед этой ) Для тех, кто уже читал, напомню, что основной цимес состоял в искусственных гетерах и сетерах через hasAccessorMutator(), которые в свою очередь оверрайдились через __call()-функцию шаблона. Очевидный минус этого подхода это невозможность использовать __call() в других шаблонах, что не есть хорошо. Есть более красивый и эффективный способ реализовать такой доступ, причем он изначально был предусмотрен в Doctrine чуть ли не с самых первых версий — это фильтры атрибутов. И снова под катом много кода и текста.

Я думаю многие со мной согласны, что Doctrine — один из самых мощных и удобных ORM для PHP, но с недавнего времени возможностей оного мне перестало хватать. Начнем с того что невозможно использовать ассоциации с условиями фильтрации, «волшебный» поиск с учетом перевода через I18n и много другого.

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

Начну с самого легкого — с расширения для мультиязычности Doctrine_Template_I18n. Оговорюсь сразу, текста будет много, как и много сумбурной технической информации

 

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

• <$150 — новичек который пытается вытянуть халтурку. Как правило студент, как правило работу он не сделает. Почему? Потому что неясно представляет фронт предстоящих работ, согласование и кучу нюансов, потому и кинет это дело на полпути. Плюсы — сомнительные, минусы — потеря времени и нервов.
  
• $300-$400 за несложный проект — новичек поопытней, либо полу-профи. Работу делают, но томно и не спеша. Часто признаком является достаточно вальяжный график работ. Если время не горит — лучший вариант. Плюсы — в принципе дешево (по сравнению со студиями), минусы — долго.
  
• >~$1000. Тут сидят профики толковые люди, либо кидалы. С такими людьми надо заключать договор перед тем как делать проект, профи толковый — подпишет не задумываясь, кидала — убежит. Работа делается четко по графику и редко бывают серьезные задержки. Составляется ТЗ, пишут сопровождающую документацию и прочие свистоперделки. Как правило качество высокое и даже лучше чем в студиях за те же деньги. Плюсы — качество, сроки, ответственность. Минусы — риск нарваться на кидалу, относительно дорого.
  

Наблюдения сделаны исходя из опыта общения со «свободными программистами» и личной практики фриланса. Множитель к каждой ценовой категории увеличивается пропорционально приближению к Европе (США) по уровню жизни и к крупным городам. Цены в описании примерно соответствуют Минску, в Москве дороже в минимум 2 раза.

UPD: Судя по тому как упала моя карма, многим такой анализ не понравился. Под кат:

Случилось так, что осваивая Zend Framework я решил написать компонент Zend_ActiveRecord по функциональности как можно более похожий на Rails. Подобное предложение возникало на комьюнити зенда, но давно не обновлялось, да при этом требовало php 5.3 из-за его __callStatic(). Меня этот факт не устроил, но необходимость вызова динамических методов класса модели как статичных по прежнему остается очень актуальной темой, я же попробовал разобраться с этим как раз на примере моей собственной ActiveRecord для зенда