Что случилось с laravelcollective после обновления?

Question

[Илья]

Не понятно что случилось с laravelcollective после обновления: composer update

Ранее если в урл был параметр ?group_id=2, поле селект правильно отображало текущее значение

{{ Form::label('group_id', 'Группа') }} 
{{ Form::select('group_id', [1=>'group1', 2=>'group2', 3=>'group3'], null, ['id' => 'group_id', 'class' => 'app-input__select form-control']) }}

Допустим shop.local/admin/product/create/?group_id=2
В форме показывалось текущее значение = group2. Сейчас как бабка отшептала.

Answer 1

[Виктор]

https://github.com/LaravelCollective/html/issues/531
Я убрал это поведение по умолчанию, потому что оно не нравилось многим пользователям, теперь нужно включать через
Form::considerRequest(true)

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

Comments

[Илья]

Спасибо, выручили. 3-й час голову ломаю что я натворил с системой, пока не откатил на предыдущую версию до обновления и понял что там работает все отлично =)

Почему такая система не удобна... В моем случае отстуствие этой системы заставляет описать много лишнего кода для обработки и передачи текущих значений.

[Виктор]

Илья, я поэтому и сделал заполнение из запроса (изначальный PR), чтобы поля фильтра не перезаполнять каждый раз руками.

[Илья]

Если честно, использование одной формы для create и update просто ужасно неудобное, если форма чуть крупнее бложика. Вообще думаю перейти на ручное написание форм, всеравно приходится так или иначе передавать во вьюху миллион параметров вместо одного обьекта с кучей реляций. Очень слабый пакет, хорошо что они оставили возможность передачи данных через принудительное указание. Иначе там вообще функционала не остается =)

[Виктор]

А кто заставляет использовать одну форму для create / update?

[Илья]

А смысл использовать две одинаковые формы, по факту разница между update and create в текущих данных. update они есть, create их нет. Всегда думал что код надо максимально использовать повторно. Но конечно опыта работы с ларавел маловато пока и оптимизировать все очень сложно. Например у laravelcollective есть классные мутаторы для форм https://laravelcollective.com/docs/5.4/html#form-m...

use FormAccessible;
 /**
     * Get the user's date of birth for forms.
     *
     * @param  string  $value
     * @return string
     */
    public function formDateOfBirthAttribute($value)
    {
        return Carbon::parse($value)->format('Y-m-d');
    }

Шикарная штука, правда больше бложика опять с ней не сделать, например можно добавить в форму дополнительный атрибут features - условно и получить какие либо данные не прибегая к прямому указанию - какие должны быть значения текущие у формы во вьюхе. Чисто, красиво и бестолково.

public function formFeaturesAttribute()
    {
        return $this->values->where('feature_id', 3)->first()->value; // Условно что-то там получаем через реляцию "values" и выводим в форму
    }
{{ Form::text('features') }}

Но как сделать
{{ Form::text('features[feature_id][20]') }}

Где 20 идентификатор значения в таблице features (id, value) Просто чтоб мутатор "formFeaturesAttribute" понимал что-то из названия кроме одного слова =) и смог вывести значения в форму самостоятельно. Да вообще перед выводом значения/ий поля в форме была бы возможность указать каак-то зацепки откуда данные брать. У меня например все атрибуты в форме лежать в массиве features, помимо этого есть еще несколько массивов с полями, например product или sku.

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