Как стать автором
Обновить

Комментарии 16

Демо станет доступно по следующим адресам: www.rock-validate/ или 192.168.33.35/


А на localhost не выложите?
Уже, выше.
Автор указывает адреса, доступные после разворачивания в виртуалке.
Оу, был невнимателен, как следствие — излишне саркастичен.
Измените на любой желаемый.

Когда только постигал мудрость разворачивания проектов в виртуалке, руководствовался сторонним vagrant-конфигом. С тех пор, как-то прижилось. Плюс позволяет избежать конфликта с остальными пет проектами поднятыми в виртуалке. Меняю лишь последний разряд. 192.168.0.0/16 — вроде ничего криминального.

P.S. Демо скорее в нагрузку, ибо практическая польза минимальна. Примеры представлены здесь и в документации исчерпывающие. Дополнительные зависимости/окружение, которые необходимо как-то особым образом «приготовить» — не требуются.
А с чем связан такой несколько нестандартный выбор способа инициализации правил валидации? В том плане, по примерам, что каждый метод, по сути, может быть вызван как статически для создания валидатора, так и физически на уже готовом валидаторе? Почему не некая единая точка инициализации?
  • сохранить элегантный синтаксис (сцепной принцип для правил);

Кроме «элегантности» такого подхода, сохранена совместимость, что даёт прозрачную возможность мигрировать. Можете посмотреть на аналогичную «магическую» инициализацию в Respect/Validation.
Почему не некая единая точка инициализации?

Легко. В примере с кастомизацией это видно. А именно:
// инициализация с дефолтными настройками
$v = (new Validate)->string()->email();
$v->validate(7); // output: false

$v->getErrors();
/*
output:
[
   'string' => 'value must be string',
   'email' => 'value must be valid',
]
*/

Давайте разнообразим задачу и предположим, что вы используйте некий DI контейнер:
[
    ...
    'validator' => function(){
        $config = [
            'locale' => 'ru' // по дефолту используем русский словарь
        ];

        return new Validate($config);
    },
    ...
]

Возможно, у Вас возникнет вопрос: Почему используется некий конфигурирущий массив с настройками?
Данная библиотека является standalone модулем моего фреймворка, т.е. используется независимо от него, как и многие другие модули. Инициализация в нём реализована таким образом. Подобную подход Вы могли видеть в yii2
НЛО прилетело и опубликовало эту надпись здесь
… это форк/переосмысление Yii 2.

Легенда была несколько иная. Всё началось с написания шаблонизатора, потом появилась некая «экосистема»/фреймворк. Далее, была попытка избавится от множества велосипедов. Плотная работа с Yii 1 и повышенный интерес к Yii 2 ещё в ранней альфе, сделали своё дело. До этого года полтора проработал с Symfony, но взаимности не вышло.

Фреймворк писался из академических соображений — бесценные опыт и знания. Скорее всего, он в таком статусе и останется. Ряд компонентов пусть даже с небольшими изменениями, являются всё же наследием Yii 2, а потому, неэтично как-то ангажировать последний.

чем отличается от Yii

  • Роутинг. Можно скормить конфиг с правилами, либо использовать методы, short-метод для создания набора REST-правил, поддержка Action Injection
  • DI. Возможность возвращать инстанс, как синглетон, service locator, Constructor Injection.
  • Шаблонизатор. Использует два движка: нативный php и свой доморощенный на regex-ах (сниппеты, чанки, плейсхолдеры, фильтры). Одновременно можно использовать оба. Изолированные скоупы для плейсхолдеров: $root.name, $parent.name и name соответствует плейсхолдеру/переменной рута, родителя и текущего скоупа), эскейпинг всего, кэширование. HtmlHelper перекачивал из Yii, а также некоторые виджеты. Тот же ActiveForm использует AngularJS на клиенте (в доработке).
  • Валидатор описанный в этом посте
  • Санитизатор
  • Кэширование: тегирование, autolock для конкурирующих запросов
  • Url builder
  • Datatime builder
  • Провайдер для изображений. Связка imagine + flysystem, позволяет хранить отредактированные изображение не только локально, но и на удалённых файловых хранилищах/облаке
  • Абстракция над реализацией markdown парсера от Карстена Брандта. Дополнил специальным синтаксисом для кропа изображений, добавление видео-тегов с возможность указать заглушку с ссылкой на видео (режим оптимизации), существует возможность ограничить набор используемых тегов
  • Абстракция над MQ сервисами
  • и многое другое

С недавних пор стал модульным, т.е. каждый компонент можно использовать независимо от фреймворка. Yii, к сожалению, таким не является, и неизвестно, будет ли. Тут, как говорится, на вкус и цвет.
И всё же, к примеру, если Вам нравится реализация AR модели в Yii 2 и при этом очень хочется только её одну где-нибудь задействовать, возможно, в другом фреймворке, то можете воспользоваться Rock DB (актуальна версии Yii2 2.0.3). Существует ряд отличий/дополнений: кэширование Rock Cache, Select Builder — помогает автоматизировать подбор полей при использовании JOIN-ов, иная система пагинации для ActiveDataProvider и ещё по мелочи. Аналогично это касается API/ORM для поискового движка Sphinx и ODM для MongoDB. Для хранения сессий в MongoDB задействован ttl-индекс и упразднён garbage collector. Всё никак не подготовлю PR, чтоб и в Yii это было + некоторые баги.
Всегда полезно покопаться в чужом белье коде. Благодаря моему взвозу в Yii DB наконец-то появился валидный UNION, но нет возможности задать ORDER BY/LIMIT для всех стейтментов в конце. У себя я это предусмотрел. В общем, всех нюансов сразу так и не вспомнить.

Повторюсь, у меня нет планов писать обзорные статьи по фреймворку и по тем компонентам, где мой вклад минимален.
А Rock Validate вы планируете поддерживать и развивать? Не хотелось бы оказаться в ситуации, когда куча кода завязана на компонент, который автор уже не развивает.
Я всё буду поддерживать, ибо львиная доля компонентов/библиотек задействована в проектах компании. С радостью готов принять feedback.
github.com/romeOz/rock-validate/blob/master/src/rules/Required.php

Мне кажется, или вы собрали те же грабли, что и Respect/Validation? По поводу этого !empty() столько непоняток. Как, например, без костылей валидировать 0 и 1?
По поводу этого !empty() столько непоняток.

Спасибо, что заметили. Добавил выбор режима ($strict). По умолчанию он строгий ($strict = true). В нестрогом режиме, это: '' и null.

Validate::required(false)->validate(0); // output: true

Validate::required(false)->validate(''); // output: false
Вот так лучше
1. Мне совершенно непонятен вывод стека ошибок через древо exceptions. Если такая возможность кому-то необходима, то несложно абстрагироваться от \rock\validate\Validate с добавлением соответствующих методов, которые, в свою очередь, будут дёргать getErrors() и выбрасывать exceptions.

2. Логика у Respect/Validation слишком «накручена» — глубокий уровень наследования (жучка за внучку, внучка за бабку, ...). В моей реализации:
  • У Validate вообще отсутствует наследование. При использовании атрибутов задействован класс Attributes.
  • Rule -> Класс с правилом
  • Locale -> Класс с ошибками.

3. Кстати, товарищи сделали i18n? Тем не менее, такой вызов exception не очевиден — жёсткая привязка к неймспесу, а значит, и к директории.
Честно говоря, во внутренностях Respect/Validation особо не копался, возможно вы правы. Насчет i18n, я не уверен, что он всем там по дефолту нужен. По крайней мере я сделал свою надстройку и очень доволен (у меня translator переводы из БД берет).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории