Add enumerable list of all error objects

[davewasmer]

Currently, validations.messages exposes a flattened array of all error messages present. It would be useful (for a variety of reasons) to have access to both the message as well as the attribute name it corresponds to.

This PR adds validations.errors following the same pattern as validations.messages (it also adds validations.error).

(docs included)

[rwjblue]

I think this will need some tests. Also, can you tweak the docs to indicate what the contents of .errors will be?

[davewasmer]

Good idea - caught a mistake (although I have a sneaking suspicion you knew that already 😉 )

Let me know if you'd like me to squash, or if I missed something in my test coverage.

[offirgolan]

I like this idea but I don't believe this is the best approach. If you look at how the addon is structured, all validation objects share the same model. Meaning that the global props, validation-result, and validation-result-collection all have (messages, invalid, valid, etc.). All this is currently doing is putting errors on the global validation object.I would suggest to start from validation-result.js and work up.

[davewasmer]

@offirgolan glad to hear you like the idea.

So adding an error/errors property to each level? I understand the structure you are describing, but I'm not sure how that would work, since the error objects basically are the validation-result objects.

I could introduce a new concept (an "Error object" for lack of a better name) that is essentially just the message & attribute name, and attach those at each level. Is that what you had in mind?

[offirgolan]

Since all validations are composed of validation result-collection objects, I feel like we can put the logic there (i dont think you need to touch the result file). So errors can listen to messages.[] and generate a set of error objects

{ 
  attribute: get(this, 'attribute'), 
  message: message
}

Or like you said, we can introduce a new concept addon/validations/error.js

export default Ember.Object.extend({
 attribute: null,
 message: null
})

And just create these. I kind of prefer the latter since it can scale better?

From the global props perspective, it can be identical to how the global messages property is computed.

@rwjblue thoughts?

[offirgolan]

Actually now that I think of it, the initial error object creation should happen on the result object, not on the result-collection object. So the error prop will listen to message, attribute and isInvalid which will then create an error object with it's own attribute. On the result-collection object, it would just be the same logic as the messages and same for the global prop.

[davewasmer]

@offirgolan alrighty, updated. Let me know how that looks.

[offirgolan]

Can you remove these empty lines (before and after the props)

[offirgolan]

This looks great! If you can just fix that one comment and rebase this to a single commit, I will merge this 😺

[offirgolan]

This isnt needed here. A result will only have a single error unless the _validations object get replaced by a validation-result object (only in belongs-to and has-many). Thats why the messages CP exists here but no actually messages prop.

[davewasmer]

@offirgolan address both comments and rebased!

[offirgolan]

Beautiful! 💯 thank you sir!

[davewasmer]

🍻