YiiFramework Числовые поля в БД

  • Автор темы Автор темы Vano
  • Дата начала Дата начала
Насколько помню, всё пошло от того, что не подошёл FILTER_VALIDATE_EMAIL потому как полный эквивалент ему в JavaScript выглядел слишком уж жутко. Попробую приспособить ещё раз...
 
Валидация на регекспах, в фильтр можно передать тот же регексп, что и сейчас в yii, работает оно одинаково.

Интересно написать компилятор правил, чтобы из кучи валидаторов создавать один набор правил. Попробую.
 
Последнее редактирование:
Погонял ради интереса FILTER_VALIDATE_REGEXP и preg_match на тему прожорливости по памяти и быстродействия. Эквивалентны целиком и полностью. Разве что у filter_var для регекспов синтаксис дурацкий.
 
я не предлагал filter_var с регулярками - их эквивалентность очевидна,
я говорю про filter_var_array() - один вызов для всех полей, с приведением к INT по FILTER_VALIDATE_INT
 
я приведения не замечаю потому что у меня основная бизнес-логика в собственных моделях с plain sql или query builder, а ActiveRecord - в основном в роли DbTableGateway

В контексте еще и твоих высказываний в других темах я теперь вообще не понимаю, что ты из Yii используешь. :) Получается, что только базовый уровень бутстрап-роутинг-контроллер-конфиги? А не проще тогда Symfony Appkernel взять? =)
 
А я не основной разработчик, я пишу только ключевые участки, по объему кода в основном все пишется на ActiveRecord, это экономически оправдано.
Например, я написал вывод каталога, посадочные страницы, но неважно как отработает пополнение счета через аггрегатор и админка, лишь бы без ошибок.
У меня авгиевы конюшни legacy, которые я уже почти разгреб.
А роутинг у меня, наоборот, хакнутый. У меня 70% трафика на /, пройти через десяток объектов и рефлексию чтобы проверить какие параметры принимает контроллер при GET-запросе к / для меня overkill.
 
Последнее редактирование:
А, я думал ты не про лично себя, а про вообще весь проект. Тада ясно.

У меня 70% трафика на /, пройти через десяток объектов и рефлексию чтобы проверить какие параметры принимает контроллер при GET-запросе к / для меня overkill.

Ой, что, все так плохо? Я думал, сначала матчится роут, а рефлексия уже только когда известен controller и action, чтобы передать параметры. В laravel-е, по крайней мере, так.
 
А роутинг у меня, наоборот, хакнутый. У меня 70% трафика на /, пройти через десяток объектов и рефлексию чтобы проверить какие параметры принимает контроллер при GET-запросе к / для меня overkill.
Нужно смачнее рассказывать: «сотни объектов», «тяжёлая рефлексия», «десятки аргументов контроллера», «экономия – миллионы долларов» и т.д.
 
я приведения не замечаю потому что у меня основная бизнес-логика в собственных моделях с plain sql или query builder, а ActiveRecord - в основном в роли DbTableGateway
Кстати, тут напрашивается DataMapper по типу Analogue, только для Yii, удобнее будет, и почти ничего не изменится в остальном коде. Можно даже сделать, чтобы ClassName::model() отдавал репозиторий, хи-хи.

Analogue оказался несколько недоделанный, пришлось форкнуть, чтобы пофиксить багодром и UnitOfWork запилить. Пока, правда, костылями, выкладывать такое стыдно :)
 
Последнее редактирование:
Ой, что, все так плохо? Я думал, сначала матчится роут, а рефлексия уже только когда известен controller и action, чтобы передать параметры. В laravel-е, по крайней мере, так.
Конечно не всё так плохо :)
Не плохо, все так же - создали controller и action, рефлексией посмотрели на список аргументов, проверили, фильтр, колбеки, события, исполнение.

Нужно смачнее рассказывать: «сотни объектов»
а потом космические корабли бороздят просторы :)

стандартно:
создал Request, передал в UrlManager, сгенерилось 35 объектов правил, по циклу выполняю правила пока не найду controller/action, распарсил закодированный роут, распарсил параметры роута, создал контроллер, создал объект для action (для метода класса тоже), вызвал колбек before, еще один колбек, рефлексия, проверка фильтров, запуск исполнения объекта Action.

Выполнение правил по циклу, парсинг route-а и параметров, объект action, рефлексию и колбеки я выбросил для одного адреса, на который приходится до 70% запросов к приложению, и где мне это точно не нужно.
5 строк:
PHP:
public function processRequest() {
  if ($_SERVER['REQUEST_URI'] === '/') {
    $controller = new \desktop\FlatCatalogAuctionController('flatCatalogAuction',$this);
    $this->setController($controller);
    $controller->init();
    $controller->actionIndex();
 
Последнее редактирование:
grigori, кстати я тут приложение накидал, использовал action как сервисы, очень удобно и быстро получается, в твоем случае как раз может получится проще архитектура и все будет шустрее работать.
Фабиен слегка не прав в http://symfony.com/doc/current/cookbook/controller/service.html
Ибо лучше делать экшены сервисом.

Можно в роутере заговнокодить вызов экшен-сервиса через сервис локатор (Yii::app()), минуя поиск контроллера и рефликсию.
Сейчас с php 5.5 SL первого Yii, можно построить на анонимках.

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

Можно в роутере заговнокодить вызов экшен-сервиса через сервис локатор (Yii::app()), минуя поиск контроллера и рефликсию.
Сейчас с php 5.5 SL первого Yii, можно построить на анонимках.
экшен сделать компонентом yii?
Я так понимаю, первый Yii компоненты на анонимках не поддерживает, это надо дописывать.

Думаю, что вызывать контроллер из роутера неправильно, контроллер надо дергать из приложения. Роутер может сказать приложению, что рефлексию делать не надо, но ее делает не приложение. Для запуска контроллера объект приложения вызывает один метод, которого хватит для всех - Controller->run(), и уже контроллер делает рефлексию самого себя, колбеки и прочую хрень. Вероятно, надо научить приложение вместо парсинга роута и вызова controller->run() просто отдавал управление компоненту.
Идея, в принципе, хорошая.
@Sam Dark , сделайте такое в 2ке?
 
Последнее редактирование:
я так понимаю, проблему раздутых или разнесенных в непонятные места конфигов SL никто не решил толком
 
Охренеть у вас сложности. В Symfony HttpKernel это решается всего лишь одним listener'ом KernelsEvents::REQUEST. Только толку от таких оптимизаций.
 
Охренеть у вас сложности. В Symfony HttpKernel это решается всего лишь одним listener'ом KernelsEvents::REQUEST. Только толку от таких оптимизаций.
0_о в симфони это решается
Код:
hello_world:
  path: /
  defaults: { _controller: hello_app.action.hello:run }
зачем усложняешь?
 
0_о в симфони это решается
Код:
hello_world:
  path: /
  defaults: { _controller: hello_app.action.hello:run }
зачем усложняешь?
Имеется в виду, чтобы до роутера дело не доходило. К тому же HttpKernel более общая штука, которую некоторые юзают и без full-stack Symfony. :)
 
Сверху