[Zelda] Inline Validation

[ErisDS]

This is required as part of the User Onboarding epic: #5315

One of the biggest changes falling out with Zelda, is an overhaul of the use of notifications. Ghost's old notification system was used and abused for all user messaging, all that is changing in Zelda.

---

At the moment we have a neat validation engine which defines the validation for each of our model. This system fires on save and feeds back to the user via oldschool notifications.

This needs to be magicked into a system that also works inline. Fields that fail validation need to go red, and provide feedback inline to the field, and on-the-fly (that is on de-focus), rather than on save. We want to roll this out across the signin/signup/setup auth flows, but also across things like the settings panes, so that we can eventually do all the saving on the fly without an explicit save button (like the PSM).

(Please ignore the missing icons)

For the auth flows, which still need a button, any post-save messaging is displayed in red below the form, as shown on this screenshot (and as currently permanently displayed on the signin screen 😁).

To implement this new inline validation system, we need a way to redefine our validation rules & system so that they can be applied to each field, rather than an entire model (perhaps leveraging DS.Error?). We also need to provide spaces for the messages along with the inputs. For an example of the HTML for outputting inline validation see the install3.html file.

When specifying the messages to display if a validation rule fails, we'd really like to be able to specify multiple messages and have the interface display one of them at random. Some rules might have one message, others might have several. The idea is to inject a little bit of fun and personality into boring stuff like getting your password right 😉

The major part of this issue is going to be creating the new validation system. Wiring it into one form as an example would be awesome. We can make secondary issues to wire it up elsewhere once the main system is ready.

[acburdine]

After looking into this a little bit, it seems that using DS.Errors is the best way to go. It has an easily understandable way of adding errors, and it is designed out of the box to work with inline errors. Another benefit is it lends itself well to server-side validation.

However, this will take a significant rewrite of the validation engine/other controllers, as DS.Errors only works with DS models. This means stuff like the setup will have to provide a model object in order for inline validation to work, whereas before it allowed the object itself and any other objects to be validated.

Once this gets done, though, it should be pretty easy to implement in various places. I'll try to come up with a re-write of the validation engine and a working inline form in the next couple of days.

[acburdine]

Actually, after doing more research, DS.Errors can be applied to any Ember object, meaning it is trivial to add inline errors to any controller, model, etc.

[acburdine]

@ErisDS I see in the spec that it says "also inline errors" -> does that mean it still needs to be able to trigger old-school notifications? And does it need to be able to verify the entire model at once still, or just by each part? I guess it wouldn't be difficult to do both, but I just want to make sure of what needs to be kept in the new system from the existing system.

[ErisDS]

Essentially, validations against a field are there to prevent bad data being entered into the DB. Showing the messages inline and at the point of de-focus are two slightly related UX improvements, but we still need to enforce these validations on save.

How that works depends a lot on what can be done with Ember, but when you hit submit, if the fields are invalid the messages should still be there and the submit should not work. There is no need to also show old-school notifications (these are mostly going away).

However, some forms (like signin) display additional messages on submit below the button. This is a summary message explaining why the submission failed (or what the first problem was). It uses different language to describe the problem in a more general sense. So the password field might have various different validations in different places like 'too short' or 'incorrect' or 'doesn't match the other password field', but the general message for the password field failing might be 'the password fairy does not approve' as shown above.

The end goal is to be able to better support the 2 different styles of 'form' that exist in Ghost. The simple one being the straightforward form with a submit button of some sort (signin, setup, etc) and the more advanced one being the editor, post settings menu & settings forms where we ideally don't want to have any sort of submit button but instead save on defocus.

I think it's pretty much going to be required that we have {{gh-input}} component to wrap up a lot of this behaviour, including displaying the inline messages? I'm interested to see how easy we can make this to do and extend in nice ways - like showing one of a set of messages, or improving when the validation fires.

[acburdine]

@ErisDS Okay that makes sense 😄 After working on a couple of components for it, IMO it would be better to modify the current {{gh-input}} and {{gh-textarea}} components instead of one that generates the whole form group, and then have a form-group component that handles the error/success view states. I looked at a number of the current forms and it seems that, with the slight differences in each form group + the number of parameters passed in to each {{input}}, if there were to be a component that generates the entire form group (label + icons if any + input + messages), a lot of arguments would have to be passed in to the component through the template. Unless that's okay, in which case I'm more than happy to re-write it to use one giant component.