OH2-182 Standardize error message #262
Conversation
| vaccine.isnotcreated = Vaccine is not created. | ||
| vaccine.isnotupdated = Vaccine is not updated. | ||
| vaccine.isnotdeleted = vaccine is not deleted. | ||
| vaccinetype.isnotcreated = vaccine type is not created. |
There was a problem hiding this comment.
Why don't all message text start with a capital letter?
There was a problem hiding this comment.
I will update its. tky
| @@ -0,0 +1,16 @@ | |||
| package org.isf.shared; | |||
There was a problem hiding this comment.
Missing license header
| @@ -0,0 +1,16 @@ | |||
| package org.isf.shared; | |||
|
|
|||
| public class FormatErrorMessage { | |||
There was a problem hiding this comment.
Why is this even necessary? You are just working against the standards that exist for the project for a long time
and implementing new "standards" . This just seems wrong and unnecessary.
And putting this is a package called "shared" seems ironic at best as it appears to be only for the web based client.
There was a problem hiding this comment.
please where it should be. it is necessary because the error that comme from the core with format "angal.package.errormessage.msg" and the front-end just need "package.errormessage" it doesn't needs angal and msg which are on those errors message.
There was a problem hiding this comment.
My point is (and maybe most people would disagree with me) that it seems confusing that two different "standards" are used in the same project. Why did the front-end feel like they needed a different "standard format"? There are lots of "standards" in the project that I'd like to change but don't because it would make things difficult for anyone who works on multiple parts of the project.
There was a problem hiding this comment.
Okay i think it is better to discuss with @mwithi to have the good way to do because the work that i made was to analyse and give a solution of the problem.
There was a problem hiding this comment.
The options are 2:
- api responses with a code and a key, and the key is translated on the "ui" side (or any other "api-consumer") -> so you don't need bundles with translations here
or
- api responses with a translated error -> we need bundles here, so we need a "standard" way all over the project
Let's go back to the analysis (under OH2-182) to better clarify what are we going to achieve here (and clean also a lot of dead code as I've already pointed out in the comments).
See OH2-182.