Groovy Global Response Handler

[theworkerant]

Let's begin this task with an abstract discussion leading to a high level proposed solution. There are many moving parts that this will depend on, for now we can assume they will be implemented separately or in tandem. See examples at the bottom to get an idea of concrete situations this will apply to.

Purpose

The purpose of this task is to unify and make sense of the various ways responses can enter the Ember application. Furthermore, deciding what kind of actions should be taken and how they will be achieved. Much of the important work here will be simply deciding on (and enforcing) the format of the various messages (usually in json) being passed to the app.

A note on I18n

Don't forget we're going to implementing I18n soon on the API side and pass locale information to the Ember side by request. This needs to be taken into account when architecting a solution here.

Behold!

A)

What format will errors sent from the api take? Currently there is a makeshift format in place, something like: {"error": {"some_object": "something bad happened"}}. This isn't so bad, but we need to make sure it doesn't miss anything.

Some questions:

• If there is an error on the API linked to a specific form field, can we determine which field that is and display the proper inline error?
• Do we need to override errors generated by things like Devise and provide our own?
• How will we specify importance of an error, that is, whether it needs to be acknowledged by the user to proceed or a simple temporary alert will suffice? Basically, how will the error be displayed?

B)

I imagine this piece will be the core of whatever code comes out of this task, probably a mixin or something similar. We need to create some sort of library to process a message and make decisions on how it should be displayed by Ember given these sorts of attributes:

• Where did the message come from?
• What is the current user context?
• How important or "bad" is the error?

C)

Given a particular message, how should it be displayed given the current context and contents of the message? What possible display methods will be supported?

This piece overlaps a lot with E.

D)

There will be certain situations where messages should trigger some sort of action on the Ember side. This will most likely be handled on a case-by-case basis and does not need a "general" implementation, however there should be a spot reserved for this.

E)

This part should mostly deal with naming conventions that can be relied upon when building forms. For example, an error on email field might set another field emailError to true and emailErrorMessage to "Bad email!!".

Assuming a separate piece of code that processes form input and generates success/failure of validation/processing of that form, based on the response object we can:

• Determine/display success message if applicable
• Determine whether there is an error and if it is:
  • Form input specific
  • General to the form
  • Something that can be corrected or something really bad

F)

Like API messages (A), we need to decide on a particular format for Pusher messages and how they will be parsed. These messages normally come from async operations but their content can be anything we want.

G)

Any other sorts of messages/responses we might want to account for?

---

Examples Scenarios

• Database explodes when Entry is sent for saving
• User enters "abc" for a numeric form input.
• User enters 123 for a numeric input with a valid range of 1..10 (Rails validation triggered)
• Pusher notification sent after Entry processed and score (success/failure)
• Pusher notification sent to User to let them know about recent blog post
• Current user tries to access Entry form after login has expired

Login Errors (should cover all error-groups)

• Login error, bad password (server response)
• Login email validation failed (Ember form, inline)
• Login but email not verified (API response, general form error)
• Login encounters 500 error (server exploded modal)
• ??? Example of growl style error response?

---

Sub tasks

• Branch off
• Create mixin
• Create test file for mixin
• To test the mixin, create an Ember.Controller and include the mixin
• Insert several response examples to start with
• Implement error response handling for inline errors response
• Dynamically handle the flags like fooError
• Add tests for responses from different "sources" (API, Ember form, Pusher, etc).
• Add integration test for login form, use one example (mockjax) response for each error-group
• Get rid of v1_bla thing in user login

---

From Projectplace Card 2041934 -- https://service.projectplace.com/pp/pp.cgi/1027628928/direct/actions/list/details/2041934

[theworkerant]

Something to keep in mind: http://emberjs.com/guides/routing/loading-and-error-substates/#toc_the-code-error-code-event