UX: Inline error messages

[tabacitu]

Maybe errors should be placed inline, for each field, while highlighting it. The register form already has a standard implementation of this:

<div class="form-group{{ $errors->has('name') ? ' has-error' : '' }}">
                            <label class="col-md-4 control-label">{{ trans('backpack::base.name') }}</label>

                            <div class="col-md-6">
                                <input type="text" class="form-control" name="name" value="{{ old('name') }}">

                                @if ($errors->has('name'))
                                    <span class="help-block">
                                        <strong>{{ $errors->first('name') }}</strong>
                                    </span>
                                @endif
                            </div>
                        </div>

That way:

• we can just show a pnotify bubble in the top-right corner saying "Please fix the errors" and we can hide the error bubble we show now => consistent errors across the platform;
• we improve usability (especially for long forms, when you can forget what fields you missed and have to go back to the top to see, then back down to the field to complete it, etc;

[vishalb812]

If possible, can we make the error notification feature configurable between inline and the existing all-together at the top? That would be very cool and flexible. You have already written code to show all error messages together at the top, so that could as well be refactored, instead of deleting it for the inline code. That would provide the best choice to the user to mix and match as required. Maybe some behavior as below?

a) In the config file, specify the option whether you want the application wide error messages behavior to be inline or all together
b. In the CRUDController, provider a setter method to override the behavior for each CRUD Controller, if required.

[tabacitu]

@vishalbhide yup, that sounds perfect to me.

[OwenMelbz]

@tabacitu how you feeling about this for 3.2? As is a pretty big change for all the field types?

I can see it's easily possible and backward compatible using a JavaScript method, would you be happy with that rather than rewriting many of the field views?

[OwenMelbz]

Backwards compatible PR for this over here #287