As an example, the default i18n message in message.properties for blank fields is:
default.blank.message=Property [{0}] of class [{1}] cannot be blank
If one wants to customize this with a given class (e.g. user) and field (e.g. login), one does
user.login.blank=Your login name must be specified
with the ".message" suffix left-off. This threw me off for a bit (as I had it in there and it didn't work), so I'm wondering if there is a specific purpose to how the ".message" suffix is used / not used in message.properties?
There seem to be quite a bit of mismatches in the use of message customization, beyond just the use of ".message". See example below*.
I believe the grails software developers might include a comment at the top of the message.properties file, guiding the user to look at the right place for defining the custom error messages, e.g. in the Constraints quick reference list, http://www.grails.org/doc/latest/ref/Constraints/matches.html. The top level Contraints section in the quick reference does not include the error code field names, but might it be useful to add there.
*For example, the default match failure is "default.doesnt.match.message", but the specific error is, for example, "user.login.matches.invalid".
Related
The current implementation of a CCDA generator I'm working on, prints a message on a <name> tag (in header sections, where no <text> is available) when something's name is not found:
<name>No information</name>
I know the right way to express not found information is through the #nullFlavor attribute:
<name nullFlavor="NI" />
But right now there is a component on the application that reads the value on the tag and shows it in a human-readable view of the CCDA document. If I use #nullflavor only, the field that shows such name will be empty, instead of "No information".
In order to avoid changing such component, I was thinking on adding the #nullFlavor attribute but still letting the message there:
<name nullFlavor="NI">No information</name>
I know this is syntactically correct, because I've tested it with the reference validator and it passes. My question is: from a semantic point of view, is it valid?
Yes it's valid. The particular specification in question - the v3 abstract data types, simple says:
invariant(ST x) where x.nonNull {
x.headCharacter.notEmpty;
};
So if there's no nullFlavor, there must be some content. But the reverse rule is not applied; there can be content if there's a nullFlavor
Although it is not restricted, my point of view is that it is not a good strategy. I understand that you have a restriction regarding this component but, when you are building a CDA, it is important to keep in mind that it is something to be shared with everyone, and I would never expect to find content inside a nullFlavor attributed element.
Given a RESTful API, implemented in Rails, I want to include in the responses not only the errors messages, generated by ActiveModel::Validations, but also custom error codes. First of all I would like to point out that I am not talking about HTTP Status codes. I am talking about having an error of any type (from general errors like record not found to small validation errors like username can't be blank) be mapped to a unique numeric code, that is custom application-specific error codes. Let me give an example - given a list of error codes, like:
1: record not found
... some other errors
# Validation errors for User model between 1000 to 2000
1001: first name can't be blank
1002: first name must contain at least 3 characters
1003: last name can't be blank
1004: last name must contain at least 3 characters
...some other errors
If I have a form for a user and submit it with empty fields for first and last name, I want to have in the response body something like:
{error_codes: [1001, 1002, 1003, 1004]}
or something similar (for example I could have an array of error objects, each with a code, message for developer, message for user etc.). Let me give an example with the Twilio API, taken from RESTful API Design: what about errors?:
Here, 20003 is some custom Twilio-specific code. The question is - how can this be implemented in Rails? I see several difficult aspects:
how do I get a list of all possible errors that can be encountered. It is hard to get such a list even only for the validation errors, let alone the other types of errors that can occur.
how should this list be organized - maybe in a YAML file?
how do I access the list - maybe something similar to the way translations are accessed via I18n.t?
I will really appreciate any advice on the topic. Thank you.
P.S. I think this is a similar question.
ActiveModel built-in validators can be found here. Sometimes one validator can check for more than one thing and output different messages. The easiest way to see them all is, as you've guessed, in its I18n yaml file, which can be found here.
One way of doing what you want is overwriting those messages with your custom codes. Another way is passing a custom message when explicitly attaching a validator to your models.
validates :name, message: 'code:001 - my custom message'
Those two options won't help you with structure, though. You won't have a different key code on your json out of the box.
One way you can accomplish that is to can create a helper to parse the error messages and extract the codes after they have been assigned to a model instance. Something along the lines of:
def extract_error_codes(error_messages)
error_messages.map{ |message| message.match('^code:(\d+)\s-')[1] }
end
That would give you an array of error codes for that instance if you'd used the format code:001 - my custom message.
Another, much more involved way, is to tap into ActiveModel's Validator class and store an error code when a validation fails. That would require going into each validator to assign the code.
I have a Grails application that needs internationalization. Grails makes it easy to translate fixed strings using the messages.properties file, but I could not find how to translate model fields.
Is there some way to manage internationalized models, so that models in multiple languages can be entered in some admin area and the correct one will be selected in the view?
I could roll up my own system, but maybe something of this kind already exists and it is more featured and battle-tested than what I would write. This had happened to me in Django: I used a custom system - which I describe below - for internationalization, only to find out that various Django apps already solve this problem.
An example of how to solve this issue
If it is not clear what I am trying to achieve, here I describe the implementation I used on Django.
I had two base abstract models, I18NModel and TranslationModel. The actual models used in the application inherited from the former, while their translations from the latter. In inheriting, they needed to define a foreign key to their untranslated model and to define a field with the associated language.
The original model, in turn, inherited a method translate, that took a language and returned a proxy model. This proxy had a reference both to the original, untranslated model and to a translated model associated to the correct item and language.
Whenever you asked for a field on the proxy, it would try to find if it was defined on the translated model. If it was, it would return that, otherwise it would give as default the field on the untranslated model.
Hooking it with a method to find the current language, I got as a result something that I could use like this in the templates:
<h1>{{ article.translate.title }}</h1>
while allowing editors to insert translations in the admin area.
Looks like i18n-fields plugin does the thing.
I am trying to modify the messages.properties file for form input validated by a Command Object that is in specified in the controller. The output I get from the standard error message (that I modified slightly to assure I was hitting that specific one) is:
email cannot be empty test class com.dashboard.RegisterController$DashboardUserRegistrationCommand
but no variant of com.dashboard.RegisterController$DashboardUserRegistrationCommand.null.message
works
I am wondering what the correct specification should be.
Try to put DashboardUserRegistrationCommand outside (below) of RegisterController but still in the same file. Then com.dashboard.DashboardUserRegistrationCommand.. should work.
i.e. com.dashboard.DashboardUserRegistrationCommand.message.nullable
The typical layout of error messages is:
${packageName}.${className}.${propertyName}.${errorCode}
So for your example it would be:
com.dashboard.DashboardUserRegistrationCommand.message.nullable
In the Grails Reference on the right hand side there is a header titled 'Constraints'. On each page of the specific constraints listed under that header the ${errorCode} value is listed at the bottom of the page.
And sometimes you have to restart a run-app to get new messages to populate in a Grails project.
Just to help others in the future, I had the same issues and my problem was the way I was defining my key, I use now:
For default messages:
default.null.message=Write a value for {0}
For commmand error messages:
my.package.UserCommand.name.nullable=Please tell us your name
It is strange that sometimes you use nullable and sometimes you use null. The best thing is going to the Grails Constraints directly and check how is it done for example:
http://grails.org/doc/latest/ref/Constraints/nullable.html
I write code in English but I'm currently doing a site which is fully translated to another language (validation error messages included). However, I have a problem because validation error messages always seem to include the name of the attribute the error is on at the start of the error, e.g.:
Title Prosimo izpolnite naziv fakultete.
I want to get rid of the Title at the start, like so:
Prosimo izpolnite naziv fakultete.
Any help is appreciated. I would rather see if this can be solved without installing any 3rd party plugins.
If it's possible to provide translations for attribute names, that would be a cool solution too, but I would still like to know how it can be done both ways (omit or translate).
There is no need to use the error_messages_for helper for errors, you can write your own helper using the record's errors attribute.
You can just iterate over the error objects and display their messages.