Laravel Вложенные формы

[Absinthe]

Каким образом удобнее сделать форму для связанных объектов Item и Property (item has many properties), где количество блоков Property различное (через JS добавлять новые можно).
Интересуют вопросы валидации и сохранения таких объектов.

 

[Adelf]

руками

 

[Absinthe]

Жаль, в некоторых других фреймворках это стандартный функционал.
Думал, что способ есть, просто не описан в документации (там много чего не описано).

 

[Adelf]

@Absinthe, идеология ларавель, да и симфони - найди нужный пакет и юзай. Наверняка такой есть. Подцепляешь в require и начинаешь юзать.
Не обязан фреймворк содержать в себе всё на все случаи жизни.

 

[Absinthe]

На все случаи не обязан, но мы же про базовые вещи говорим. В большинстве проектов нужно будет редактировать 1..* объекты.
Получается, что встроенный функционал работает только для самых простых форм, а для вложенных - уже нет.
Работал в Rails с этим. Поэтому ожидал такого и от Laravel.

 

[Redjik]

@Adelf, ну уж не совсем такая идеология =)
в ларавел ты находишь нужный пакет, смотришь на код, ужасаешься и пишешь свой

ЗЫ. в симфони можно такие формы делать

 

[keltanas]

@Redjik, в Симфони можно. Но тоже не стоит. Там можно будет включить загрузку сраницы с формой и идти курить... )) Я на симфони обрабатываю только серверную валидацию. А верстка (или генерация верстки) формы на фронтенде.

 

[Absinthe]

В Laravel 5.2 появится что-то подобное.
http://ericlbarnes.com/laravel-array-validation/

$v = Validator::make($request->all(), [
'person.*.id' => 'exists:users.id',
'person.*.name' => 'required:string',
]);

 

[Adelf]

Блин. Как раз было бы удобно мне сейчас

 

[fixxxer]

А на каком уровне это предполагается? Всякие exists и прочие unique на уровне application validation мне кажутся несколько ересью

 

[Adelf]

@fixxxer, я говорил про левую часть выражений.

Всяким exists и unique в нормальном приложении места нет.

 

[Absinthe]

Всякие exists и прочие unique на уровне application validation мне кажутся несколько ересью

Было бы проще, если бы исключения ORM не были одного и того же типа.

К тому же как ты предлагаешь валидировать email при регистрации на уникальность? Добавление unique решает все проблемы с формой.

 

[Adelf]

Валидация формы должна просто дать ответ, правильно ли юзер ввел данные. В правильном ли формате email.
То, что он неуникальный вдруг оказался, это не неправильные данные. Это просто логика приложения такая. И проверяться оно должно глубже.

 

[Absinthe]

Логично, мы смешиваем валидацию пользовательского ввода и логику приложения. А теперь представь разницу в количестве кода (нужно не только проверить, но и вернуть сообщение об ошибке в форму над нужным полем).
Покажешь такой код?

 

[Adelf]

У меня сейчас такой. При попытке создать юзера, с email которого уже есть в базе, кидается Exception.

А еще у меня есть interface IErrorMessageException{} Пустой. Он лишь говорит о том, что если пошел Exception с таким interface и он не был отловлен в коде - его message можно показать юзеру.

И в Exceptions/Handler.php

        if($e instanceof IErrorMessageException)
        {
            return redirect()->back()->with('error', $e->getMessage())->withInput();
        }

 

[Absinthe]

Не понял, как совмещаешь результат валидации формы и таких проверок (чтобы над каждым полем было о той ошибке, которая произошла из-за данных в нем).
Плюс что делать, если таких проверок надо несколько (для разных полей, например)?

 

[Adelf]

Аа.. Не. Каждое поле я не показываю. У меня общий error message. Наверху формы. С полями сложнее было бы...

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

 

[Absinthe]

С полями сложнее было бы...

На порядки сложнее.

Поэтому я просто пользуюсь Laravel way подходом (х*як х*як и в продакшн) в проектах на Laravel.

 

[Adelf]

@Absinthe, да не сильно то и сложно. Выделяем отдельно валидацию в бизнес-логике и вызываем ее напрямую после валидации формы. И поля подсветит оно тоже. Если договориться об именах полей.

 

[Absinthe]

Выделяем отдельно валидацию в бизнес-логике и вызываем ее напрямую после валидации формы. И поля подсветит оно тоже. Если договориться об именах полей.

То, как я себе представляю это, занимает много кода.

Особенно по сравнению с 5.2, где будут вложенные формы, и кроме правил валидатора ничего не надо будет делать.