я вот закончил бакалавра по направлению «Филология» специальности «Перевод: Английский и Украинский», хочу продолжить науку заочно в магистратуре по специальности «Прикладная лингвистика», а пока поработаю в качестве php architect…
о, можете показать какой-то gateway и mapper для mongodb? также на entity для етого.
на использование acl внутри сервиса тоже интересно взгянуть б (интересно как, вот).
а для распределения нагрузки gearman были идеи использовать?
для redis вродь наиболее оптимальным решением сейчас есть libredis с поддержкой ketama, нескольких серверов и batch-запросов. или есть какие-нить другие идеи?
в своем примере я показал как сделать ето только с использованием reflection. до написания тестов на производительность пока не доходили руки. вечером может как-то добавлю. вопросов с производительностю на момент написания не возникало. ето как раз тот случай, где она неважна.
о, спасибо, за введение в @internals не знал.
а оправдано ли? все относительно: если таких вызовов немного — очень удобно и расширяемо, если их очень много (вродь как в Magento) — за производительность все прекрасно знаем (правда еще не вникал какой оверхед именно от етой возможности там). тоесть ету возможность не стоит пихать повсеместно, а только там, где даст много удобства в разработке и других полезных вещей.
в одних местах — возможно, в конкретно моем случае — нет.
еще одно распостраненное использование — движок лей-аутов в етом нисколько не ведомом продукте: для подключения внешних css и js файлов, та и для других целей в описании шаблона там используеться именно метод такого типа.
а для какой цели вам нужно было получать список public методов? get_class_methods() не подходил? или использовать php-tokenizer для разбора и обернуть его кешированием в файл типа <?php return array( ... );?
Для одного проекта занимался паралельной обработкой 200к записей. Работа с несколькими АРІ одновременно. Были свои подводные камни. Построение на основе Dependency Injection не раз спасало. Может как-то написать об етом топик.
особенно удобно работать с формами, когда есть своя библиотека декораторов — гибкость достигается путем визова одних декораторов из других ($this->getElement()->getDecorator('name')); если правильно подойти к делу — можно одной лиш заменой базового класа форм слелать из простой — многошаговую. загрузка файлов тоже интересна (например, можно сделать, чтоб большой мп3 файл оставался на сервере и привязанним к форме даже если в других полях есть ошибки); для разработки форм совет — держать набори полей разного назначения в разних класах (например, Form_User, Form_UserLogin), поскольну введение свойства идентификатора групи полей иногда накладно (но гибко))). при таком проектировании можно добится гибкости, если нужна валидация посложнее, нежели та, что предлагается через методи addValidators (нужно просто дополнить метод isValid()).
может на ету тему и заметку напишу (паралельно с кодогенерацией для zend_framework)
на использование acl внутри сервиса тоже интересно взгянуть б (интересно как, вот).
а для распределения нагрузки gearman были идеи использовать?
для redis вродь наиболее оптимальным решением сейчас есть libredis с поддержкой ketama, нескольких серверов и batch-запросов. или есть какие-нить другие идеи?
а оправдано ли? все относительно: если таких вызовов немного — очень удобно и расширяемо, если их очень много (вродь как в Magento) — за производительность все прекрасно знаем (правда еще не вникал какой оверхед именно от етой возможности там). тоесть ету возможность не стоит пихать повсеместно, а только там, где даст много удобства в разработке и других полезных вещей.
еще одно распостраненное использование — движок лей-аутов в етом нисколько не ведомом продукте: для подключения внешних css и js файлов, та и для других целей в описании шаблона там используеться именно метод такого типа.
а для какой цели вам нужно было получать список public методов? get_class_methods() не подходил? или использовать php-tokenizer для разбора и обернуть его кешированием в файл типа
<?php return array( ... );?советую брать из большей плотностю. дизайнов — море, под любую текстуру можно найти.
www.zend.com разработан создателями Magento.
может на ету тему и заметку напишу (паралельно с кодогенерацией для zend_framework)