error handling

[dbu]

we should do some error handling (or define exceptions to be thrown) so that the controller can tell create.js if something went wrong. creation of entity failed, update failed, no permissions, ...

[dbu]

flack wrote: we need a way to let the error bubble back to the user. If the store method is triggered programmatically, I think an exception would be the way to go, since then the calling code can decide what to do. If store is triggered via the REST handler, it could also catch the exception and send its message to the browser. This of course needs support from Create.js. I talked about this issue with @bergie at some point, but I'm not sure if there is a way to pass error messages back to Create.js yet.

dbu: i have seen that create.js shows an overlay if it does get a non-json response. not sure if there is an error: key or something in json that could be used too. http status codes would also make a lot of sense. i.e for the case of already exists, there is a dedicated 4xx code afaik.

[adou600]

I used this "non-json response" thing to deal with a duplicated content creation in the open PR on the CreateBundle: https://github.com/symfony-cmf/CreateBundle/pull/19/files#L0R127 and CMF Website (symfony-cmf/symfony-cmf-website#9).

The visual result:

It is not perfect, but it is the way I found to do it at the moment.

[flack]

Yes, non-JSON responses are interpreted as errors and show as-is with all markup. so you could theoretically use this to show error messages, but it seems kind of hackish. Functionally, the problem with that is that you can't really tell which object failed if you send several changes at once, so an integrated solution with Create.js would be preferable i think. Using different HTTP status codes sounds like a good idea, the question is if and how this should be handled in the library, since at the moment, we don't even send HTTP responses.

We could define a bunch of Exception classes for the different error conditions. then, it would be up to the framework integration code to do the right thing. If Create.js had a defined error format for responses, it would of course be a lot cleaner, although the framework integration would probably still need to do some post-processing for l10n and things like that

[dbu]

i would use one createphp HttpException or something that has a status code and a message. then its up to the controller of the client application to catch that and return something suitable. if / when create.js has a thing to handle errors, we could do a toJson method on the exception to simplify live.

[flack]

Small update: I just talked to @bergie, and apparently, if you sent an HTTP error code, Create.js will display whatever HTML comes in the body as an error message. So combined with @dbu's suggestion, we have a working design for this